After updating with the recovery tool I have lost the capability to use ethernet. See log below:
U-Boot SPL 2020.04-00378-gcc0cba256 (May 16 2023 - 18:33:13 +0200)
Normal Boot
U-Boot 2020.04-fsimx8mp-Y2023.03 (Mar 13 2023 - 19:29:40 +0000) for F&S
CPU: i.MX8MP[8] rev1.1, 1600 MHz (running at 1200 MHz)
CPU: Industrial temperature grade (-40C to 105C)
Reset: POR
Model: PicoCoreMX8MP
Board: PicoCoreMX8MP Rev 1.10 (eMMC, 1x DRAM)
DRAM: 1 GiB
TCPC: Vendor ID [0x1fc9], Product ID [0x5110], Addr [I2C2 0x52]
MMC: FSL_SDHC: 0, FSL_SDHC: 2
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
BuildInfo:
- ATF 1d14183
- U-Boot 2020.04-fsimx8mp-Y2023.03
flash target is MMC:2
Net: No ethernet found.
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot: 0
PicoCoreMX8MP # ping 192.168.99.1
No ethernet found.
ping failed; host 192.168.99.1 is not alive
Dear Paul,
did you enter the serial number of your Board into the prompt Serial?
The Board-ID field should change to your board type then.
Please try the recovery tool again and make sure Board-ID shows your correct board type.
Your F&S Support Team
Hello everyone.
Is there also an option to recover a i.MX8M-Plus board from LINUX (e.g. Ubuntu). Or is this only possible via Windows?
Best regards.
Maik
Thanks for the response.
I switched the module from a working SKIT for now. But it would be great to have a LINUX port.
Thanks.
I performed to recover NBOOT and UBOOT according the documentation. I successfully was able to go back to the uboot command line interface and installed the image from the release package (directory: binaries) via the command "update usb install.scr". The boot was also a success but after a restart/reboot from LINUX the board was bricked again (see [1] for full log):
mmc_load_image_raw_sector: mmc block read error
Booting from MMC1 failed
SPL: failed to boot from all boot devices
I tested it multiple times and with two separate SKITs. But always the same result.
Please assist to permanantly recover the board.
Thanks.
[1]:recovery.txt
Hello,
the current Recovery-Tool installs U-Boot and Nboot from fsimx8mp-Y2023.03.
To update from fsimx8mp-Y2023.03 to fsimx8mp-Y2023.09 you will have to update U-Boot and Nboot too.
Please follow the instructions at
i.MX8M-Plus Linux Release Y2023.09 (Yocto 4.0)
at "Attention"
We will upload a Recovery-Tool with U-Boot and Nboot from fsimx8mp-Y2023.09 soon.
Your F&S Support Team
Hi.
That would be great. Because only to replace the *.fs files does not seems to work and the uuu-*.exe displays an error.
I could fix the issue in the meantime with reflashing the NBOOT and UBOOT after I flashed the ROOTFS image.
Thanks.
I can explain what happened above in the update process from the recovery.txt log.
The new NBoot and new U-Boot are downloaded via UUU-Tool to RAM and are started. There in U-Boot, the same (new) NBoot and U-Boot are loaded to RAM again and also saved to eMMC. This is successful. So at this moment, the system is in a stable state and should be capable of restarting.
Please note that in this version, U-Boot is still stored in the User partition of eMMC. This is important because it is the reason why the next step fails.
Now the update command is started. This loads the emmc-fsimx8mp.sysimg and writes it to the User-Partition of eMMC. This also includes the section in the partition where U-Boot is located. So if sysimg either does not contain an U-Boot at all or if it holds a different version of U-Boot, then U-Boot is now overwritten by zeroes or with the different (old) copy of U-Boot, which does not match the installed NBoot. So when the update command ends, U-Boot is already corrupted in eMMC and restarting the system would already fail. But as you are in a working U-Boot in RAM, you do not see this right now. So booting Linux actually succeeds. But when trying to reboot later, NBoot (SPL) does not find a matching U-Boot version (or any U-Boot image at all) and fails to boot.
You could do the same restoration procedure again, just NBoot and U-Boot, not Linux! Then the system should be working again, because then the new U-Boot is again saved. But the main problem is that you must use the same U-Boot in your sysimg. Otherwise you will always kill U-Boot when saving the sysimg.
In the past, we sometimes changed some stuff in the boot process, either in NBoot or in U-Boot, so unfortunately NBoot and U-Boot were rather dependent on each other, so they needed to be more or less in sync. And the idea of storing U-Boot in the User partition also proved as problematic.
In the meantime, we have optimized the whole NBoot/U-Boot boot process quite considerably. Starting with the release in September 2023, U-Boot is now stored in the Boot partitions of eMMC, too, and is not part of the User-Partition anymore. Thus writing a new sysimg can not corrupt U-Boot anymore. There are also many other improvements in NBoot and the fsimage command in U-Boot, so we strongly recommend switching to the new release. From now on, NBoot and U-Boot are rather independend of each other, and updating NBoot will only be necessary in very rare cases.
Your F&S Support Team
Hi,
how do i determine which Board-ID my chip has?
I got a bunch of picocoremx8mpr2 rev 1.00.
You have to enter your serial number. The Recovery Tool will then automatically contact our server and determine the BOARD-ID. You do not have to (and even should not) enter the BOARD-ID manually. A wrong BOARD-ID may make things worse.
Your F&S Support Team
