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.
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.)
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.
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#
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??
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
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
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)