We have upgraded the community system as part of the upgrade a password reset is required for all users before login in.

Help Opening/writting over MTD partitions

  • I am trying to copy my bootloader (mtd0) and replace the kernel (mtd4) I know this will render the Onion "unusable", but I want to do that to have a secondary bootloader to edit and have the primary bootloader still available for if/when i brick a bootloader trying to change it and compiling.

    Regardless on if I try to copy the actual u-boot itself or the given binaries from the official repo I get a permision denied error.

    If anyone knows of how to give myself the correct permissions that would be great, or maybe a way to do it on a lower level such as bootloader mode.

    root@Omega-8279:/# dd if=uboot-omega2p-20200512.bin of=/dev/mtd4 bs=4096
    dd: can't open '/dev/mtd4': Permission denied
    root@Omega-8279:/# dd if=/dev/mtd0 of=/dev/mtd4 bs=4096
    dd: can't open '/dev/mtd4': Permission denied
    crw-r-xr-x    1 root     root       90,   8 Jan  1  1970 /dev/mtd4

  • I guess you should look at mtd rather than dd. mtd is the tool sysupgrade uses to write the firmware partition.

    At the uboot level, only 4 partitions exist, uboot, uboot_env, factory and firmware, the last one covering the entire remaining space of the flash.

    firmware contains the uimage, which consists of a header, the kernel, and the compressed (squashfs) rootfs. It's is the mtd kernel driver which only later creates the kernel, rootfs and rootfs_data partitions on the fly, and also makes kernel and rootfs read-only (because these don't even align with erase blocks, you can see this in the output of dmesg)

    I guess you'll be able to write something arbitrary into firmware using mtd, but I doubt just a 1:1 copy of the uboot partition will do, because as far as I understand, uboot needs to find that uimage header at the beginning of firmware to instruct uboot what to do with the contents (decompress, load into ram, call,...). So you probably need to prefix your second copy of uboot with a suitable uimage header such that it gets properly loaded and started.

    Anyway, for such experiments, personally I'd try to do this from the uboot console, not from within linux, because the latter will work only one time (and then you'd need to recover via uboot http server or similar anyway).

    [Update] If you have the openwrt sdk installed, you'll also have the mkimage tool in ./staging_dir/host/bin/mkimage which can generate uimage headers.

  • @luz Thank you very much for your help I did start creating the uImages shortly after this since I was getting a Bad Magic Number but was unsure why/how until reading your post. Currently trying to create the correct uImage as I'm unsire if my current errors come from pointing in the wrong memory load adress or empty points. Still relatively new to this but I appreciate the help

Log in to reply

Looks like your connection to Community was lost, please wait while we try to reconnect.