Way to flash U-Boot on Omega 2
-
@perillamint Keep in mind the console on the LinkitSmart is on Serial 2, while the Omega2 is Serial 0.
-
@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?
-
@WereCatf I already removed that param from DTB but it didn't work.
-
@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.
-
@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 ofcp.ubootvscp.linuxand 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 -aorcat /proc/unameshow 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
flashromsupports 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.
-
@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.
-
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.
-
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.
-
This post is deleted!
-
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.
