umiddelb Posted April 3, 2022 Posted April 3, 2022 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. 0 Quote
lenebat796 Posted May 30, 2022 Posted May 30, 2022 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. 0 Quote
Igor Posted May 30, 2022 Posted May 30, 2022 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. 0 Quote
lenebat796 Posted May 30, 2022 Posted May 30, 2022 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. 0 Quote
Igor Posted May 30, 2022 Posted May 30, 2022 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. 0 Quote
usual user Posted May 30, 2022 Posted May 30, 2022 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. 0 Quote
MichaIng Posted June 25, 2022 Posted June 25, 2022 (edited) 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 0 Quote
usual user Posted June 26, 2022 Posted June 26, 2022 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 1 Quote
MichaIng Posted June 26, 2022 Posted June 26, 2022 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! 0 Quote
usual user Posted June 26, 2022 Posted June 26, 2022 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 0 Quote
MichaIng Posted June 26, 2022 Posted June 26, 2022 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. 0 Quote
usual user Posted June 26, 2022 Posted June 26, 2022 (edited) 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 1 Quote
einsteinx2 Posted October 27, 2022 Posted October 27, 2022 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. 0 Quote
usual user Posted October 27, 2022 Posted October 27, 2022 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. 0 Quote
einsteinx2 Posted October 28, 2022 Posted October 28, 2022 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. 0 Quote
usual user Posted October 28, 2022 Posted October 28, 2022 (edited) 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 0 Quote
umiddelb Posted October 29, 2022 Author Posted October 29, 2022 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). 0 Quote
usual user Posted October 30, 2022 Posted October 30, 2022 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? 0 Quote
joekhoobyar Posted October 30, 2022 Posted October 30, 2022 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. 0 Quote
umiddelb Posted October 30, 2022 Author Posted October 30, 2022 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 0 Quote
usual user Posted October 30, 2022 Posted October 30, 2022 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". 0 Quote
Helmut Posted October 31, 2022 Posted October 31, 2022 @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 :-) 0 Quote
einsteinx2 Posted October 31, 2022 Posted October 31, 2022 (edited) 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 0 Quote
Recommended Posts
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.