MichaIng
commented
1 year ago Has the SPI flash been erased? AFAIK there is a button at the downside of the device to force booting via MMC bootloader. Can you test this?
Open Power-onoff opened 1 year ago
MichaIng
commented
1 year ago Has the SPI flash been erased? AFAIK there is a button at the downside of the device to force booting via MMC bootloader. Can you test this?
Power-onoff
commented
1 year ago AFAIK Odroid C4 doesn't have a SPI flash
Board Layout : https://wiki.odroid.com/odroid-c4/hardware/hardware#board_layout
MichaIng
commented
1 year ago Ah, seems like only the HC4 has it. I didn't know that. Could you test the Armbian Bullseye image? Should be identical regarding bootloader and kernel: https://www.armbian.com/odroid-c4/
Power-onoff
commented
1 year ago I'll check and let you know right away
Power-onoff
commented
1 year ago Verified that there is no problem booting the Ambian Bullseye image
MichaIng
commented
1 year ago I just compared again both, they should be 100% identical regarding anything relevant for early boot stage. However, just yesterday I moved new builds in place, which contain a more recent kernel and bootloader (also newer than on Armbian image). Can you please test that one?
Do you have a USB-UART/serial adapter to review bootloader output?
Power-onoff
commented
1 year ago Yes, you have a USB-UART adapter.
I would appreciate it if you could tell me in detail what kind of test to do.
MichaIng
commented
1 year ago Just attach it when trying to boot so you see the early boot logs which should show where and why it fails.
Power-onoff
commented
1 year ago Just attach it when trying to boot so you see the early boot logs which should show where and why it fails.
MichaIng
commented
1 year ago U-Boot loads correctly but then it seems to try reading from eMMC or fails to read from SD card (from where it loaded U-Boot successfully before), not sure:
Card did not respond to voltage select! : -110
MMC Device 2 not foundIs there an eMMC module attached? If so, could you try to detach it and then boot?
Power-onoff
commented
1 year ago U-Boot loads correctly but then it seems to try reading from eMMC or fails to read from SD card (from where it loaded U-Boot successfully before), not sure:
Card did not respond to voltage select! : -110 MMC Device 2 not foundIs there an eMMC module attached? If so, could you try to detach it and then boot?
The result I mentioned is the result of the test with the eMMC module removed, that is, only the sdcard is connected
MichaIng
commented
1 year ago Hmm, currently there is no general boot issue reported with Odroid C4, but only that warn reboot does not work with latest U-Boot, an issue plaguing many of the meson64 boards with Armbian kernel. I'll check whether we can test an alternative U-Boot.
usual-user
commented
1 year ago I just attached my 2022.10 GA odroid-c4/hc4 firmware composition here. The mainline u-boot configuration seems to be derived from the n2 and also applies to the hc4.CONFIG_IDENT_STRING=" odroid-c4/hc4The TF-A components are selected according to the odroid-c4. Because I don't have a suitable device available, I can't check the functionality myself. So just run the "blank microSD card with firmware only" attempt and see what happens.
u-boot-meson.zip
MichaIng
commented
1 year ago Many thanks for providing this, let's see whether it boots more reliable than the current Armbian U-Boot build. I can imagine that it's similar to the Odroid N2 boot issues with some SD card and eMMC module models.
MichaIng
commented
1 year ago Since there was a U-Boot update in the meantime, @Power-onoff could you try this image?
If it still doesn't work for you, I'll generate one with usual-user's U-Boot build provided above. This worked well for Odroid N2 already.
Power-onoff
commented
1 year ago Since there was a U-Boot update in the meantime, @Power-onoff could you try this image?
If it still doesn't work for you, I'll generate one with usual-user's U-Boot build provided above. This worked well for Odroid N2 already.
Sadly, the boot still failed.
MichaIng
commented
1 year ago Actually I recognise that we flash the u-boot.bin differently, compared to Armbian. We do:
dd if=u-boot.bin of=<drive> bs=512 seek=1 conv=notrunc,fdatasynchence flash the second stage bootloader only after the MBR. Armbian does:
dd if=u-boot.bin of=<drive> bs=1 count=442 conv=fsync
dd if=u-boot.bin of=<drive> bs=512 skip=1 seek=1 conv=fsynchence flashes the file as well to the first stage bootloader into the MBR before the partition table. @usual-user is this correct that your U-Boot binary contains the second stage bootloader only, or is first stage U-Boot smart enough to find second stage U-Boot also 512 bytes later? Or I'm interpreting something wrong?
However, PR up and image builds running:
MichaIng
commented
1 year ago New images are ready: https://dietpi.com/downloads/images/testing/
Power-onoff
commented
1 year ago New images are ready: https://dietpi.com/downloads/images/testing/
I flashed it using balenaEtcher But it still failed to boot Did I make a mistake or miss anything?
DietPi_OdroidC4-ARMv8-Bullseye.img
DietPi_OdroidC4-ARMv8-Bookworm.img
MichaIng
commented
1 year ago Btw, no need to test the Bookworm image, if the Bullseye image does not boot. They share the exact same bootloader and kernel 😉.
Is it right that you have 3 USB devices attached? If so, does it make a difference when you detach all USB devices (apart from the UART adapter)?
Let's wait for @usual-user, whether the bootloader was flashed correctly, or whether first stage bootloader needs to be flashed. However, second stage is reached, based on output, I'd say.
Power-onoff
commented
1 year ago Is it right that you have 3 USB devices attached? If so, does it make a difference when you detach all USB devices (apart from the UART adapter)?
All tests were conducted with only power, LAN, UART, and SDcard connected I didn't connect any USB
usual-user
commented
1 year ago First of all, thank you very much for confirming that my firmware composition works. I am pleased that it works right away because after all I built the firmware only according to theoretical assumptions and on-target with a completely different tool-chain. And can't even verify the result myself. The logs indicate that everything is working as expected.
Let's wait for @usual-user, whether the bootloader was flashed correctly, or whether first stage bootloader needs to be flashed. However, second stage is reached, based on output, I'd say.
The firmware consists of several components than just the payload (u-boot). U-boot (BL33) is only the last component in the boot chain. The other boot artifacts (BL2, BL3X) are only available by Amlogic as binary-only. Therefore, all FIPs consist of the same TF-A components, which is also recognizable by the identical log messages up to the u-boot version message. Regarding the way the firmware is brought into place, I can only say that my firmware composition (FIP) only provides what the MASKROM code of the SOC requires and is placed at the entry point that the MASKROM code uses. But because now the TF-A artifacts are identical, and thus also their functionality, I can not say which code Armbian places in the MBR. However, it is not something that the MASKROM code of the SOC, TF-A or u-boot requires. Probably a legacy code artifact. But now to the real issue:
Card did not respond to voltage select! : -110
From the specification reference from the second post by @Power-onoff, I see:
Storage<----->1x Micro SD slot (DS/HS mode up to UHS-I SDR104)
From the initial post by @Power-onoff, I see:
Axxen microSDHC SK10 16GB TLC CLASS10 UHS-3
Here is my analysis: I don't know if there is a hardware limitation for the maximum UHS-I class or if only the necessary software support is missing, but the error message reflects exactly the facts. The fact that the firmware can be loaded from the card is due to the fact that the MASKROM uses the lowest common mode to use the greatest possible compatibility. Subsequent firmware may then try to use higher modes, which may not work. I would therefore recommend trying a maximum UHS-I class microSD card.
Power-onoff
commented
1 year ago Thank you for all your assistance
Here is my analysis: I don't know if there is a hardware limitation for the maximum UHS-I class or if only the necessary software support is missing, but the error message reflects exactly the facts. The fact that the firmware can be loaded from the card is due to the fact that the MASKROM uses the lowest common mode to use the greatest possible compatibility. Subsequent firmware may then try to use higher modes, which may not work. I would therefore recommend trying a maximum UHS-I class microSD card.
As you mentioned, we tested on the UHS-I class microSD card and confirmed that the login screen appears after booting.
Power-onoff
commented
1 year ago tested on the Silicon Power 64GB MicroSDXC UHS-1 Class10 microSD card and confirmed that the login screen appears after booting.
MichaIng
commented
1 year ago So the Odroid C4 is picky on SD cards. Not sure whether this is a hardware limitation or may be solved bootloader wise.
Now it would be interesting whether old C4 image boots on those two UHS-I cards as well, so whether #5959 does bring any benefit or not. Since you are the first to report boot issues with C4 (recently), I guess we can stick with the Armbian build. But good to have an alternative at hand, since it wouldn't be the first time that an Armbian U-Boot release broke booting, or made it less reliable, like recently on NanoPi R1.
I can not say which code Armbian places in the MBR. something that the MASKROM code of the SOC, TF-A or u-boot requires.
The first 446 bytes are traditionally used for the first stage bootloader, but not sure whether it is required for those meson SoCs, which are indeed the only ones where those bytes are flashed. Probably for ancient compatibility indeed.
Btw, I just compared both binaries, and there is a larger identical pattern in their code with a few KiB offset. And the offset of this pattern is exactly 512 bytes smaller in your case. So indeed Armbian's build does contain the MBR part (for whatever reason), while yours does not.
Power-onoff
commented
1 year ago Tested on the eMMC and confirmed that the login screen appears after booting.
Power-onoff
commented
1 year ago FILE: DietPi_OdroidC4-ARMv8-Bullseye.img DATE: Sun Nov 20 21:18:55 UTC 2022 MD5: b04895fe49136b5b172eca4b91fc9bf0 SHA1: c5ec31de0d164a5d087eee4b544a0c76f6fbfdc5 SHA256: ce7dac9ebffda21891e75d7f70f33fcfed2ece49e4f4ed472969ee93e217a21f
microSD card: Sandisk 16GB MicroSDHC UHS-1 Class10
confirmed that the login screen appears after booting.
Power-onoff
commented
1 year ago One of the things I mentioned was a mistake
Correct UHS-3 to UHS-1(U3)
"Axxen microSDHC SK10 16GB TLC CLASS10 UHS-3" >> "Axxen microSDHC SK10 16GB TLC CLASS10 UHS-1(U3)"
Here is my analysis: I don't know if there is a hardware limitation for the maximum UHS-I class or if only the necessary software support is missing, but the error message reflects exactly the facts. The fact that the firmware can be loaded from the card is due to the fact that the MASKROM uses the lowest common mode to use the greatest possible compatibility. Subsequent firmware may then try to use higher modes, which may not work. I would therefore recommend trying a maximum UHS-I class microSD card.
Power-onoff
commented
1 year ago FILE: DietPi_OdroidC4-ARMv8-Bullseye.img DATE: Sun Nov 20 21:18:55 UTC 2022 MD5: b04895fe49136b5b172eca4b91fc9bf0 SHA1: c5ec31de0d164a5d087eee4b544a0c76f6fbfdc5 SHA256: ce7dac9ebffda21891e75d7f70f33fcfed2ece49e4f4ed472969ee93e217a21f
microSD card: Axxen microSDHC SK10 16GB TLC CLASS10 UHS-1(U3)
Strangely, boot fails only on certain microSD cards Btw, I checked that it works fine on the rest except for some SD cards
MichaIng
commented
1 year ago Okay, so it fails to boot from Axxen microSDHC SK10 16GB TLC CLASS10 UHS-1(U3) with any image and succeeds to boot from any other SD card you tested, right?
Then for now I don't see a reason to switch U-Boot, but good to have it in mind and available, in case we find cases where one boots but the other not.
MichaIng
commented
1 year ago Many thanks for all your tests btw! Since I don't have a C4 myself, this is very valuable!
usual-user
commented
1 year ago As it looks now, the firmware has a problem with the use of class UHS-1(U3) microSD cards.
u-boot-meson.zip
I would like to see the result of a small experiment. Replace the firmware on the failing microSD card with the unpacked attached one:
dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${$MEDIA}
Post the serial console log with this firmware used.
Power-onoff
commented
1 year ago As it looks now, the firmware has a problem with the use of class UHS-1(U3) microSD cards. u-boot-meson.zip I would like to see the result of a small experiment. Replace the firmware on the failing microSD card with the unpacked attached one: dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${$MEDIA} Post the serial console log with this firmware used.
FILE: DietPi_OdroidC4-ARMv8-Bullseye.img DATE: Sun Nov 20 21:18:55 UTC 2022 MD5: b04895fe49136b5b172eca4b91fc9bf0 SHA1: c5ec31de0d164a5d087eee4b544a0c76f6fbfdc5 SHA256: ce7dac9ebffda21891e75d7f70f33fcfed2ece49e4f4ed472969ee93e217a21f
microSD card: Axxen microSDHC SK10 16GB TLC CLASS10 UHS-1(U3)
Executed a command in the dietpi virtualbox dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/sdc
usual-user
commented
1 year ago Damn, I wanted to apply a patch for the experiment, but fat finger typed the name and it's missing. Can you redo the experiment with this attached one? u-boot-meson.zip
Power-onoff
commented
1 year ago I don't know if it's helpful information, but it's the result of installing several OS images on a micro sd card that couldn't boot
Boot failed
Boot Successful
MichaIng
commented
1 year ago The images which succeed are all with the same vendor bootloader. So it's a limitation of the mainline U-Boot. As always, sad that manufacturers do not commit their necessary bootloader (same with kernel) support upstream in the first place, but keep maintaining an own fork, usually without ever updating (just patching) it 😞.
In the meantime, Meveric switched to mainline kernel and U-Boot as well. I guess his newer C4 image fail the same way: https://oph.mdrjr.net/meveric/images/Bullseye/
Power-onoff
commented
1 year ago Damn, I wanted to apply a patch for the experiment, but fat finger typed the name and it's missing. Can you redo the experiment with this attached one? u-boot-meson.zip
FILE: DietPi_OdroidC4-ARMv8-Bullseye.img DATE: Sun Nov 20 21:18:55 UTC 2022 MD5: b04895fe49136b5b172eca4b91fc9bf0 SHA1: c5ec31de0d164a5d087eee4b544a0c76f6fbfdc5 SHA256: ce7dac9ebffda21891e75d7f70f33fcfed2ece49e4f4ed472969ee93e217a21f
microSD card: Axxen microSDHC SK10 16GB TLC CLASS10 UHS-1(U3)
Executed a command in the dietpi virtualbox dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/sdc
Power-onoff
commented
1 year ago The images which succeed are all with the same vendor bootloader. So it's a limitation of the mainline U-Boot. As always, sad that manufacturers do not commit their necessary bootloader (same with kernel) support upstream in the first place, but keep maintaining an own fork, usually without ever updating (just patching) it 😞.
In the meantime, Meveric switched to mainline kernel and U-Boot as well. I guess his newer C4 image fail the same way: https://oph.mdrjr.net/meveric/images/Bullseye/
Tested the image file "Debian-Bullsey64-1.0-20221003-C4.img.xz" and successfully booted.
MichaIng
commented
1 year ago U-Boot 2015.01 (Aug 07 2020 - 08:55:43)
Ah, only mainline kernel but vendor U-Boot it seems.
usual-user
commented
1 year ago OK, had found this fix that was applied to mainline DT but has not yet been incorporated into mainline u-boot. Yes, I dubblechecked that it's really included in my second test build, but it doesn't seem to make any difference. An incorrectly wired IO line for regulator control would have been a good explanation as the cause of the error. Unfortunately, I can't really help under these debugging conditions (no corresponding device for locale investigations) any further. So we have to wait until a mainline solution becomes available. Of course I can then provide a new firmware build as an early adoption.
MichaIng
commented
1 year ago @usual-user Many thanks for all your help and builds. Sooner or later I will have to setup U-Boot and kernel build workflows as well, I guess.
I will ask Hardkernel for developer samples. Not sure if they will still send a C4, but probably an M1 or future SBC ones in pipeline.
Until then or generally, we should bring this up in Odroid forum: https://forum.odroid.com/viewforum.php?f=203
usual-user
commented
1 year ago Many thanks for all your help and builds.
You're welcome. It's also a bit self-serving, it confirms to me that fedora also works out-of-the-box on devices I don't own, as long as there's a firmware that can boot the operating system. And fedora is not even designed for a specific device, but only generically compiled for the aarch64 architecture. So one image fits everyone.
I will ask Hardkernel for developer samples. Not sure if they will still send a C4, but probably an M1 or future SBC ones in pipeline.
This is not a good choice. The HC4 is better, because as I noticed in the meantime, there is a separate odroid-hc4_defconfig with additional storage media enabled. The C4 u-boot should also work on the HC4, but cannot read the boot configuration from the additional storage media offered by the HC4. However, this makes the HC4 suitable for checking the function of both firmwares.
The M1 is currently only recommended for developers who want to contribute to mainline support. With kernel 6.2.0-rc1 all code available for the M1 will be available out-of-the-box. Further support code has yet to be written. Userspace support is also available with current mainline releases. The only exception is FFmpeg, where v4l2-request support is still missing. But it's not too bad at the moment, because the rkvdec2 kernel driver is still missing.
All in all, the M1 is already very well supported out-of-the-box with a current mainline operating system. Some older devices still need a lot of out-of-tree patches for equivalent support.
But when it comes to u-boot, so far only the legacy BSP fork from 2015 is available.
TF-A support is progressing slowly. And for u-boot no mainline code has been posted yet. There are only a few incomplete out-of-tree hacks for other rk3568 devices.
I'm using an Armbian build as boot trampoline, but as the BSP version gets probably no development and feature backports, no reason to build it myself. So it will take some time, but something is always ;-)
Until then or generally, we should bring this up in Odroid forum
In my experience, Hardkernel doesn't have much interest in mainline contributions and only supports lagacy outdated BSP implementations. But maybe constant dripping hollows the stone? Pine64 does a much better job, at least they document the current mainline support very carefully and I am very grateful to the developers for contributing their code to mainline. Without their work, the support of the Odroid-M1 by simply adding an M1 board DTS would not have been possible. And this was not even led by Hardkernel, but a nice example of what little effort (board DTS) is necessary to support a new device if there is sufficient mainline SOC support.
MichaIng
commented
1 year ago Good point about C4 vs HC4. It has an SPI flash indeed to boot from. We already know the issues with petitboot stored on it by Dee default, which has only limited boot.scr syntax support. The downside of HC4 is that it's headless and hence media features cannot be tested.
Exactly that M1 isn't so well supported yet is a good reason to have the board to test images with while finding proper builds and configs, even without doing own bootloader and kernel builds.
Hardkernel won't help with the U3 SD card issue, but probably someone from the community does 🙂.
usual-user
commented
1 year ago The downside of HC4 is that it's headless and hence media features cannot be tested.
If I don't misread the specification, the HC4 is also equipped with an HDMI port, so what are you missing?
Exactly that M1 isn't so well supported yet is a good reason to have the board to test images with while finding proper builds and configs, even without doing own bootloader and kernel builds.
The bigger problem for Debian based systems is the use of outdated software versions for "stability reasons". The aarch64 SOC architecture is bleeding edge development and cannot be efficiently driven by software designed for the x86 IBM architecture. Users must be willing to learn new things and use others as the familiar ones from the x86 architecture. But who can teach old dogs new tricks. Just look at how desperately they try to emulate a x86 boot schema, although better is possible. For example, there's no need for a boot partion or a /boot directory, this is a x86 BIOS constraint. But they seem to love how it breaks with conflicting file locations every now and then. Or how they want to use hardware video acceleration via the GPU. A WEB browser designed with this in mind will never work efficiently on a SOC architecture with separate VPUs. Yes SOCs can have several VPUs. The rk356x currently lacks rkvdec2 kernel support, but when it becomes available, it will be on par with many other SOCs and ready for the media desktop. But everything else is already possible today with an up-to-date desktop environment.
MichaIng
commented
1 year ago Oh you're right, the HC4 has HDMI, how could I miss that.
While with x86_64, things are indeed still easier IMO in the meantime, aarch64 has established quite well and is taken into account by most software developers. About e.g. GPU usage efficiency I cannot say something, but on modern mid- to high class SBCs Kodi and Chromium alike works quite well and generally an ARM server is overall more efficient compared to an x86_64 machine. However focus of DietPi is anyway a little more on server applications than on GUI applications.
Creating a bug report/issue
Required Information
cat /boot/dietpi/.versionecho $G_DISTRO_NAME $G_RASPBIANuname -aecho $G_HW_MODEL_NAMEor (EG: RPi3)Additional Information (if applicable)
echo $G_HW_UUIDSteps to reproduce
Expected behaviour
Actual behaviour
Extra details
In order to remove the existing Debian buster version and install the bullseye version, I formatted the MicroSD card and installed it using balena Etcher And turn the power to remove all connectors, except the power and hdmi odroid c 4 does not do anything and still. Odroid wiki in Ubuntu use images to operate normally by installing, using a etcher Please help me with the installation of odroid c4 dietpi
When odroid c4 is running with Ubuntu image, the blue LED is blinking MicroSD card with dietpi image does not blinking LED