Writable u-boot partition (Ralink MT7268 Soc)

For Developers
1

Hi,

There must be something I am missing. In my routers DTS file I remove the "read-only" line for the "u-boot" partition. It looks just like the firmware partition now.
However, I can write the firmware partition, but MTD does not let me write to u-boot. As far as I can tell, the command should be the same, just different file and partition name, right??

On the Openwrt forum I can find people changing other files, but similar files are not available (can't find) for my Ralink MT7268 Soc.

2

You might need to "unlock" the partition with mtd, first

Quote from my old message in Openwrt forum:
https://forum.openwrt.org/viewtopic.php?pid=275865#p275865

Behaviour in this firmware:
---------------------------
root@OpenWrt2:~# mtd unlock u-boot
Unlocking u-boot ...
root@OpenWrt2:~# mtd unlock firmware
Unlocking firmware ...
root@OpenWrt2:~# mtd unlock art
Unlocking art ...

And if you need more device-specific advice, please edit the title of the thread to contain clearly the device. I already edited the target there. The needed procedures can be target or device specific, so you might need help from Ralink MT7628 specialists. (As an example, the same linked message contains the process for ar71xx devices in 2015, and it is quite different that your DTS change.)

3

Thank you for changing the Thread Name.

As I said: I could find other people (seems you are one of them) did change other files. However most (if not all) the threads I could find regarding unlocking MTD partitions were AR71xx related.

Looks like I have to start digging inside the makefile which seems to override the DTS read-only (or not) setting.

To answer device specific: I am working on the Mercury MAC1200R v2. I patched the DTS already since the one at the moment is not complete or incorrect eg. only 4 MB instead of 8MB flash and no GPIO for any LEDs and no proper PinCtrl settings. Once I have it fully up and running I will upload the changes.

4

I hoped I found a solution by installing the kernel mod: mtd-rw

root@LEDE:/tmp# insmod mtd-rw i_want_a_brick=1
[ 180.846288] mtd-rw: mtd0: setting writeable flag
[ 180.855508] mtd-rw: mtd1: setting writeable flag
[ 180.864659] mtd-rw: mtd2: setting writeable flag
[ 180.873807] mtd-rw: mtd6: setting writeable flag
[ 180.882951] mtd-rw: mtd7: setting writeable flag
root@LEDE:/tmp# mtd unlock /dev/mtd0
Unlocking /dev/mtd0 ...
root@LEDE:/tmp# mtd write uboot_new.bin /dev/mtd0
Unlocking /dev/mtd0 ...

Writing from uboot_new.bin to /dev/mtd0 ... [e]Failed to erase block
root@LEDE:/tmp# mtd write uboot_new.bin u-boot
Could not open mtd device: ▒u-boot
Can't open device for writing!
root@LEDE:/tmp# mtd write uboot_new.bin "u-boot"
Unlocking u-boot ...

Writing from uboot_new.bin to u-boot ... [e]Failed to erase block
root@LEDE:/tmp#

It looks like it unlocks but erase fails :frowning:

5

Would (temporary) applying the patch I found on the OpenWrt-Devel solve my flashing problem? Basically the patch was to flash at an offset of an erase block. Since my Uboot partition is less then a full erase block, MTD fails??

https://lists.openwrt.org/pipermail/openwrt-devel/2014-June/026110.html

extract from my partition table:

	partition@0 {
		label = "u-boot";
		reg = <0x0 0x1d800>;
	};

	factory: partition@0x1d800 {
		label = "factory_info";
		reg = <0x1d800 0x800>;
		read-only;
	};

	art: partition@0x1e000 {
		label = "art";
		reg = <0x1e000 0x2000>;
		read-only;
	};
6

I bit the bullet and made a very dirty hack/patch. Change my uboot partition to include the factory info and art partition. Add the information stored there to my uboot.bin and flash the full block.

Success!! Now I have a uboot that doesn't do a RSA check on my custom-firmware and rejects the code :smile:

7

Great that you got it working.
And nice work figuring out the ultimate reason for your initial failure.

Looks rather non-standard that they have crammed the u-boot, factory info and art partitions into the same erase block.

8

For now I have a workable project: No longer a need for a UART cable connection to start the firmware. But this U-boot looks more standard. It starts the Kernel from offset 0x050000. The OEM started at 0x040000. As a workaround for myself I just added an extra MTD partition at 0x040000 as "reserved" but that means I can't revert to the OEM firmware, even if that should boot just fine without any RSA check inside the uboot.

I guess I have to start diggin more into the inner works of the U-boot itself to rearrange partitions and have it boot 1 block earlier. Increasing the Overlay FS size by one block in the process, just in case I start running out of memory :wink:

Even the U-boot enviroment is writable, adding a bootdelay/bootcmd parameter doesnt seem to work. Looks like the recovery (TFTP) command is hardcoded and does get priority over the bootcmd parameter (not sure if thats a feature or just improper coding)