Odroid N2: Issues with recent firmware and emmc modules

[umiddelb]

Armbianmonitor:

http://www.example.com/

Hi,

 

in addition to this topic I would like to mention that the current Odroid N2 Firmware (Armbian 22.05.0-trunk.0004 Jammy with Linux 5.10.103-meson64 / U-Boot 2022.01-armbian (Mar 03 2022 - 19:25:51 +0000) odroid-n2/n2-plus) as well has difficulties with both the orange and the red coloured eMMC modules at this time. 

 

The orange coloured eMMC module is recognised but couldn't be activated ("unable to select a mode : -5"):

Spoiler

G12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:0;0.
                                                                      bl2_stage1
bl2_stage_init 0x81
hw id: 0x0000 - pwm id 0x01
bl2_stage_init 0xc1
bl2_stage_init 0x02

L0:00000000
L1:00000703
L2:00008067
L3:04000000
B2:00002000
B1:e0f83180

TE: 383826

BL2 Built : 06:17:13, Jun 28 2019. g12b gf0505d7-dirty - qi.duan@droid13

Board ID = 3
Set A53 clk to 24M
Set A73 clk to 24M
Set clk81 to 24M
A53 clk: 1200 MHz
A73 clk: 1200 MHz
CLK81: 166.6M
smccc: 00062388
eMMC boot @ 0
sw8 s
DDR driver_vesion: LPDDR4_PHY_V_0_1_14 build time: Jun 28 2019 06:17:09
board id: 3
Load FIP HDR from eMMC, src: 0x00010200, des: 0xfffd0000, size: 0x00004000, par0
fw parse done
Load ddrfw from eMMC, src: 0x00060200, des: 0xfffd0000, size: 0x0000c000, part:0
Load ddrfw from eMMC, src: 0x00038200, des: 0xfffd0000, size: 0x00004000, part:0
PIEI prepare done
fastboot data load
00000000
emmc switch 1 ok
00000000
emmc switch 2 ok
fastboot data verify
verify result: 255
Cfg max: 2, cur: 1. Board id: 255. Force loop cfg
DDR4 probe
ddr clk to 1320MHz
Load ddrfw from eMMC, src: 0x00014200, des: 0xfffd0000, size: 0x0000c000, part:0
00000000
emmc switch 0 ok
Check phy result
INFO : End of initialization
INFO : End of read enable training
INFO : End of fine write leveling
INFO : End of read dq deskew training
INFO : End of MPR read delay center optimization
INFO : End of Write leveling coarse delay
INFO : End of write delay center optimization
INFO : End of read delay center optimization
INFO : End of max read latency training
INFO : Training has run successfully!
1D training succeed
Load ddrfw from eMMC, src: 0x00020200, des: 0xfffd0000, size: 0x0000c000, part:0
Check phy result
INFO : End of initialization
INFO : End of 2D read delay Voltage center optimization
INFO : End of 2D write delay Voltage center optimization
INFO : Training has run successfully!

R0_RxClkDly_Margin==94 ps 8
R0_TxDqDly_Margi==106 ps 9

R1_RxClkDly_Margin==0 ps 0
R1_TxDqDly_Margi==0 ps 0

 dwc_ddrphy_apb_wr((0<<20)|(2<<16)|(0<<12)|(0xb0):0001
2D training succeed
auto size-- 65535DDR cs0 size: 2048MB
DDR cs1 size: 2048MB
DMC_DDR_CTRL: 00600024DDR size: 3928MB
cs0 DataBus test pass
cs1 DataBus test pass
cs0 AddrBus test pass
cs1 AddrBus test pass
 pre test  bdlr_100_average==456 bdlr_100_min==456 bdlr_100_max==456 bdlr_100_c6
 aft test  bdlr_100_average==456 bdlr_100_min==456 bdlr_100_max==456 bdlr_100_c6
non-sec scramble use zero key
ddr scramble enabled

100bdlr_step_size ps== 467
result report
boot times 0Enable ddr reg access
00000000
emmc switch 3 ok
Authentication key not yet programmed
get rpmb counter error 0x00000007
00000000
emmc switch 0 ok
Load FIP HDR from eMMC, src: 0x00010200, des: 0x01700000, size: 0x00004000, par0
Load BL3X from eMMC, src: 0x0006c200, des: 0x0175c000, size: 0x00096200, part: 0
0.0;M3 CHK:0;cm4_sp_mode 0
E30HDR
MVN_1=0x00000000
MVN_2=0x00000000
[Image: g12b_v1.1.3375-8f9c8a7 2019-01-24 10:44:46 guotai.shen@droid11-sz]
OPS=0x40
ring efuse init
chipver efuse init
29 0a 40 00 01 0b 10 00 00 19 34 37 57 4e 4b 50
[0.019859 Inits done]
secure task start!
high task start!
low task start!
run into bl31
NOTICE:  BL31: v1.3(release):ab8811b
NOTICE:  BL31: Built : 15:03:31, Feb 12 2019
NOTICE:  BL31: G12A normal boot!
NOTICE:  BL31: BL33 decompress pass
ERROR:   Error initializing runtime service opteed_fast

U-Boot 2022.01-armbian (Mar 03 2022 - 19:25:51 +0000) odroid-n2/n2-plus

Model: Hardkernel ODROID-N2
SoC:   Amlogic Meson G12B (S922X) Revision 29:a (40:2)
DRAM:  3.8 GiB
MMC:   sd@ffe05000: 0, mmc@ffe07000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Board variant: n2
Net:   eth0: ethernet@ff3f0000
Hit any key to stop autoboot:  0

=> mmc dev 1
unable to select a mode : -5

 

The red coloured eMMC module cannot be used due to a partition type mismatch (ext4 vs. dos):

Spoiler

12B:BL:6e7c85:7898ac;FEAT:E0F83180:2000;POC:F;RCY:0;EMMC:0;READ:0;0.8
                                                                      bl2_stage1
bl2_stage_init 0x81
hw id: 0x0000 - pwm id 0x01
bl2_stage_init 0xc1
bl2_stage_init 0x02

L0:00000000
L1:00000703
L2:00008067
L3:04000000
B2:00002000
B1:e0f83180

TE: 85701

BL2 Built : 06:17:13, Jun 28 2019. g12b gf0505d7-dirty - qi.duan@droid13

Board ID = 3
Set A53 clk to 24M
Set A73 clk to 24M
Set clk81 to 24M
A53 clk: 1200 MHz
A73 clk: 1200 MHz
CLK81: 166.6M
smccc: 000196a4
eMMC boot @ 0
sw8 s
DDR driver_vesion: LPDDR4_PHY_V_0_1_14 build time: Jun 28 2019 06:17:09
board id: 3
Load FIP HDR from eMMC, src: 0x00010200, des: 0xfffd0000, size: 0x00004000, par0
fw parse done
Load ddrfw from eMMC, src: 0x00060200, des: 0xfffd0000, size: 0x0000c000, part:0
Load ddrfw from eMMC, src: 0x00038200, des: 0xfffd0000, size: 0x00004000, part:0
PIEI prepare done
fastboot data load
00000000
emmc switch 1 ok
00000000
emmc switch 2 ok
fastboot data verify
verify result: 255
Cfg max: 2, cur: 1. Board id: 255. Force loop cfg
DDR4 probe
ddr clk to 1320MHz
Load ddrfw from eMMC, src: 0x00014200, des: 0xfffd0000, size: 0x0000c000, part:0
00000000
emmc switch 0 ok
Check phy result
INFO : End of initialization
INFO : End of read enable training
INFO : End of fine write leveling
INFO : End of read dq deskew training
INFO : End of MPR read delay center optimization
INFO : End of Write leveling coarse delay
INFO : End of write delay center optimization
INFO : End of read delay center optimization
INFO : End of max read latency training
INFO : Training has run successfully!
1D training succeed
Load ddrfw from eMMC, src: 0x00020200, des: 0xfffd0000, size: 0x0000c000, part:0
Check phy result
INFO : End of initialization
INFO : End of 2D read delay Voltage center optimization
INFO : End of 2D write delay Voltage center optimization
INFO : Training has run successfully!

R0_RxClkDly_Margin==82 ps 7
R0_TxDqDly_Margi==106 ps 9

R1_RxClkDly_Margin==0 ps 0
R1_TxDqDly_Margi==0 ps 0

 dwc_ddrphy_apb_wr((0<<20)|(2<<16)|(0<<12)|(0xb0):0001
2D training succeed
auto size-- 65535DDR cs0 size: 2048MB
DDR cs1 size: 2048MB
DMC_DDR_CTRL: 00600024DDR size: 3928MB
cs0 DataBus test pass
cs1 DataBus test pass
cs0 AddrBus test pass
cs1 AddrBus test pass
 pre test  bdlr_100_average==461 bdlr_100_min==461 bdlr_100_max==461 bdlr_100_c1
 aft test  bdlr_100_average==461 bdlr_100_min==461 bdlr_100_max==461 bdlr_100_c1
non-sec scramble use zero key
ddr scramble enabled

100bdlr_step_size ps== 450
result report
boot times 3Enable ddr reg access
00000000
emmc switch 3 ok
Authentication key not yet programmed
get rpmb counter error 0x00000007
00000000
emmc switch 0 ok
Load FIP HDR from eMMC, src: 0x00010200, des: 0x01700000, size: 0x00004000, par0
Load BL3X from eMMC, src: 0x0006c200, des: 0x0175c000, size: 0x00096200, part: 0
0.0;M3 CHK:0;cm4_sp_mode 0
E30HDR
MVN_1=0x00000000
MVN_2=0x00000000
[Image: g12b_v1.1.3375-8f9c8a7 2019-01-24 10:44:46 guotai.shen@droid11-sz]
OPS=0x40
ring efuse init
chipver efuse init
29 0a 40 00 01 0b 10 00 00 19 34 37 57 4e 4b 50
[3.305690 Inits done]
secure task start!
high task start!
low task start!
run into bl31
NOTICE:  BL31: v1.3(release):ab8811b
NOTICE:  BL31: Built : 15:03:31, Feb 12 2019
NOTICE:  BL31: G12A normal boot!
NOTICE:  BL31: BL33 decompress pass
ERROR:   Error initializing runtime service opteed_fast

U-Boot 2022.01-armbian (Mar 03 2022 - 19:25:51 +0000) odroid-n2/n2-plus

Model: Hardkernel ODROID-N2
SoC:   Amlogic Meson G12B (S922X) Revision 29:a (40:2)
DRAM:  3.8 GiB
MMC:   sd@ffe05000: 0, mmc@ffe07000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Board variant: n2
Net:   eth0: ethernet@ff3f0000
Hit any key to stop autoboot:  0
=> part list mmc 1

Partition Map for MMC device 1  --   Partition Type: DOS

Part    Start Sector    Num Sectors     UUID            Type
  1     8192            60448768        1f0554cd-01     83
 

 

I don't know if there is already a corresponding Jira issue and/or development activities going on. 

 

Cheers

Uli 

 

PS: 

odroidn2:~:% sudo armbianmonitor -u
System diagnosis information will now be uploaded to curl: (52) Empty reply from server
Please post the URL in the forum where you've been asked for.

 

[lenebat796]

I can confirm this issue. I have following additional experience:

Sometimes it boots fine. But this is by less then 20% of the times when tried out. It never succeed when it failed once and automaticly tries again and you dont disconnect the DC-power in between. I can see that it tries to boot about 3 times and then tries to get something from tftp.

 

Here the logfile of an Odroid N2 with a 16GiB orange PCB eMMC module when it does not boot: https://pastebin.com/GCqk5PTV

And here is the logfile of the same N2 just a minute later with a different try: https://pastebin.com/dsjyfVhh

 

Example image tried out for those logfiles: https://imola.armbian.com/dl/odroidn2/archive/Armbian_22.05.2_Odroidn2_jammy_edge_5.17.5_cinnamon_desktop.img.xz

 

Maybe helpful to mention: I dont have any issues with current Manjaro Odroid N2 images.

Here the always working boot output of Manjaro on same hardware setup: https://pastebin.com/p46FsLrX

Image used: Manjaro-ARM-kde-plasma-on2-22.04.img

 

And maybe also helpful to mention: I did not have any issues with older armbian images that was build about half a year ago on the same hardware setup. Those was based on Impish and worked with the exception that the HDMI monitor goes off because of no signal after about a minute and you had to disconnect and reconnect it to have a working HDMI-output(it was same issue on different HDMI monitors). So the eMMC issue is a regression with the latest images. I have this bootissue with all now build images. It does not matter if Jammy, Bullseye or Focal. Something seems to have changed in the build process of the recent images.

[Igor]

13 minutes ago, lenebat796 said:

Something seems to have changed in the build process of the recent images.

Yes. We have decided to move away from dirty proprietary stock boot loader to most recent boot loader ... where not all troubles has been ironed out / quirks ported from factory firmware. I would assume only with (some?) eMMC. Perhaps @chewittknows something about this?

 

Reverting changes and forgetting about better security that comes with common / open / mainline represent some serious work / decisions and its questionable - you gain something, you loose something. We could go back, but not sure if that is the right way.

[lenebat796]

No, should be fixed upstream at u-boot and armbian helps at the moment to get aware of this existing issue.

Because it needs testing and its already partly broken now, maybe you could update the images to u-boot v2022.07-rc3 that is recently been released. Or at least to the latest stable release v2022.04.

[Igor]

4 minutes ago, lenebat796 said:

maybe you could update the images to u-boot v2022.07-rc3

I think you need to read FAQ and once you are done with updating and testing, make an integration request. Which is already a burden to the project but that you can cover with a donation.

[usual user]

10 hours ago, lenebat796 said:

maybe you could update the images to u-boot v2022.07-rc3

Alternatively, you can try the firmware (v2022.07-rc2), which I offered in this thread, with your image. At least, you can provide log files that facilitate analysis in the event of an error.

[MichaIng]

I can confirm this and posted a serial console log here: 

EDIT: Ah sorry, I see my logs just match the ones that have been posted here already. It's also the same orange 16 GiB eMMC module. I'll try with edge firmware and upstream U-Boot when I find time.

 

EDIT2: I cannot replicate ATM, but it indeed seems that it boots fine with at least one other eMMC module, reported by one of our users. Probably it's some sort of timing, i.e. the eMMC takes too long to become ready resp. the bootloader tries too early to read its partition table? The bootloader itself however was loaded successfully from that same eMMC obviously 🤔. I clearly lack if insights, just guessing around 😅.

Edited June 26, 2022 by MichaIng

[usual user]

12 hours ago, MichaIng said:

I clearly lack if insights, just guessing around

The firmware (uboot) is loaded by the maskrom code in the safest and slowest mode to use only minimal eMMC requirements. When uboot takes over, an attempt  is made to switch to a more efficient mode. If this does not succeed, it can  lead to the observed behavior. Since I don't know if more recent uboot  versions have already fixed a possible problem, I had offered my v2022.07-rc2  build for a quick test. Unfortunately, in the other thread it looked like the maskrom code couldn't even read the firmware blobs and without console logs  it's not really to analyze. So if you want, try v2022.07-rc2 it's a simple:

dd bs=512 seek=1 conv=notrunc if=u-boot-meson.bin of=/dev/${entire-card-device-to-be-used} ; sync

 

[MichaIng]

That works, awesome! 

 

Spoiler

U-Boot 2022.07-rc2 (May 21 2022 - 00:00:00 +0000) odroid-n2/n2-plus

Model: Hardkernel ODROID-N2
SoC:   Amlogic Meson G12B (S922X) Revision 29:c (40:2)
DRAM:  3.8 GiB
Core:  389 devices, 27 uclasses, devicetree: separate
MMC:   sd@ffe05000: 0, mmc@ffe07000: 1
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
Board variant: n2-plus
Net:   eth0: ethernet@ff3f0000
starting USB...
Bus usb@ff500000: Register 3000140 NbrPorts 3
Starting the controller
USB XHCI 1.10
scanning bus usb@ff500000 for devices... 4 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
8025 bytes read in 1 ms (7.7 MiB/s)
## Executing script at 08000000
U-boot default fdtfile: amlogic/meson-g12b-odroid-n2-plus.dtb
Current variant: n2-plus
For variant n2-plus (dash version, 2021.07 or up), set default fdtfile: amlogic/meson-g12b-odroid-n2-plus.dtb
112 bytes read in 1 ms (109.4 KiB/s)
Current fdtfile after armbianEnv: amlogic/meson-g12b-odroid-n2-plus.dtb
Mainline bootargs: root=UUID=351fe422-92cd-4cb9-bdf6-16b4b9225cc9 rootwait rootfstype=ext4 console=ttyAML0,115200 console=tty1 consoleblank=0 coherent_pool=2M loglevel=1 ubootpart=629e7b94-01 libata.force=noncq usb-storage.quirks=    cgroup_enable=memory swapaccount=1
13823913 bytes read in 302 ms (43.7 MiB/s)
26530304 bytes read in 580 ms (43.6 MiB/s)
77567 bytes read in 3 ms (24.7 MiB/s)
232 bytes read in 1 ms (226.6 KiB/s)
Applying kernel provided DT fixup script (meson-fixup.scr)
## Executing script at 32000000
## Loading init Ramdisk from Legacy Image at 13000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    13823849 Bytes = 13.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 04080000
   Booting using the fdt blob at 0x4080000
   Loading Ramdisk to 3f2d1000, end 3fffff69 ... OK
   Loading Device Tree to 000000003f255000, end 000000003f2d0fff ... OK

Starting kernel ...

 

It's still a release candidate (now RC5 is available), I guess it is not feasible to use it for a new Armbian N2 U-Boot package before being a stable release right? But great to have a workaround, many thanks!

[usual user]

1 hour ago, MichaIng said:

That works, awesome! 

Congratulations, I'm glad that it works for your usecase. Since I don't have an eMMC, it was just a shot in the dark, thanks for the confirmation that it also works with an eMMC.

 

1 hour ago, MichaIng said:

I guess it is not feasible to use it for a new Armbian N2 U-Boot package before being a stable release right?

Since the release is already near, it is not worth taking another intermediate step, since most likely nothing earth-shattering will be added in relation to ODROID-N2+:

Quote

v2022.07-rc5 are OUT / Merge Window is CLOSED, -next is OPEN / Release v2022.07 is scheduled for 4 July 2022

I could still offer v2022.07-rc4 as an upload if you like. The use of the rc version should have no meaning in relation to the ODROID-N2+ as long as no malfunctions are noticeable. And even if some mainline bug is identified, I don't think there is enough time to introduce a fix in the planned release.
By the way, I run the firmware only from the SPI flash, and in case of recovery from the SD card. In the end it's just:

dd if=u-boot-meson.bin of=/dev/mtd0 ; sync

 

[MichaIng]

I leave it to you whether a quicker RC-based release or little later stable-based release is feasible. I tested it with eMMC and SD card and it works pretty well. It does support being loaded from SPI flash as well? That is nice indeed, at least as backup bootloader, haven't tested this yet.

[usual user]

On 6/26/2022 at 7:46 PM, MichaIng said:

I leave it to you whether a quicker RC-based release or little later stable-based release is feasible.

I have nothing to decide here, if you want it to be in Armbian you have to convince an Armbian maintainer to pick it up. I also use Armbian only very sporadically for board bring-up and initial tests. Nevertheless, when the release has taken place, I will build a uboot-tools package for me and can, if you wish, upload the firmware.

 

On 6/26/2022 at 7:46 PM, MichaIng said:

It does support being loaded from SPI flash as well?

I use it to start my system from SD card or via USB connection. I don't see  any reason why it shouldn't work with eMMC, but you only know for sure if  you've tested it. For me it was the first action to replace Petitboot with  a mainline uboot.

You have to wait a little longer, see here.

Release v2022.07 has taken place and the uboot-tools package has been build. I am running the firmware from SPI flash and it is working flawless for me.
Since distro-boot is supported for free, the use of an extlinux.conf allows to select the current kernel, an previous one and a persistent one with the option to enable SPI flash for ODROID-N2 or ODROID-N2+. See the attached extlinux.conf as an example implementation.

Quote

Boot Options
1:      default Odroid-N2/Odroid-N2+
2:      previous Odroid-N2/Odroid-N2+
3:      Odroid-N2/Odroid-N2+ 5.18.0-60
4:      Odroid-N2 SPI FLASH
5:      Odroid-N2+ SPI FLASH
Enter choice:

More details can be extracted from this thread, with its distracting posts in between. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade will never leave an unbootable system behind as long as a previously working one is still installed.
So if someone wants to experiment with u-boot-meson.bin, you have to let me know and I will upload the file.

extlinux.conf

Edited August 6, 2022 by usual user

[einsteinx2]

I am also using an 16GB orange eMMC module with an Odroid-N2 on the latest version of Armbian (22.08 Bullseye, kernel 5.10.y) and was having a similar issue after running the `armbian-install` command from an SD card and installing to eMMC (hanging on boot, just showing a uboot logo). Booting from SD card worked fine.

 

I flashed the suggested uboot-meson v2022.07-rc2 version linked above to the eMMC and it's also working perfectly for me now booting directly from eMMC without any SD card inserted. I just wanted to post as another data point for anyone else that may come across this.

 

I assume at some point these newer uboot-meson versions will be included in the Armbian image (or maybe not? I have no idea how the Armbian release process works...), but until then, the linked version and dd command seems to resolve the issue even on the latest Armbian release.

 

 

[usual user]

5 hours ago, einsteinx2 said:

until then, the linked version and dd command seems to resolve the issue even on the latest Armbian release.

There is also 2022.07 GA available and if you insist I can also upload 2022.10 GA.

[einsteinx2]

Thanks! I flashed the GA version and can confirm it’s working perfectly as well.
 

No need for 2022.10 as 2202.07 is working fine, though if you don’t mind pointing me to the correct git repo I’m fine compiling them myself in the future as needed. I was trying to find it yesterday, but was having trouble as I’m not very familiar with uboot.

[usual user]

5 hours ago, einsteinx2 said:

No need for 2022.10 as 2202.07 is working fine

Since I have already uploaded 2022.10 GA at the request of someone else, it can be downloaded here if there is still a need.

 

5 hours ago, einsteinx2 said:

if you don’t mind pointing me to the correct git repo

The u-boot GitLab is here. But I am building from the release tar ball with a fedora toolchain.

In any case, you only get the u-boot.bin, which still has to be signed with the binary-only tools from the vendor u-boot tree and combined with the binary-blob artefacts to the FIP.
In the case of Armbian, surely the better solution is for someone to adjust the Armbian building system to a more recent version and issue a pull request so that the change can be integrated into Armbian. He will certainly reap the thanks of many happy Armbian users.

By the way, for another occasion I just verified that UEFI boot also works.
See console.log for reference.

Edited October 28, 2022 by usual user

[umiddelb]

On 10/28/2022 at 9:10 PM, usual user said:

No need for 2022.10 as 2202.07 is working fine

 

I've tested the 2022.10 GA u-boot. This working for the red coloured eMMC, but the orange coloured eMMC (the faster one) still has the same issue (unable to select a mode : -5). 

[usual user]

I just looked at this page. To me it looks as if the colors are used to distinguish which devices they are intended for and with which OS system they are supplied. For the N2 I see only two colors to distinguish between Linux and Android. All eMMCs marked in orange appear to be intended for other devices. Could it be that this is the reason why they do not work reliably with the N2?

[joekhoobyar]

Been using these 16GB ones from Ameridroid, and they've worked great on both my N2 and two XU4(s).

On latest Armbian stable release.

[umiddelb]

Both modules have worked in the past (BSP), the red module was made for the C2 while the other came with the N2 developer sample. At this time I'm quite happy that at least one eMMC module is working now. Thank you.

 

Just for the records, you need to write the firmware on emmc starting with sector 1 (instead of sector 0 for µSD):

sudo dd if=u-boot-meson.bin of=/dev/XXX conv=fsync bs=512 seek=1

 

[usual user]

14 hours ago, umiddelb said:

unable to select a mode : -5

This error message indicates to me that the module does not support a certain functionality.

 

5 hours ago, umiddelb said:

Both modules have worked in the past (BSP)

Mainline releases tend to be more advanced than outdated forks with out-of-tree hacks that have never been ported to mainline. Now, if Mainline uses new eMMC features that are not supported by a module and even the recovery attempt fails, the legacy firmware may work better in this case. It does not trigger this circumstance. Since mainline development does not rely on the support of a special module, it can lead to such failures to the advantage of other modules that support these functions. You can now try to determine the cause and then have a fix incorporated into mainline if necessary, but that's out of my interest, since I don't have any eMMC modules. I provided my firmware builds just to be able to do a quick test to see if a fix has already been added to mainline, saving you the hassle of building it yourself or waiting for it to become available in Armbian. I build the firmware for me for other reasons anyway.  This also saves Armbian the effort of quickly integrating a new version if there is no improvement anyway. But I think a prepared PR is still welcome to keep Armbian up to date if this does not lead to regressions.

 

5 hours ago, umiddelb said:

Just for the records, you need to write the firmware on emmc starting with sector 1 (instead of sector 0 for µSD)

This is not entirely true. The dd command is the same for microSD and eMMC except for the "of=" parameter. Both are MMC devices and the block device data structure (MBR) is identical, only the hardware interface used is different. But this is handled by the corresponding drivers and is not important from the user's point of view.
For SPI flash, that's a different story. SPI Flash does not necessarily use block device data structures and therefore the firmware range starts at offset zero. Therefore, the dd command for SPI flash looks like this:

dd conv=notrunc,fsync if=u-boot-meson.bin of=/dev/mtdblock0

Alternatively, you can also use "flashcp".

[Helmut]

@usual user Thank you for this workaround! I have had these mentioned boot problems with my N2 board recently. Uboot 2022.07 GA was the solution for me. At least it seems like it :-)

[einsteinx2]

As an additional data point, I went ahead and flashed the 2022.10 GA release to my N2 with orange 16GB eMMC, and so far it's working just as well as 2022.07 GA for me. Though not sure if there's any real benefit to 2022.10 over 2022.07 though if that version boots successfully, so if that seems to work for more people, probably makes sense to just stick with that. If I run into boot problems in the future, I'll roll back, but so far so good.

 

And fwiw Armbian has been super stable, which is why I was looking to switch in the first place. The official N2 builds from Odroid all use the old 4.9 kernel which is too old for Docker and Wireshark without workarounds, which were hard requirements for my use case. I tried a community made Debian build on the Odroid forums, but got a kernel panic overnight after just a day, and it was using EXT4 without LVM so harder to do snapshots without some workarounds, or manually trying to migrate to BTRFS and hope for the best. So I started looking for alternative Debian options and found Armbian, which has now been working fully stable for 3 days so far, though I'm continuing to actively monitor it. Plus the included Armbian eMMC install script made it really easy to use BTRFS, which I also wanted for snapshotted backups, which was icing on the cake.

 

Having working U-boot for eMMC booting was the missing piece for me to make the switch, so big thanks to @usual user for providing a potential solution and taking the time to post builds as well!

Edited October 31, 2022 by einsteinx2