Way to flash U-Boot on Omega 2

perillamint .

Hello, I'm currently trying to flash Linkit 7688 u-boot to Omega 2. (Yes, I know it may hard brick my omega 2) However, I don't want to use in-circuit programming because it requires some bothering tasks like de-solder EMI shield and solder leads on SPI flash, etc.

At first, I removed read-only from Omega2 DTB. No luck here.
Second, I tried to flash it using U-Bot shell. I tried this command with firmware partition which is easily recoverable.

Using U-Boot shell, I successfully loaded firmware blob into 0x80000000 and able to erase SPI flash (tried it with easily recoverable firmware partition), but when I executed cp command, it says

Omega2 # cp .b 0x80000000 0x50000 6815914
Usage:
cp      - memory copy

I also tried this

Omega2 # cp 0x80000000 0x50000 6815914
Usage:
cp      - memory copy

It seems U-Boot cp command does not work as expected.

How can I flash u-boot partition? Does someone knows how to do it?

Chris Stratton

You would probably need to check the source (or possibly strings on the binary, potentially after decompression) to see exactly what they did.

In Mediatek's U-Boot the cp command cannot do arbitrary writes but primarily exists as a cp.uboot and cp.linux because the usual do_mem_cp() is overridden by a limited one in drivers/spi_rt6855A_flash.c. There's a fair chance whatever Onion is using is derived from this.

Needless to say this is only recommended if you have recourse to JTAG or SPI in case something goes wrong. Of the pins needed for SPI, only /CS0 is not on the headers, ~~and it's probably on the SMD connector pads on the bottom, the only one that would need to be picked up there~~ unfortunately it is not on the SMD pads on the bottom either - it appears to run directly from the SoC to pin 1 of the flash with only a boot mode pulling resistor. If you do take the shield can off, it's a micrograbber friendly SOIC-8 (Incidentally, to reflash via SPI, the MT7688 has to be held in reset).

Writing U-Boot from a Linux kernel that does not protect that partition does work.

WereCatf

@perillamint-. said in Way to flash U-Boot on Omega 2:

How can I flash u-boot partition? Does someone knows how to do it?

If you use a custom kernel with modified DTB to make the MTD-partitions writeable, you could just use the mtd utility from within the OS.

Ghent The Slicer

You guys like to live dangerously. This has a good chance of bricking the omega2. If only there were some Onion people around to help with the JTAG pins or the u-boot source...ping ping, nudge nudge..

Ghent The Slicer

@perillamint Keep in mind the console on the LinkitSmart is on Serial 2, while the Omega2 is Serial 0.

perillamint .

@Chris-Stratton I examined Linkit source and Widora bootloader source , but they says it takes 3 additional arguments: source addr, dst addr, copy size.

Unfortunately, it didn't work.

I also trying to disassemble it using IDA, but I couldn't find its base address from (leaked) datasheet. Is there any document describes base addr?

perillamint .

@WereCatf I already removed that param from DTB but it didn't work.

perillamint .

@Ghent-The-Slicer Thanks.

BTW, I think desoldering EMI shield will expose EEPROM. I think I can try in-circuit programming when I hard bricked my omega.

Chris Stratton

@perillamint-. said in Way to flash U-Boot on Omega 2:

@Chris-Stratton I examined Linkit source and Widora bootloader source , but they says it takes 3 additional arguments: source addr, dst addr, copy size.

I suspect you are looking at the wrong version of do_mem_cp() there are several in different files. On Mediatek's own build it is the two argument one in drivers/spi_rt6855A_flash.c (linked above) that is compiled, rather than the 4-argument ones in other more generic files. Figuring out from that source how to use that version is likely what you need - looks like it might only take the command verb and a size since the destination address is set by the choice of cp.uboot vs cp.linux and the source address looks like it may be hardcoded to wherever kermit or tftp store things.

I also trying to disassemble it using IDA, but I couldn't find its base address

There's some sort of vector table like thing first, but that would probably be the same in form for any build, so you should be able to find the entry address from something like the .elf of your own build. U-Boot itself will probably print out the relocation address at that point in the execution. There are some notes in the U-Boot sources about dealing with that offset while debugging, etc.

I already removed that param from DTB but it didn't work.

Removing the write protection of the device tree entry does in fact work, at least if you change the effective one and end up running the resulting build. Does uname -a or cat /proc/uname show that it is the kernel you compiled?

BTW, I think desoldering EMI shield will expose EEPROM. I think I can try in-circuit programming when I hard bricked my omega.

It's flash not EEPROM, but yes it will be exposed and it's a micrograbber-friendly SOIC, just remember to hold the MT7688 in reset to release the lines. It's not a part that something like flashrom supports very well, but then that is a horribly inefficient tool in the procedures it enforces, especially for large storage devices like this - after suffering through that route once, if I had to do it again I'd probably rig up something custom with an STM32 dev board, or even try to turn an operable MT7688 board into a buddy-programmer using the second SPI chip select, /CS1.

Ghent The Slicer

@perillamint
What +Chris said. There are two commands cp.linux and cp.uboot - both are available on the omega. Both commands take no parameters.

They copy whatever was loaded with tftp at address 0x80100000 and write it to the corresponding flash partition.

So in theory, you should load the desired firmware with tftp at address 0x80100000, then erase the flash partition and issue cp.linux and that should write it. Again in theory.

Ghent The Slicer

Btw. I was not able to get the Ethernet to work on the Omega2s, so I can't try tftp.

I'm waiting for my ethernet dock - hopefully that would work.

Ghent The Slicer

Another avenue you can try is to program the spi flash with a series of "spi" commands. Try "help spi", but you'll have to write a tool to issue the commands one by one.

Chris Stratton

This post is deleted!

perillamint .

I removed read-only from DTB and it worked.

However during initial porting attempt, my bootloader failed to load kernel.

While trying to fix it, I accidentally erased my u-boot so I have to open the shield.

Thanks everyone.