Jump to content
  • 0

Odroid N2: Issues with recent firmware and emmc modules


umiddelb
 Share

Question

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.

 

Link to comment
Share on other sites

11 answers to this question

Recommended Posts

  • 0

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.

Link to comment
Share on other sites

Open source development is fun. Join Armbian Linux development team today!

  • 0
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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0

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 by MichaIng
Link to comment
Share on other sites

  • 0
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

 

Link to comment
Share on other sites

  • 0

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!

Link to comment
Share on other sites

  • 0
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

 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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 by usual user
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...