Just received the Odroid N2+ today with 16gb eMMC for N2+ , I can install android or ubuntu on emmc and boot without any problem but when i tried to install dietpi i got black screen solid red light and no blue light , After i switch to SPI the blue light flashing but i only see the Petitboot 20220317 menu i don’t know what to do , Then i try to install on my 32gb microSD and switch back to MMC i can boot up the dietpi so only microSD works no eMMC , Anyone please help ?
Please switch the boot switch on the PCB from SPI to MMC. Our image does not support petitboot, respectively the other way round.
Yes i did but i got black screen on MMC without blue light blinking .
Hmm, I successfully run it on N2+ with eMMC here. I’ll also try to flash the new image.
PSU (and cable) is the original one? If you have peripherals attached, could you try to disconnect them?
Yes PSU emmc original from hardkernel.com just received the package today , It’s brand new i just opened the package actually , i am not sure why i cannot boot from eMMC only microSD works , Am i miss something before i flash the dietpi ?
There shouldn’t be any additional step required. If you tried without all peripherals, I’m not sure what the issue may be.
Did you get a UART adapter as well, so you can see early boot messages?
I’ll try to replicate when I’m back from work.
I finally can boot up dietpi on eMMC and install update everything works ok no error at all but after sudo reboot i can no longer boot again ?
Issue solved with a recent U-Boot build provided by usual user. New images have been uploaded.
Thanks for your help !
Release v2022.07 has taken place and the uboot-tools package has been build.
Since distro-boot is supported for free, the use of an extlinux.conf allows to select the current kernel, an previous one and a persitent one with the option to enable SPI flash for ODROID-N2 or ODROID-N2+. See the attached extlinux.conf as an example implementation.
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 v2022.07, you have to let me know and I will upload u-boot-meson.bin.
extlinux.conf.txt (1.8 KB)
1 Like
The only issue with extlinux is that one cannot add device tree overlays, AFAIK?
Also in some cases the exact device tree is based on the SBC variant and automatically chosen by U-Boot. I think with extlinux one must define the dtb explicitly and hence can only support a single board variant with an image?
But good to hear that the new version is up, we can skip the custom file injection for new images.
Fortunately, distro-boot does not follow your opinion, otherwise the same SD card would not work in all my devices and I would have great problems to be passed my changing overlay needs.
Which “all” devices do you mean? For Odroid N2 our images supports N2 and N2+, and probably the N2+ even boots with N2 device tree, but has lower-than-default CPU clocks and probably other limitations then.
With the fdtdir parameter the DTB is loaded which is requested by u-boot as default for the respective device:
Odroid-N2 => meson-g12b-odroid-n2.dtb
Odroid-N2+ => meson-g12b-odroid-n2-plus.dtb
Odroid-M1 => rk3568-odroid-m1.dtb
NanoPC-T4 => rk3399-nanopc-t4.dtb
HonyComb => fsl-lx2160a-honeycomb.dtb
Helios64 => rk3399-kobol-helios64.dtb
… => …
The fdt parameter enforces the DTB and it is the user’s duty to select the correct one.
E.g. meson-g12b-odroid-n2-plus-nor.dtb for SPI NOR FLASH support on the Odroid-N2+.
1 Like
Ah, nice, I didn’t know the fdtdir parameter. With this however you’d need to update extlinux.conf on every kernel upgrade, no big issue through. Not sure which kernel package you are using, but those paths do not match what the Armbian kernel package ships. It would either need to be /usr/lib/linux-image-$(uname -r)/amlogic/ there, or /boot/dtb/amlogic/ (shipped by the linux-dtb-* package, which doubles the device trees but provides a static path.)
So last issue then is the missing device tree overlay support, and that one cannot so easily to variable-dependant device tree adjustments, as can be done with a boot.scr (shell-like syntax) script: That way we can make it easier to e.g. enable a headless mode, support for LCDs and such, with a single setting.
With my approach, not even that is necessary.
By kernel package I mean all installed files belonging to a particular kernel version. It does not matter from which package system they were installed. The simplest form is a tar archive which only needs tar -C /usr/lib/modules/ -xzf 5.18.0-1.60.fc34.aarch64.tgz for installation.
How can you keep any number of kernels installed at the same time with the Armbian layout? But by simply copying some files, you can easily change that.
My approach only requires the manipulation of a symbolic link, I have to admit it can not quite keep up with boot.scr cryptic. Only general command line tools that should be available in every system.
Since all your previous doubted functions are already supported by my attached extlinux.conf, we should best start with some experiments on your site, and I will explain it when you use it. If you are interested in this, let me know and I will explain some necessary preparations for it.
Just to clarify: I aim to use the Armbian kernel und U-Boot packages unmodified. However, we anyway need to place kernel postinst/postrm scripts which are contained in their bsp package which we do not pre-install anymore, so placing the one or the other symlink and keeping them or the extlinux.conf updated that way wouldn’t be a big issue if it had sufficient benefits. Multiple kernel versions from the same bench (legacy, current, next) however are not possible.
What I still so not see with extlinux is support for device tree overlays, to toggle specific hardware features, overclock the device etc. But I might be wrong.
Another approach wound be to switch to the generic Debian kernel packages which do not provide device tree overlays anyway, so that I assume that all hardware features, like GPIO-based interfaces are enabled by default. But it limits flexibility like custom usage of pins when things like multiple I2C devices are blocking them, or the other way round those are wanted and cannot easily be enabled. Also Debian doesn’t skip U-Boot packages for all SBCs we support and we don’t have capacities to build, pack and distribute them ourselves.
If the functionality offered is enough for you, it is easily feasible. Just copy some files to /usr/lib/modules/${kernelversion} and customize a symbolic link. U-boot wise it is only extlinux.conf administration.
No problem for distro-boot, but with out-of-tree legacy kernel, the userspace may not play along.
As I said, everything is possible, only you have to learn new tricks. But this is best explained with learning by doing, step by step in the necessary order to understand the concept. You cannot derive the overall concept from a single example.
@greentea1 There has been a patch added to Armbian’s U-Boot sources which seem to be related to your eMMC boot issue: odroidn2: u-boot: fix eMMC stability · armbian/build@5c15e3f · GitHub
Would you mind to test this:
wget 'https://dietpi.com/downloads/binaries/testing/linux-u-boot-odroidn2-current.deb'
dpkg -i linux-u-boot-odroidn2-current.deb
source /usr/lib/u-boot/platform_install.sh
# Unmute output/errors
eval "$(declare -f write_uboot_platform | sed -e 's| > /dev/null 2>&1||g' -e 's|status=none|status=progress|g')"
write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"
But if it fails, you would need to flash the other U-Boot binary from another Linux system, to make it boot again 
.