A place to talk about anything and everything Omega related
4311
Topics
23530
Posts
@mrahul said in OM2+ getting stuck in boot stage with custom firmware using b255:
Should we see the same behavior if we use the binary downloaded from the Onion FW Repo?
No, my previous comment does not apply to firmware in the Onion firmware repo - these firmware images are already compiled and should contain everything needed.
So devices with mac addresses that start with 40:A3:6B should boot and operate properly when flashed with any firmware from the Onion firmware repo.
Devices with mac address addresses starting with 88:1E:59 will boot and operate correctly when flashed with firmware b255 and higher.
I've confirmed this with devices I have on hand
Device with 40:A3:6B mac address running firmware b254:
Device with 40:A3:6B mac address running firmware b259:
Device with 88:1E:59 mac address running firmware b256:
@mrahul said in OM2+ getting stuck in boot stage with custom firmware using b255:
However, we only use two methods, i.e. through ethernet or syupgrade to upgrade or re-flash a device on bricking. How different are these two processes?
For a device that boots into linux successfully, upgrading the firmware thru sysupgrade and thru ethernet with the bootloader will have the same effect. As long as sysupgrade is run with the -n option to overwrite the existing configuration and filesystem.
For a device that cannot boot into Linux, we recommend reflashing the firmware with ethernet thru the bootloader.
@mrahul said in OM2+ getting stuck in boot stage with custom firmware using b255:
Lately, we've started seeing the same behavior again with b255 where it gets stuck in the boot process.
Does this mean the firmware sometimes works and sometimes doesn't?
This could point to something in the hardware design impacting the boot sequence. Do you use any SPI devices? Do you follow the bootstrapping pins guidelines in your hardware?
My recommendation
Since you mentioned you're using the through-hole Omega2+, we can try to isolate where the issue is coming from.
I recommend doing the following:
Remove an Omega2+ device from your custom board
Plug it into an Onion Expansion Dock with an Ethernet Expansion
Use the bootloader + ethernet to flash firmware b259 from the Onion firmware repo
Observe the outcome, given my testing I expect this device should boot properly
Plug the device back into your custom board and attempt to boot it again
Let me know how it goes!
@luz hahaha, trying to become a full onioneer little by little.
It is the Omega2+. Here is a log of the boot process to see if I'm missing anything.
U-Boot 2024.04-gc2bfb2b8c6 (Jul 19 2024 - 15:18:23 -0400)
CPU: MediaTek MT7688A ver:1 eco:2
Boot: DDR2, SPI-NOR 3-Byte Addr, CPU clock from XTAL
Clock: CPU: 580MHz, Bus: 193MHz, XTAL: 40MHz
Model: Onion Omega2+
DRAM: 128 MiB
Core: 59 devices, 18 uclasses, devicetree: separate
Loading Environment from SPIFlash... SF: Detected mx25l25635e with page size 256 Bytes, erase size 64 KiB, total 32 MiB
OK
In: uartlite@c00
Out: uartlite@c00
Err: uartlite@c00
Initializing MT7688 GPIO system.
Net: eth0: eth@10110000
Hit any key to stop autoboot: 0
=>
I did see that address 80800000 is outside the zone range of the memory but the load address is defined as 0x80800000 and trying to load it via tftp and booting anywhere else fails to decompress the image. Maybe thats the issue and just assumed it should work. Thought the offset would take care of that but maybe I am misunderstanding what the offset does
CONFIG_SYS_LOAD_ADDR=0x80800000
Go-to resource for frequently asked technical questions
55
Topics
121
Posts
Ah I think this answers the question of why it doesn't work initially:
@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:
The woraround i found now is to first
sysupgrade -F -n -v onion_omega2p-22.03.5-20240122.bin a fresh omega
let that reboot and then
mtd -r write pan230_v4.1-96_20240222.bin firmware
This works, taking a LOT of precious extra time, but no nastyness.
The target device needs to be running the same firmware version as the original device. (This is mentioned in Step 2 in the original post)
The reason being the cloning only overwrites the firmware partition. If the rest of the partitions don't match, that opens to door to the nastiness you've been experiencing.
@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:
thanks for that little push toward the image builder.
Glad you're finding it useful!!
@tony-ter-neuzen said in FAQ: Is it possible to "clone" the firmware running on an Omega2 device and copy it to other Omega2 units?:
I hope i still can bother you now and then, because i'm absolutely convinced i will find plenty of obstacles to be conquered
On that note, would it be better to report in the git issues or to discuss in the community?
Definitely! Always open to suggestions!
I think the community is good for general discussion, if there's something specific then open a github issue
@cyberai pls try running the checkCamera.py Example Python Program and posting the command line output and screenshots of the output.
This will give us a better idea of what's going on.
