Armbian: HC4 does not recognize SATA HDDs

[DRuf]

Hi guys,

I installed the latest Armbian (Buster) release for my Odroid HC4 and - after getting rid of Petitboot as that just wouldn't let me boot the image - it's working great so far. Only big problem I have is that it does not recognize any SATA devices, in neither of the two slots.

I tried different HDDs / SSDs that I verified are recognized on a Windows PC and another Ubuntu PC.

Did anyone get that working already? I assume the required Kernel drivers for the PCIe-Sata-chip are probably still missing.

Armbianmonitor: http://ix.io/2FlU

Many thanks and best regards

Daniel

[peppoonline]

I have exactly the same problems with the official Armbian Buster image... works and boots perfectly, but only the SDcard is recognized.

[DRuf]

I did some googling and found that the SATA chipset of the HC4 seems to be quite unsuported in Linux because it apparently reports as an IDE device instead of an AHCI device.

https://superuser.com/questions/363144/ ... nder-linux


That might be part of the reason why it doesn't find a correct driver.

Is there really no one using the HC4 with Armbian?

[DRuf]

I think Armbian developers didn't configure the Kernel device-tree files properly.
If they set it correctly, the SATA ports should work out of the box like meveric's Debian Buster or our Ubuntu OS images.
viewtopic.php?p=313206#p313206

[DRuf]

Thanks @odroid,

I think so too, but in fact I tried to build my own Armbian image & kernel from trunk. While doing that, I have included the SATA & AHCI kernel modules, but that didn't work. But might also be a problem on my side.

For reference, I have also created a thread on Armbian forum and I'm hoping that an Armbian Dev will fix this in a next Armbian build: https://forum.armbian.com/topic/16088-o ... sata-hdds/

For now, I will try Meveric's Debian Buster image (which at least for me wasn't booting with Petitboot, maybe it works without)

[igorpec]

I think Armbian developers didn't configure the Kernel device-tree files properly.

We distribute Armbian also with your private 4.9.y kernel and those builds should work the same as any other build, but OP is interested in a modern kernel support which is usually a bit more expensive and complicated to provide.

Code: Select all

[    0.000000] Linux version 5.9.6-meson64 (root@xeon) 

Obvious its something wrong, but we don't even have this hardware (0 out of 2 required as minimum) and we have no intention or reason to (dry) debug this problem anytime soon. We marked HC4 support as CSC (community supported configuration), users can enjoy Armbian with a kernel 4.9.y until fix shows up.

[igorpec]

Thanks @odroid,

I think so too, but in fact I tried to build my own Armbian image & kernel from trunk. While doing that, I have included the SATA & AHCI kernel modules, but that didn't work. But might also be a problem on my side.

For reference, I have also created a thread on Armbian forum and I'm hoping that an Armbian Dev will fix this in a next Armbian build: https://forum.armbian.com/topic/16088-o ... sata-hdds/

For now, I will try Meveric's Debian Buster image (which at least for me wasn't booting with Petitboot, maybe it works without)

Is this working for you:
https://imola.armbian.com/dl/odroidhc4/ ... 241.img.xz

[DRuf]

Hi Igor,

thanks for the explanation on the 4.9 Kernel - I wasn't aware that that is the proprietary Odroid-Kernel, i just thought it's simply an older one..
Then It would make a lot of sense if that Kernel would work.

I will try it this evening and give feedback.

[DRuf]

The 4.9 Armbian image is not working (the Archive one in the link above) is not booting for me and the current "stable" 4.9 debian image from the Armbian download page does not recognize the HDDs.

Switching to Meveric's Debian image now.

[odroid]

Also consider @tobetter's Debian Buster if you need a modern kernel 5.9. It supports Panfrost GPU driver too.

[igorpec]

Should be fixed with today's update:
https://www.armbian.com/odroid-hc4/

Benefits from other images:
- mainline u-boot based 2020.10 ->
- mainline kernel based 5.9.12 ->
- support for ZFS (install headers from armbian-config , apt install zfs-dkms; next build will have build-in support for ZFS)
- its Armbian

Ubuntu Groovy (20.10) or Debian Buster ... or anything you like if you DIY https://github.com/armbian/build

[Jschoeck]

Still not working with Petiteboot though.
@odroid: any plans to modify the boot config in Petiteboot in a way that recognizes more functioning bootable systems (like Armbian)?

[tobetter]

Still not working with Petiteboot though.
@odroid: any plans to modify the boot config in Petiteboot in a way that recognizes more functioning bootable systems (like Armbian)?

I've quickly look into the Armbian image and look like it's not possible to support Armbian in the near future since Armbian uses advanced features with mainline U-boot and kernel. Their boot script is a bit complicated than other OS images I know and need much time to make the Petitboot to recognize the boot script to make it boot with their advanced features. One way to use the Armbian on HC4 is to remove the Petitboot and boot with Armbian OS image from SD card using their boot loader.

[igorpec]

advanced features with mainline U-boot and kernel. Their boot script is a bit complicated than other OS images I know and need much time to make the Petitboot to recognize the boot script to make it boot with their advanced features.

It has boot.ini integrated in and its divided into legacy and mainline boot way. We can move parameters out to the env file, but I guess that will not help. Since modern kernel boots on a bit different way, we have little options. Any idea for a workaround on our side to meet petitboot?

One way to use the Armbian on HC4 is to remove the Petitboot and boot with Armbian OS image from SD card using their boot loader.

What is the most noob friendly way to do that?

[tobetter]

advanced features with mainline U-boot and kernel. Their boot script is a bit complicated than other OS images I know and need much time to make the Petitboot to recognize the boot script to make it boot with their advanced features.

It has boot.ini integrated in and its divided into legacy and mainline boot way. We can move parameters out to the env file, but I guess that will not help. Since modern kernel boots on a bit different way, we have little options. Any idea for a workaround on our side to meet petitboot?

The problem is not kernel parameter, but the commands in the script. Armbian uses mainline kernel and manage the default env values whilist Petitboot for ODROID-N2/HC4 are fully tied to legacy U-boot, so some commands in the script does not run properly to decode the boot script and Armbian uses the single partition layout OS image which is also the problem. The single partition OS image does not work at all even from mine or customized Hardkernel image.

One way to use the Armbian on HC4 is to remove the Petitboot and boot with Armbian OS image from SD card using their boot loader.

What is the most noob friendly way to do that?

viewtopic.php?p=311902#p311902

[igorpec]

The problem is not kernel parameter, but the commands in the script. Armbian uses mainline kernel and manage the default env values whilist Petitboot for ODROID-N2/HC4 are fully tied to legacy U-boot, so some commands in the script does not run properly to decode the boot script and Armbian uses the single partition layout OS image which is also the problem. The single partition OS image does not work at all even from mine or customized Hardkernel image.

So we are hitting the limits of Petitboot. I updated our instructions with the necessary info to proceed. Thanks!

[chewitt]

@tobetter is there a plan to send the device-tree upstream and (then) add support to mainline u-boot?

[tobetter]

@tobetter is there a plan to send the device-tree upstream and (then) add support to mainline u-boot?

I would sort out a couple patches for C4 and HC4 for upstream kernel but no please for U-boot yet.

[rpardini]

Quick question, on the HC4, if I clear Petitboot, could I install and run Armbian from an eMMC module (not SD)?
SATA ports would be used for separate storage only.

[tobetter]

Quick question, on the HC4, if I clear Petitboot, could I install and run Armbian from an eMMC module (not SD)?
SATA ports would be used for separate storage only.

There is no eMMC port on HC4, only SD is available.

[mad_ady]

It might boot from an emmc, if connected with the sd2emmc adapter, on the sd port... But it hangs out precariously...

[rpardini]

There is no eMMC port on HC4, only SD is available.

Thanks! I just assumed HC4 would be similar to C4...
In this case it seems the C4 has the SPI flash sharing a GPIO with eMMC, which caused that SPI was only writable before initializing the eMMC... (eg, at petitboot-level, but not Ubuntu). You sure know what I'm talking about.
If the HC4 has no eMMC, then this conflict should not exist in HC4, and we could get a DTB with the SPI flash exposed to Ubuntu, or I am going too far? (Would allow for configuring PetitBoot fw from Ubuntu and others)
I tried grabbing the DTB/DTS from Petitboot (which has the partition tables for the SPI flash) and adapting it for 5.10.y series, but with no success, is it a waste of time?

Maybe related: I've been having a lot of trouble with SDCard when booting the SD via PetitBoot: "mmc0: error -110 whilst initialising SD card". If I hold the boot switch, and let it boot straight from SD, everything works...

[tobetter]

There is no eMMC port on HC4, only SD is available.

Thanks! I just assumed HC4 would be similar to C4...

Yes.

In this case it seems the C4 has the SPI flash sharing a GPIO with eMMC, which caused that SPI was only writable before initializing the eMMC... (eg, at petitboot-level, but not Ubuntu). You sure know what I'm talking about.

C4 does not have SPI flash memory while N2 has. Only N2/HC4 has SPI flash for booting. SPI flash memory shares the bus with eMMC, so if they are exclusively enabled in the kernel any of them can be accessible any time.

If the HC4 has no eMMC, then this conflict should not exist in HC4, and we could get a DTB with the SPI flash exposed to Ubuntu, or I am going too far? (Would allow for configuring PetitBoot fw from Ubuntu and others)

No, DTB is not same over all Linux version. DTB in the SPI flash memory is for the Petitboot which uses 4.9 kernel and it cannot be booted for the upstream kernel like 5.4 or 5.9/5.10. They are totally different. This does not allow the Petitboot to configure the device tree for any OS. Therefore the device tree blob must come with the OS image to boot on HC4.

I tried grabbing the DTB/DTS from Petitboot (which has the partition tables for the SPI flash) and adapting it for 5.10.y series, but with no success, is it a waste of time?

Yes, do not try this..it's totally waste of time. The reason is explained.

Maybe related: I've been having a lot of trouble with SDCard when booting the SD via PetitBoot: "mmc0: error -110 whilst initialising SD card". If I hold the boot switch, and let it boot straight from SD, everything works...

When the error happens, are you able to boot an OS from the Petitboot or not? The error could not be related to SD card at all.

[rpardini]

C4 does not have SPI flash memory while N2 has. Only N2/HC4 has SPI flash for booting. SPI flash memory shares the bus with eMMC, so if they are exclusively enabled in the kernel any of them can be accessible any time.

Interesting. Thanks for the explanations.

Yes, do not try this..it's totally waste of time. The reason is explained.

Yes, I dunno why I chased after this... it seems the real problem is below.

Maybe related: I've been having a lot of trouble with SDCard when booting the SD via PetitBoot: "mmc0: error -110 whilst initialising SD card". If I hold the boot switch, and let it boot straight from SD, everything works...

When the error happens, are you able to boot an OS from the Petitboot or not? The error could not be related to SD card at all.

The scenario is as follows:
- Boot brand-new HC4 into PetitBoot with an empty SD card. Update PetitBoot with pb_update, etc.
- Install 20.04/5.10.x via netboot_default into the SD card (sloooow but works) -- BTW amazing work on netboot, thanks!
- After install, reboots into PetitBoot, which then tries to boot from the SD, outputs "mmc0: error -110 whilst initialising SD card" repeatedly and Ubuntu kernel does not boot.
- Waste a night chasing after what I thought were bad/old/damaged SD cards. Not so! (F3 tested)
- Power off the HC4, hold the boot switch underneath the board, power on, Ubuntu boots straight from SD, no errors, SD (and everything else) works.
- Reboot again, into PetitBoot, again does not work.
- Reboot again, into PetitBoot, sometimes (maybe 1 out of 10 tries) it does boot and work.
- Reboot with Boot Switch skipping PetitBoot, always works (10 out of 10 times).

A separate scenario:
- HC4 with SATA SSD, no SD. Netboot install Ubuntu 20.04/5.10.x to SATA. Heaven. Thanks!
- Power off HC4. Insert SD, any SD in the slot. Boot into PetitBoot, and then Ubuntu SATA SSD: cannot access the SD in Ubuntu, same error ("mmc0: error -110 whilst initialising SD card") appears, but indeed the OS does boot. But SD card does not work.
- Power off HC4. Remove SD from the slot. Boot into PetitBoot, and then Ubuntu SATA SSD. Heaven. Then insert the SD after Ubuntu booted: works perfectly, no errors, can use SD normally.

I hope those clarify a bit.
This is not a deal breaker for me, just trying to understand how things work pre-deployment.
My "production" scenario will use PetitBoot and boot/root from SATA SSD, which is many orders of magnitude faster than SD.

Thanks again for all the work! BTW I sent you a Pull Request from another topic. https://github.com/tobetter/linux/pull/21

[igorpec]

boot/root from SATA SSD, which is many orders of magnitude faster than SD

Armbian universal way which works on all boards the same way is that we load kernel files from boot media (eMMC / SD) and the rest from SSD / NvME / USB. Loading kernel image is sequential read which means it always performs at a maximum SD card / interface speed. Booting everything from SSD vs this way is not noticeable diff. But I agree its fancier to boot from SPI if exists and works properly ... but is usually not present on all hardware and its sometimes too small to carry big loaders. Also I think it doesn't yet support loading Armbian.

[tobetter]

C4 does not have SPI flash memory while N2 has. Only N2/HC4 has SPI flash for booting. SPI flash memory shares the bus with eMMC, so if they are exclusively enabled in the kernel any of them can be accessible any time.

Interesting. Thanks for the explanations.

Yes, do not try this..it's totally waste of time. The reason is explained.

Yes, I dunno why I chased after this... it seems the real problem is below.

Maybe related: I've been having a lot of trouble with SDCard when booting the SD via PetitBoot: "mmc0: error -110 whilst initialising SD card". If I hold the boot switch, and let it boot straight from SD, everything works...

When the error happens, are you able to boot an OS from the Petitboot or not? The error could not be related to SD card at all.

The scenario is as follows:
- Boot brand-new HC4 into PetitBoot with an empty SD card. Update PetitBoot with pb_update, etc.
- Install 20.04/5.10.x via netboot_default into the SD card (sloooow but works) -- BTW amazing work on netboot, thanks!
- After install, reboots into PetitBoot, which then tries to boot from the SD, outputs "mmc0: error -110 whilst initialising SD card" repeatedly and Ubuntu kernel does not boot.
- Waste a night chasing after what I thought were bad/old/damaged SD cards. Not so! (F3 tested)
- Power off the HC4, hold the boot switch underneath the board, power on, Ubuntu boots straight from SD, no errors, SD (and everything else) works.
- Reboot again, into PetitBoot, again does not work.
- Reboot again, into PetitBoot, sometimes (maybe 1 out of 10 tries) it does boot and work.
- Reboot with Boot Switch skipping PetitBoot, always works (10 out of 10 times).

A separate scenario:
- HC4 with SATA SSD, no SD. Netboot install Ubuntu 20.04/5.10.x to SATA. Heaven. Thanks!
- Power off HC4. Insert SD, any SD in the slot. Boot into PetitBoot, and then Ubuntu SATA SSD: cannot access the SD in Ubuntu, same error ("mmc0: error -110 whilst initialising SD card") appears, but indeed the OS does boot. But SD card does not work.
- Power off HC4. Remove SD from the slot. Boot into PetitBoot, and then Ubuntu SATA SSD. Heaven. Then insert the SD after Ubuntu booted: works perfectly, no errors, can use SD normally.

I hope those clarify a bit.
This is not a deal breaker for me, just trying to understand how things work pre-deployment.
My "production" scenario will use PetitBoot and boot/root from SATA SSD, which is many orders of magnitude faster than SD.

Thanks again for all the work! BTW I sent you a Pull Request from another topic. https://github.com/tobetter/linux/pull/21

That's strange...can you let me know the brand/model of your SD card? If possible, product link of you SD would be great.
Booting from SSD is way faster than SD if the OS boots properly and personally I prefer to boot from SSD since SD is slow and not safe for OS.

I reviewed your PR, thank you for the contribution, but I will change your PR - will merge two patches into one since 2nd patch is to fix the 1st patch and the format of your change is to be improved. Once I test the patch - my eye reviews yours anyway - I will merge it to 5.10. Thanks again!!

[rpardini]

I reviewed your PR, thank you for the contribution, but I will change your PR - will merge two patches into one since 2nd patch is to fix the 1st patch and the format of your change is to be improved. Once I test the patch - my eye reviews yours anyway - I will merge it to 5.10. Thanks again!!

No, thank you -- I'm just dabbling.
Yes, 2 commits (first a working copy from blue, the second red-specific adjustments).
See the patch here https://github.com/tobetter/linux/pull/21
In Github Web you can "squash" them together before merge (rebase), change the message, etc; (green button for merge has options)
I tested all triggers with red and seems stable. Now if only we could turn off the SATA light (and UART led!) the same way for a truly dark mode

@igorpec -- I bet the same patch applies clean to Armbian too, from 5.5.y maybe, but 5.10.y for sure.

CoreELEC Kodi even has a UI for the blue led; I'll investigate hacking there to add the red led if more folks agree on this patch -- @odroid?

[rpardini]

boot/root from SATA SSD, which is many orders of magnitude faster than SD

Armbian universal way which works on all boards the same way is that we load kernel files from boot media (eMMC / SD) and the rest from SSD / NvME / USB. Loading kernel image is sequential read which means it always performs at a maximum SD card / interface speed. Booting everything from SSD vs this way is not noticeable diff. But I agree its fancier to boot from SPI if exists and works properly ... but is usually not present on all hardware and its sometimes too small to carry big loaders. Also I think it doesn't yet support loading Armbian.

Ahn, ok, interesting. I had not gotten to that point with Armbian. I used the same scheme ("SD bootdisk with dtb overlays/kernel/initrd only") with RPi4 and USB3, but due to "USB stuff" it is quite unreliable. At least for heavy I/O load.
I will investigate Armbian further! I was scared away from flash_eraseall I think, but it seems there is a failsafe SD that can restore SPI.

I've built and deployed CoreELEC and Armbian on very old S912 boards, using SD for deploy and eMMC for runtime, somewhat successfully, but with legacy kernel. Mostly small containers with little I/O.
I'd rather stick to mainline, due to Panfrost-hope, qemu/kvm on aarch64 and containerd stuff, but I need ffmpeg hwaccelerated transcode, etc etc, the whole saga with Mali.

This HC4 toaster with its SATA ports is a very interesting design. 3 HC4's, 3 NAS HDD, 3 SSDs, and you have a very decent 3-node Ceph/EdgeFS storage cluster with compute to spare for Kubernetes etcd multi-master and some containers. With @tobetter 's builds I can have some mainline nodes, and some legacy 4.9+binary-blob for GPU work nodes with very little effort (provision a node under 20 minutes). I only wish these boards had 32gb RAM or more -- why anything with more than 4gb is so rare?

The Petitboot via SPI adds significant value, in my case netbooting (d-i with preseed everything except target disk, and install cloud-init to finish provisioning during first boot after install).
Installing and running straight to SATA without touching finnicky SD cards, which are always damaged/fake/unsupported, is a very good thing.

I hope we can find ways to make things work together, Armbian/Odroid/ELEC and more.

[igorpec]

I'd rather stick to mainline, due to Panfrost-hope, qemu/kvm on aarch64 and containerd stuff

Check once again. Armbian has the most mainline experience you will find around - no special boot loader, no legacy u-boot. It has mainline based u-boot and mainline based kernel. The only proprietary part is closed part of boot loader, which you can't avoid to bring up Amlogic chip. In any combination.

Panfrost will be supported / enabled, when stable enough.

Armbian you were playing with on S912 could only be community Armbian build as we never supported Amlogic S912.

but due to "USB stuff" it is quite unreliable. At least for heavy I/O load.

Well, you can boot system from USB drive just fine in most cases ... but otherwise USB drive as system/storage on heavy I/O just sucks. But explain that to people if you can ...

[rpardini]

That's strange...can you let me know the brand/model of your SD card? If possible, product link of you SD would be great.

Hmm. I will get data directly for the card(s) that are failing from Linux.
I won't have a product link though.

To explain: if Petitboot "sees" the SD card, I can never again access it.
If I remove the SDcard, boot to Ubuntu/SATA, and then insert the card, it works.
Using that method I got the info below:

Code: Select all

# from dmesg
kernel: [ 9368.934305] mmc0: new ultra high speed SDR104 SDXC card at address 0001
kernel: [ 9368.934938] mmcblk0: mmc0:0001 EC2QT 59.6 GiB

Code: Select all

# udevadm info -a -n /dev/mmcblk0
looking at parent device '/devices/platform/soc/ffe05000.sd/mmc_host/mmc0/mmc0:0001':
KERNELS=="mmc0:0001"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="1b534d4543325154307451537c012400"
ATTRS{csd}=="400e00325b590001dcff7f800a404000"
ATTRS{date}=="04/2018"
ATTRS{dsr}=="0x404"
ATTRS{erase_size}=="512"
ATTRS{fwrev}=="0x0"
ATTRS{hwrev}=="0x3"
ATTRS{manfid}=="0x00001b"
ATTRS{name}=="EC2QT"
ATTRS{ocr}=="0x00200000"
ATTRS{oemid}=="0x534d"
ATTRS{power/autosuspend_delay_ms}=="3000"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_time}=="362831"
ATTRS{power/runtime_status}=="active"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{rca}=="0x0001"
ATTRS{scr}=="02c5800300000000"
ATTRS{serial}=="0x7451537c"
ATTRS{ssr}=="0000000008000000040090000f053c00003000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
ATTRS{type}=="SD"

Thanks for looking into this, but I've tried many SD cards and they all fail.

Booting from SSD is way faster than SD if the OS boots properly and personally I prefer to boot from SSD since SD is slow and not safe for OS.

I agree, but booting via Petitboot from SD should "just" work. There is an interesting possibility for using SD for boot/root, and 1 SATA port for SSD, and 1 SATA port for HDD, with EnhancedIO or bcache or something like that, could prove a very interesting "simple NAS" scenario.

I really believe PetitBoot SPI flash and that weird DTB is involved in this and should be fixable...

Is there anywhere I can get to the sources used to build petitboot/uboot etc and the kernel that can flash it into SPI?

[tobetter]

That's strange...can you let me know the brand/model of your SD card? If possible, product link of you SD would be great.

Hmm. I will get data directly for the card(s) that are failing from Linux.
I won't have a product link though.

To explain: if Petitboot "sees" the SD card, I can never again access it.
If I remove the SDcard, boot to Ubuntu/SATA, and then insert the card, it works.
Using that method I got the info below:

Code: Select all

# from dmesg
kernel: [ 9368.934305] mmc0: new ultra high speed SDR104 SDXC card at address 0001
kernel: [ 9368.934938] mmcblk0: mmc0:0001 EC2QT 59.6 GiB

Code: Select all

# udevadm info -a -n /dev/mmcblk0
looking at parent device '/devices/platform/soc/ffe05000.sd/mmc_host/mmc0/mmc0:0001':
KERNELS=="mmc0:0001"
SUBSYSTEMS=="mmc"
DRIVERS=="mmcblk"
ATTRS{cid}=="1b534d4543325154307451537c012400"
ATTRS{csd}=="400e00325b590001dcff7f800a404000"
ATTRS{date}=="04/2018"
ATTRS{dsr}=="0x404"
ATTRS{erase_size}=="512"
ATTRS{fwrev}=="0x0"
ATTRS{hwrev}=="0x3"
ATTRS{manfid}=="0x00001b"
ATTRS{name}=="EC2QT"
ATTRS{ocr}=="0x00200000"
ATTRS{oemid}=="0x534d"
ATTRS{power/autosuspend_delay_ms}=="3000"
ATTRS{power/control}=="auto"
ATTRS{power/runtime_active_time}=="362831"
ATTRS{power/runtime_status}=="active"
ATTRS{power/runtime_suspended_time}=="0"
ATTRS{preferred_erase_size}=="4194304"
ATTRS{rca}=="0x0001"
ATTRS{scr}=="02c5800300000000"
ATTRS{serial}=="0x7451537c"
ATTRS{ssr}=="0000000008000000040090000f053c00003000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
ATTRS{type}=="SD"

Thanks for looking into this, but I've tried many SD cards and they all fail.

Booting from SSD is way faster than SD if the OS boots properly and personally I prefer to boot from SSD since SD is slow and not safe for OS.

I agree, but booting via Petitboot from SD should "just" work. There is an interesting possibility for using SD for boot/root, and 1 SATA port for SSD, and 1 SATA port for HDD, with EnhancedIO or bcache or something like that, could prove a very interesting "simple NAS" scenario.

I really believe PetitBoot SPI flash and that weird DTB is involved in this and should be fixable...

Is there anywhere I can get to the sources used to build petitboot/uboot etc and the kernel that can flash it into SPI?

It should work boot from SD by the Petitboot and it is with my HC4, I've seen several users install OS to SD and manage the rest with SSD/HDD. Having error with -110 and not booting from SD is the first time so far. That's why I need to grab the product detail to test with the same SD card if it is caused by the incompatible SD card with the kernel.

[rpardini]

Ok, thanks.
I should mention that I did do pb_update many times in the last week...

[tobetter]

Ok, thanks.
I should mention that I did do pb_update many times in the last week...

Petitboot update does not happen often, maybe once in 2-3 months if there is no critical issue. So "pb-update" do have nothing to work mostly.
Appreciate if you share the vendor/model of your SD card which gives -110 error with the Petitboot so I can try to reproduce it.

[rpardini]

Hi! Of course you are right. Two SD cards, both fail booting through Petitboot 9 out of 10 times:
- EC2QT is a https://www.samsung.com/us/computing/me ... mc64ha-am/ Samsung MB-MC64HA/AM (EVO PLUS 64gb)
- EB1QT the 32gb https://www.samsung.com/us/computing/me ... mc32ga-am/

Of this second one, it is said

Card speed stays at high speed during boot up while other UHS-I compatible card switched to ultra high speed. It only changed to ultra high speed after remove and reinsert the card.

I know I need new SDs -- I will be ordering some soon together with more Odroid's!
In the meantime maybe there is something to be learned, maybe a denylist of known-bad SD cards with PetitBoot? To avoid headaches?

I'm gonna wipe Petitboot and see what happens, if those same cards are useable. Off to Armbian land. Let you know. Thanks.

[tobetter]

Hi! Of course you are right. Two SD cards, both fail booting through Petitboot 9 out of 10 times:
- EC2QT is a https://www.samsung.com/us/computing/me ... mc64ha-am/ Samsung MB-MC64HA/AM (EVO PLUS 64gb)
- EB1QT the 32gb https://www.samsung.com/us/computing/me ... mc32ga-am/

Of this second one, it is said

Card speed stays at high speed during boot up while other UHS-I compatible card switched to ultra high speed. It only changed to ultra high speed after remove and reinsert the card.

I know I need new SDs -- I will be ordering some soon together with more Odroid's!
In the meantime maybe there is something to be learned, maybe a denylist of known-bad SD cards with PetitBoot? To avoid headaches?

I'm gonna wipe Petitboot and see what happens, if those same cards are useable. Off to Armbian land. Let you know. Thanks.

Thanks, fortunately I think have those SD cards so I would be able to test again.
FYI, the Petitboot does not use UHS-I and use High Speed mode. This is because, as you've read, in order to achieve UHS-I, need power cycle to SD card which is a bit complicated to the Petitboot when switching to real OS. So it's like Power-On -> High-Speed mode -> real kernel -> intiate UHS-I mode. Samsung EVO always give a headache while SanDisk is the best for ODROID.

[rpardini]

- EC2QT ...
- EB1QT ...

Thanks, fortunately I think have those SD cards so I would be able to test again.
FYI, the Petitboot does not use UHS-I and use High Speed mode. This is because, as you've read, in order to achieve UHS-I, need power cycle to SD card which is a bit complicated to the Petitboot when switching to real OS. So it's like Power-On -> High-Speed mode -> real kernel -> intiate UHS-I mode. Samsung EVO always give a headache while SanDisk is the best for ODROID.

Yes. I will get new, decent SDs and report back. But, do see below -- problems with those SD cards are specific to Petitboot.

- EC2QT ...
- EB1QT ...
I'm gonna wipe Petitboot and see what happens, if those same cards are useable. Off to Armbian land. Let you know. Thanks.

Done. flash_eraseall cleaned Petitboot. It is like a completely different machine, much faster boot times (u-boot).
Done a dozen tryouts with everything else: CoreELEC, Armbian, some other stuff, everything works perfectly with same EC2QT and EB1QT.
Armbian specifically says "your SD card is slow", but works perfectly 10 out of 10 boots. No errors. Insert/reinsert, boot here, boot there, it always works.
The only thing that chokes the HC4 is Petitboot...


Sorry to ask again:

where can I find the source and build instructions for the Petitboot/u-boot on the Odroid boards?