Way to flash U-Boot on Omega 2

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

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 thereunfortunately 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.

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.