odroidm1: u-boot: enable setexpr; patch 2025.01 for fileenv; enable squashfs support
#7769
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
size/medium
|
I have M1 and can do the test. If you tell how to perform this test. |
Nice, thanks. First: If you already have Armbian u-boot on SPI from before this PR: try the HAOS image on SD and see it fail (bootloop). Then: deploy Armbian to the ODROID-M1 as per the instructions (build image from this PR, write image to SD, hold RCY button for a little while, boot image, Then: download HAOS M1 image, write to SD and boot it, it should just work. I've sent a patch to HAOS to enable booting from NVMe as well but that's not yet merged nor released yet. |
rpardini
force-pushed
the
pr/odroidm1-u-boot-enable-setexpr-patch-202501-for-fileenv-enable-squashfs-support
branch
from
8b1462e to
4df2850
Compare
|
Sorry, but no. |
|
If I press recovery button on power on, HAOS booting hangs on kernel load: |
|
Normal armbian image I build some weeks ago not boots without button, but boots with recovery button. |
rpardini
force-pushed
the
pr/odroidm1-u-boot-enable-setexpr-patch-202501-for-fileenv-enable-squashfs-support
branch
from
4df2850 to
d71aff0
Compare
|
Hi, the first bootlog you sent seems to not find anything bootable (and thus goes to bootp). I've not changed anything regarding this. Can you check SD is fine? Second bootlog, seems to be with button, and thus uses the uboot from the card (not us). HAOS does not have serial console enabled (check cmdline.txt in the HAOS image to enable) and thus seems to hang -- I have the same. |
|
Not sure it related... I use BalenaEtcher for microsdcard writing. So, I add I think it means, at least, my HAOS image is bootable itself, despite of etcher error. Log of boot without button shows now I check, and see — this branch ( Hash equal. Now I rebuild uboot ad armbian image with your latest commit. |
|
Indeed. It seems all checks out. I'm puzzled as to why. I will get the odroidm1 going again and capture some bootlogs so we can compare. In the end, all this PR does is enable a few uboot commands so that the boot.scr from HAOS works, and enables squashfs so it can read the kernel Image from HAOS correctly -- it shouldn't change anything regarding readability of SD. If you build HAOS from the PR I linked somewhere above, you can also boot and run it directly from NVMe, which is my use case, for performance and stability -- too many flukes with SD and eMMC over the years. I use a USB micro cable and uboot UMS command to write the HAOS image directly to NVMe. |
|
I not build HAOS image, I build only armbian. HAOS image I got by your link. Currently I have no nvme disk available for testing — maybe, later, but not nearest days. I'd like add to context fact that current armbian uboot can't boot M1 from sdcard without recovery button too: https://forum.armbian.com/topic/45671-odroid-m1-wont-boot-on-recent-images-in-armbian-download-section/#findComment-211555 |
|
As promised a complete bootlog. This is the u-boot from this PR on SPI, and eMMC. eMMC has been flashed using a micro-usb cable to desktop computer and raspberrypi-imager with HAOS image 14.2 and using |
|
And this is a boot from SD card (64gb Sandisk gold); HAOS was written on desktop using raspberrypi-imager. Odroid-M1 in this case has only SD (eMMC was removed). |
Very strange. I've tested all previous versions since 2024.07 and all work with SD on my m1. This is on the u-boot 2025.01 from this PR, showing SD card details. |
rpardini
force-pushed
the
pr/odroidm1-u-boot-enable-setexpr-patch-202501-for-fileenv-enable-squashfs-support
branch
from
d71aff0 to
652aea5
Compare
Yes, please try eMMC - I suspect there might be the ages-old problem of dubious SD cards involved here. |
|
|
|
@rpardini maybe we use different M1 devices? Mine is Rev1 |
|
I'm baffled. From your
|
…le squashfs support - as Armbian u-boot is possibly deployed to SPI (replacing Petitboot), try to make as compatible as possible; eg enable squashfs support - in this case, `setexpr` and `fileenv` are used by HAOS - found `fileenv` here spikerguy/khadas-uboot@049e1a1 Signed-off-by: Ricardo Pardini <[email protected]>
rpardini
force-pushed
the
pr/odroidm1-u-boot-enable-setexpr-patch-202501-for-fileenv-enable-squashfs-support
branch
from
652aea5 to
7d3d616
Compare
Mine is |
|
|
|
Thus Fact the u-boot can talk to eMMC, can list partitions, but can't access the most basic FAT32 filesystem is very strange -- I can't attribute this to a different board revision. How are you burning the image? Can you check that partition indeed contains the expected files using another machine? Also, try creating some file in there and see if it shows up in u-boot's |
|
Also, check the help for the |
|
You are right |
|
Ok. Since your device can
in my understanding there is no reason why this wouldn't frakking boot the Unless... you've instructed it to not do that, in the SPI environment. Could you please capture the full output of running
please? |
|
|
Hmm, your env says I am, in case you've not noticed, completely at a loss here. Maybe someone more knowledgeable will spot this and help. I don't wanna invoke Jonas with a mention -- yet -- but also dunno what else to try. Maybe, if you keep everything else as-is and downgrade BOOTBRANCH to 2024.04 (or whatever is the last working one; keep BOOTPATCHDIR so it picks up the patch for |
|
Also, maybe try interrupting "Hit any key to stop autoboot" and do: to see if it reveals any more? maybe it is the USB scan that is somehow frakking up things. |
This is highly likely. I see now that the default I used in the board file is thus you have manually changed to boot USB first in your environment? That might be affecting things...? |
|
Do you have USB devices plugged in when testing? :-D Maybe try without... |
no one, even usb wifi pulled out. |
|
no. I can't remember anything like that. I have no knowledge about uBoot and newer tune it. |
I set (complete https://paste.next.armbian.com/owizexuvor) |
|
Yeah, no idea then. Other than your FAT32 |
|
We need more testers. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
try to make as compatible as possible; eg enable squashfs support
setexprandfileenvare used by HAOSfileenvhere spikerguy/khadas-uboot@049e1a1Signed-off-by: Ricardo Pardini [email protected]