I did some research for a new CE/Kodi box and the recommendations often mentioned the N2+ so I bought one in the hope that it would be supported for quite a while. It was supplied with 9.2.8 on sd-card and I understood that 19.3 was supported now so was very disappointed to find that 19.3 seems not to be recognised.
I flashed the 19.3 stable build using Rufus onto two different sd-cards but neither will boot. I followed CoreELEC - Device Trees and copied the g12b_s922x_odroid_n2.dtb file into root and renamed it dtb.img, restarted but the box refuses to boot with either card - nothing happens on the display at all.
I noted that 19.3 has the same dtb file for both the normal N2 and plus versions whereas 9.2.8 has two different files, so not sure if that is relevant.
What am I doing wrong?
I tried the latest nightly (CoreELEC-Amlogic-ng.arm-19.4-Matrix_nightly_20211116-Odroid_N2.img.gz) on one of the sd-cards and that boots fine so it appears there’s something up with 19.3.
If you download the correct image, https://github.com/CoreELEC/CoreELEC/releases/download/19.3-Matrix/CoreELEC-Amlogic-ng.arm-19.3-Matrix-Odroid_N2.img.gz you don’t even need to do anything with the dtb’s because this image is only for the N2/N2+.
For me, Rufus was a pain in the butt, always. Try flashing with Balena Etcher, the guys from HK made a Balena variant optimized for Odroids.
See if that makes a difference. By the way, the SBC booting is set from SD card, wright?
For me Rufus is working pretty well, I´m using it many years to prepare USB ore SD card
I guess mr-b did something wrong.
The N2 files are working oob, nothing to do like copy and rename any dtb
Tx all for the quick suggestions.
Yes I’ve used Rufus for years also and never had an issue. Interested to know what exactly causes the PITA in Rufus and what the Odroid optimisation is with Balena Etcher?
The only related niggle I experienced recently is with Windows 10 which for some reason no longer automatically assigns a drive letter to the sd-card’s COREELEC FAT partition, even after reinsertion and ensuring that Virtual Disk Service is running.
RE: the correct image, I was just following the inst’ns at https://coreelec.org/#install which only has links to specific CE versions, even though they say “select the image file (.img.gz) for your device.” which kinda led me to believe there would be per-device images available. A link to those would help remove the potentially error-prone dtb file copy & rename step, though of course it involves more downloads/flashing steps if one selects the wrong image for the device (which apparently equally can be error prone). Swings and roundabouts I guess.
Either way, I tried the device specific 19.3 image and that worked fine first time - yay! So I (triple) checked the generic image, copied and renamed g12b_s922x_odroid_n2 to dtb.img in root, ejected card. The N2 doesn’t boot. (I’ve no idea how to check “SBC booting is set from SD card”). I couldn’t find any checksums generated for the generic image at Releases · CoreELEC/CoreELEC · GitHub - are they available?
I downloaded CoreELEC-Amlogic-ng.arm-19.3-Matrix-Generic.img.gz CRC32 3A4B5E94
The generic image won’t work on N2+, it’s not supposed to.
CoreELEC - Device Trees says:
“Odroid N2(+) S922X 4G g12b_s922x_odroid_n2”
Is there any advantage using Balena variant for HK devices instead of Rufus? Stability? Performance?
Balena for Odroid could be more of preference matter for some people (me included). With Rufus and some Balena Etcher variants I had some errors when flashing (could be bad sd cards).
Generic image won’t work, trust me. You need the bootloader included in the N2/N2+ image. Why are you trying to use generic?? What do you think you’ll gain from it?
Um, I was just following the simple instructions at https://coreelec.org/#install.
Please choose which version you would like to install.
The recommended installation for your living room is the latest stable version.
If you are brave enough and would like to test the newest developments,
you could pick the latest nightly version.
There was no “show me all download options” link.
But even if I had followed it, CoreELEC-Amlogic-ng.arm-19.3-Matrix-Odroid_N2.img.gz doesn’t mention the plus variant, so I would have just gone back to the simple instructions.
Why does CoreELEC - Device Trees mention “N2(+)” if the generic image does not work with it?
Your problem is solved and was explained to you. All the dtb’s are on that folder because that’s the way it’s built. You did not follow the instructions, pardon me. If you choose Odroid N2(+) from the helper it will download the N2(+) image. You downloaded the generic because you wanted, not because it was offered for the N2(+) by the helper. If there’s nothing wrong with your device/download, please mark this as solved. Thank you
Ok I’ve found the issue. I just tried following the 19.3 link again and the web page appears to have changed and now the Download Helper pops up, which I’d never seen before, and it allows me to select the device, which makes sense. However the Helper certainly did not appear before and it just downloaded the generic image. Indeed now even if I’d wanted to, I can’t even find a link to download the Generic image via the Helper.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.