Closed as-shura closed 1 year ago
Many thanks for your report.
It loads the boot.ini
script correctly but it fails to load kernel image, initramfs and device tree. Those three files are however present in our image. Can you verify this when attaching the SD card to another system and accessing the first/FAT partition there?
I've also been unable to boot the latest images. Though it is possible to boot Dietpi on the Odroid C1 if I use the conversion script to rework Armbian Buster 5.10.12.
However, if I mount a usb flash drive that version will also fail to boot.
Could you answer the question form my previous post, please?
However, if I mount a usb flash drive that version will also fail to boot.
You mean any image fails to boot from SD card as long as you also have a USB flash drive attached? Sounds like a power/voltage issue.
Many thanks for your report.
It loads the
boot.ini
script correctly but it fails to load kernel image, initramfs and device tree. Those three files are however present in our image. Can you verify this when attaching the SD card to another system and accessing the first/FAT partition there?
Let me reflash an SD card and check for validation.
Content of the boot.ini file:
ODROIDC-UBOOT-CONFIG
# HDMI resolution
# - Exactly one line needs to be uncommented!
#setenv m "vga" # 640x480
#setenv m "480p" # 720x480
#setenv m "576p" # 720x576
#setenv m "800x480p60hz" # 800x480
#setenv m "800x600p60hz" # 800x600
#setenv m "1024x600p60hz" # 1024x600
#setenv m "1024x768p60hz" # 1024x768
#setenv m "1360x768p60hz" # 1360x768
#setenv m "1440x900p60hz" # 1440x900
#setenv m "1600x900p60hz" # 1600x900
#setenv m "1680x1050p60hz" # 1680x1050
#setenv m "720p" # 720p 1280x720
#setenv m "800p" # 1280x800
#setenv m "sxga" # 1280x1024
#setenv m "1080i50hz" # 1080I@50Hz
#setenv m "1080p24hz" # 1080P@24Hz
#setenv m "1080p50hz" # 1080P@50Hz
setenv m "1080p" # 1080P@60Hz
#setenv m "1920x1200" # 1920x1200
# HDMI/DVI selection: "hdmi" or "dvi"
# - DVI mode disables HDMI sound
setenv vout "hdmi"
# HDMI BPP Mode: "32", "24" or "12"
setenv m_bpp "32"
# Monitor output: "true" or "false"
# - Controls if HDMI PHY should output anything to the monitor
setenv monitor_onoff "true"
# HDMI Hot Plug detection
# - "0" disables auto-detection and forces HDMI output.
# - "1" enables HDMI detection based on cable connection (default).
#setenv hpd "0"
# CEC (requires hardware modification)
# - "0" disables HDMI CEC (default).
# - "1" enables HDMI CEC.
#setenv cec "0"
# PCM5102 I2S Audio DAC
# - PCM5102 is an I2S Audio DAC addon board for ODROID-C1+
# - Uncomment the line below to __ENABLE__ support for this addon board.
#setenv enabledac "enabledac"
# UHS Card Configuration
# - Uncomment the line below to __DISABLE__ UHS-1 Micro SD support
# - This might break boot for some brand models of cards.
#setenv disableuhs "disableuhs"
# Disable VPU (Video decoding engine, saves RAM!!!)
# - 0 = disabled
# - 1 = enabled (default)
#setenv vpu "1"
# Disable HDMI Output (Again, saves RAM!)
# - 0 = disabled
# - 1 = enabled (default)
#setenv hdmioutput "1"
# Default Console Device Setting
setenv condev "console=ttyAML0,115200n8 console=tty1"
# ODROID-VU7 touchscreen: "false" or "true", defaults to "true"
#setenv disable_vu7 "false"
# CPU Max Frequency: 96 192 312 408 504 600 720 816 1008 1200 1320 1488 1536 1632 1728 or 1824
setenv max_freq "1536"
### DO NOT EDIT ANYTHING BELOW THIS LINE ###
if test "${hpd}" = "0"; then setenv hdmi_hpd "disablehpd=true"; fi
if test "${cec}" = "1"; then setenv hdmi_cec "hdmitx=cecf"; fi
if test "${disable_vu7}" = "false"; then setenv hid_quirks "usbhid.quirks=0x0eef:0x0005:0x0004"; fi
# Boot arguments
setenv bootargs "root=UUID=b83304f6-e29e-411d-ae85-421876dfcce1 rootfstype=ext4 rootwait rw ${condev} loglevel=4 no_console_suspend consoleblank=0 vdaccfg=0xa000 dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac} monitor_onoff=${monitor_onoff} max_freq=${max_freq} ${hid_quirks} ${extraargs}"
# Booting
fatload mmc 0:1 0x20800000 uImage
fatload mmc 0:1 0x22000000 uInitrd
fatload mmc 0:1 0x21800000 dtb/meson8b-odroidc1.dtb
fdt addr 21800000
if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi
if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi
bootm 0x20800000 0x22000000 0x21800000
Folder structures :
Could you answer the question form my previous post, please?
However, if I mount a usb flash drive that version will also fail to boot.
You mean any image fails to boot from SD card as long as you also have a USB flash drive attached? Sounds like a power/voltage issue.
I don't think it's a power issue. The Armbian Buster image will boot with two usb drives attached. But it's not possible when I convert Armbian to DietPi.
@Thomas-O I don't know what you are talking about but before it gets to any of the things you are talking about it doesn't enter inside of the kernel. After we achieve that can we validate your hypothesis.
Did you upgrade to latest kernel version 5.15.93 on the Armbian image? The DietPi conversion cannot really have any impact on booting, but the kernel and U-Boot upgrades can have (which are implied by the DietPi update). And it can have effect on peak power consumption.
All files are there. The U-Boot package is and was very old and the same, as is boot.ini
. Only the kernel changed, upgraded in mid February, but this cannot explain the U-Boot failures of OP.
Did you upgrade to latest kernel version 5.15.93 on the Armbian image? The DietPi conversion cannot really have any impact on booting, but the kernel and U-Boot upgrades can have (which are implied by the DietPi update). And it can have effect on peak power consumption.
All files are there. The U-Boot package is and was very old and the same, as is
boot.ini
. Only the kernel changed, upgraded in mid February, but this cannot explain the U-Boot failures.
@MichaIng who are you addressing yourself to?
Why can't the device get to the kernel image if it is there ? What can I do to do further testing?
@as-shura My last post was addressing @Thomas-O as he was testing the Armbian image and conversion.
Why can't the device get to the kernel image if it is there ?
I have no idea. I rechecked and compared the image and couldn't find any issue. I just triggered a new build, probably a quirk on the particular run: https://github.com/MichaIng/DietPi/actions/runs/4431965962 Ready in about 20 minutes.
To both of you: In the meantime you could also test the Bookworm image to rule out an issue with the particular build.
And a question: Do you have any need for the dedicated boot FAT partition? Based on the Armbian boot.ini
, I think the bootloader actually supports booting from a single ext4 partition. What would simplify clean things up. Only argument to keep the FAT partition is accessing it easier from Windows and macOS to pre-configure dietpi.txt
and/or boot.ini
.
And a question: Do you have any need for the dedicated boot FAT partition? Based on the Armbian
boot.ini
, I think the bootloader actually supports booting from a single ext4 partition. What would simplify clean things up. Only argument to keep the FAT partition is accessing it easier from Windows and macOS to pre-configuredietpi.txt
and/orboot.ini
.
I think the old way of booting is not necessary anymore. It will be a good think to make it a single partition. Good call on this one.
I will test Bookworm in the mean time and keep you updated.
Only argument to keep the FAT partition is accessing it easier from Windows and macOS to pre-configure
dietpi.txt
and/orboot.ini
.
You can always use this https://github.com/matt-wu/Ext3Fsd to explore on Windows ext4 partitions.
I have no idea. I rechecked and compared the image and couldn't find any issue. I just triggered a new build, probably a quirk on the particular run: https://github.com/MichaIng/DietPi/actions/runs/4431965962 Ready in about 20 minutes.
Where can I download the newly generated image if there is something to test?
Bookword console log is the same! :D
But that Windows ext4 driver is read-only, isn't it? Reading the content of the image file can be done with 7-Zip as well. Writing from Windows and macOS is the challenge. There are drivers which support it, but all I tested destroyed the filesystem earlier or later, so this is extremely dangerous. A Linux VM is best to do it safely. Sadly WSL2 wsl --mount
does not support USB devices OOTB and with some TCP based pass through method it does not support MMC/SD devices 😞.
No need to spam the issue with long U-Boot log, if it is just the same 😄.
Ah sorry, new image is ready here: https://dietpi.com/downloads/images/testing/
It is both read/write I use it everyday. Modified the long log and getting ready to test the new image.
Same problem with the new image:
setenv bootargs "root=UUID=518088d3-8e71-4da2-85bf-00bdd1671f22 rootfstype=ext4 rootwait rw ${condev} loglevel=4 no_console_suspend consoleblank=0 vdaccfg=0xa000 dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac} monitor_onoff=${monitor_onoff} max_freq=${max_freq} ${hid_quirks} ${extraargs}"
fatload mmc 0:1 0x20800000 uImage
reading uImage
Invalid FAT entry
** Unable to read "uImage" from mmc 0:1 **
fatload mmc 0:1 0x22000000 uInitrd
reading uInitrd
Invalid FAT entry
** Unable to read "uInitrd" from mmc 0:1 **
fatload mmc 0:1 0x21800000 dtb/meson8b-odroidc1.dtb
reading dtb/meson8b-odroidc1.dtb
Invalid FAT entry
** Unable to read "dtb/meson8b-odroidc1.dtb" from mmc 0:1 **
fdt addr 21800000
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi
libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC
bootm 0x20800000 0x22000000 0x21800000
Wrong Image Format for bootm command
ERROR: can't get kernel image!
▒
Unknown command '▒' - try 'help'
MMC read: dev # 0, block # 1216, count 16384 ... 16384 blocks read: OK
MMC read: dev # 0, block # 1088, count 128 ... 128 blocks read: OK
Wrong Image Format for bootm command
ERROR: can't get kernel image!
Just to let you know the FAT32 partition is still there 😄
Why isn't Dietpi using the latest mainline kernel with odroid-c1?
Okay I have no idea what changed, looked through all commits and checked the image, all seems identical. Of course in theory some defaults on latest GitHub Actions runners (Ubuntu Jammy) parted or dosfstools could have changed, or a bug introduced or such, but this is extremely unlikely for fundamental tools like this on the most settled filesystem that exists. And neither Windows, 7-Zip or RPis have any issue accessing this FAT filesystem 🤔.
However, lets skip that and test whether a single ext4 partition works. Build is running and image available in about 30 minutes as linked above.
Why isn't Dietpi using the latest mainline kernel with odroid-c1?
Because we use the Armbian meson kernel which is currently at 5.15.93. However, the kernel is not the issue here, but the combination of bootloader and this FAT filesystem and/or partition table.
We just started to do own kernel builds with Quartz64 and RISC-V VisionFive 2 SBCs (never did this before). When the CI development for this settled, I see no problem to do own kernel and in case bootloader builds as well for other SBCs. Upstream Linux has an Odroid C1 device tree, so theoretically support is there. And since Armbian kernels have a bunch of issues as well, sometimes caused by their large amount of patches causing conflicts with upstream changes, it might even make things better. E.g. HDMI is not working on C1, right? Probably with unmodified current upstream Linux is does, who knows.
Because we use the Armbian meson kernel which is currently at 5.15.93. However, the kernel is not the issue here, but the combination of bootloader and this FAT filesystem and/or partition table.
Great news waiting for the build to finish and will test it ASAP.
We just started to do own kernel builds with Quartz64 and RISC-V VisionFive 2 SBCs (never did this before). When the CI development for this settled, I see no problem to do own kernel and in case bootloader builds as well for other SBCs.
I think that we should have parallel kernels just to se the upcoming challenges while we are running working kernel. Good move for Future.
Upstream Linux has an Odroid C1 device tree, so theoretically support is there. And since Armbian kernels have a bunch of issues as well, sometimes caused by their large amount of patches causing conflicts with upstream changes, it might even make things better.
I tested all armbian mainline images with 5.1* and they are all corrupting the SD card at some point and the system is not usable at all. I am getting all these errors:
[ 398.788954] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #2: comm systemd-udevd: reading directory lblock 0
[ 398.799372] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #10930: comm systemd-udevd: reading directory lblock 0
[ 398.831376] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #10930: comm systemd-udevd: reading directory lblock 0
[ 398.841743] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #5352: comm systemd-udevd: reading directory lblock 0
[ 398.857158] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #2: comm systemd-udevd: reading directory lblock 0
[ 399.019189] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #10930: comm systemd-udevd: reading directory lblock 0
[ 399.069134] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #76498: comm systemd-udevd: reading directory lblock 0
[ 399.093787] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #5352: comm systemd-udevd: reading directory lblock 0
[ 399.104768] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #2: comm systemd-udevd: reading directory lblock 0
[ 399.119149] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #10930: comm systemd-udevd: reading directory lblock 0
[ 399.129577] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #76498: comm systemd-udevd: reading directory lblock 0
[ 399.140373] EXT4-fs error (device mmcblk0p2): __ext4_find_entry:1660: inode #5361: comm systemd-udevd: reading directory lblock 0
E.g. HDMI is not working on C1, right? Probably with unmodified current upstream Linux is does, who knows.
IMHO the best use case for ODROID-C1 series is only serverless with docker for home server setup. Only needed is ssh+network+external-usb-HD
I think that we should have parallel kernels just to se the upcoming challenges while we are running working kernel. Good move for Future.
It is always possible to install the "edge" kernel builds:
apt install linux-{image,dtb}-meson-edge linux-u-boot-odroidc1-edge
I think the "edge" U-Boot does not exist (for Odroid C1, as it is not officially supported anymore by Armbian), or is practically the same as the "current" one. In case skip that.
However, the benefit is probably a more reliable kernel basis. Time will tell if upstream Linux is more reliable (not suddenly breaking features with upgrades) for Odroid C1 or in general, compared to Armbian.
Even if HDMI is not seen important, it would be just nice to have all basic hardware features supported. I remember it broke for Odroid C1 when Armbian moved from the ancient Linux 3.x kernel from Hardkernel sources to mainline Linux. But possible mainline Linux did get support in the meantime, and there is only one of the huge number of Armbian kernel patches breaking it.
And, does the new image boot? https://dietpi.com/downloads/images/testing/
I think the "edge" U-Boot does not exist (for Odroid C1, as it is not officially supported anymore by Armbian), or is practically the same as the "current" one. In case skip that.
Where can we then find a working U-Boot for the edge version?
It means apt install linux-{image,dtb}-meson-edge linux-u-boot-odroidc1-edge is useless in that case isn't it?
And, does the new image boot? https://dietpi.com/downloads/images/testing/
I just arrived now and will test it right away.
I am sorry to tell this news to you but it is looping in this :
QA5:A;SVN:B72;POC:17F;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:41;USB:3;SERIAL:4;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:41;USB:3;SERIAL:4;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:41;USB:3;SERIAL:4;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:41;USB:3;SERIAL:4;QA5:A;SVN:B72;POC:17F;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:41;USB:3;SERIAL:4;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:41;USB:3;
I can confirm this because I tested on 2 different SD card and still same looping. Just ping me when there is a new build.
If you make this happen you will save 2 ODROID-C1 boards and their future. We will employ them for their lifetime as docker host and few services. Otherwise I am going to crush the boards and throw them in garbage by saying "what a bad investment choosing you for the future" 😄
Ah my mistake. New image builds: https://github.com/MichaIng/DietPi/actions/runs/4442800002
Testing soon still download and will be flashing afterwards. Good news and bad news.
Booting works only at the 1/4 with error:
Folders in drive partition:
Content of boot.ini
I've just tried the latest (2023-03-17) Odroid C1 Bullseye image and I'm sorry to report that there's still nothing happening at my end.
As a semi-technical user for whom DietPi is a godsend I won't be able to provide a sophisticated analysis of any shortcomings, but I was a little puzzled by the missing boot partition. When I flashed the image all I could see was the 400mb ext4 filesystem. Sorry if this is a doltish observation but installing and clumsily configuring DietPi already stretches the limits of my comprehension and capacity.
One last attempt: https://github.com/MichaIng/DietPi/actions/runs/4447536627
I used the boot.ini
from dev
branch instead of odroidc1
branch, where the needed changes were done. However, the error sounds like the bootloader tries to use fatload
to load the boot.ini
itself and does not fall back to ext4load
, so indeed requries it to be located on a FAT partition. What nonsense that it tries to load it from /boot/boot.ini
first/at all, as if Linux could run on FAT 😄:
** Unable to use mmc 0:1 for fatload ** Loading file "/boot/boot.ini" from mmc device 0:1 xxa1 ** File not found /boot/boot.ini
Mainline U-Boot sadly does not support it, and if Armbian did not patch it on to of Hardkernel sources, it doesn't seem that easy.
So seems like we need to fix the issue with that FAT partition, whatever it is.
One last attempt: https://github.com/MichaIng/DietPi/actions/runs/4447536627
I think we need more people on this task if you are at the end of your roll of ideas.
More people won't help. That U-Boot supports FAT only, that's it 😢. I'm regenerating a FAT image now. If it does not boot like the previous one, I have two ideas to test.
I am behind you I will test as much as I can to support. I got your back 😄
I think we need more people on this task
How much people do you expect working on DietPi project? We are an extremely small group of people, where @MichaIng is the only developer we have. 😉
I think we need more people on this task
How much people do you expect working on DietPi project? We are an extremely small group of people, where @MichaIng is the only developer we have. 😉
I am a developer also but never worked with Linux programming.
More people won't help. That U-Boot supports FAT only, that's it 😢. I'm regenerating a FAT image now. If it does not boot like the previous one, I have two ideas to test.
When ever you have a new build let me knowI will be outside but close to home and will come back to test on the board.
This is the last release on the 18th.
This just looks like a wrong baudrate. You do use 115200
?
This just looks like a wrong baudrate. You do use
115200
?
Is this the first console output or is there readable output before that? I'm very much lost as the first output isn't related to any partitioning or filesystem at all, the very first output not even to the SD card content. So that the image can have any effect on this is basically impossible.
What I however did change is the cluster size of the FAT partition. This is a valid value which mounts and scans all find on Linux. I just recognised however that 7-Zip cannot open the partition. Probably the C1 is picky on it as well. BUT that again has nothing to do with U-Boot which is not within the FAT partition and hence not affected. If there was any effect, then, as before, that it cannot read boot.ini
.
I'll switch to FAT16 now, which would be the default for this filesystem size and is what Armbian images are shipped with, i.e. the last remaining difference: https://github.com/MichaIng/DietPi/actions/runs/4463039464
It is strange, according to Hardkernel's U-Boot sources as well as a matching patch from Armbian, it should support an ext4 partition:
Those two messages are ext4load
attempts, after fatload
failed:
Loading file "/boot/boot.ini" from mmc device 0:1 xxa1
** File not found /boot/boot.ini
Loading file "boot.ini" from mmc device 0:1 xxa1
** File not found boot.ini
So it is a more fundamental issue with the image or SD card or socket or power of whatever that loading something from any partition/filesystem fails. Strange also that it happens at different stages:
boot.ini
from the FAT partition, reporting Loading boot.ini from mmc0:1 (vfat)
, but then failed to load the kernel, initramfs and dtb.boot.ini
, while it did try it with ext4load
.EDIT: From the U-Boot command print, does env
or fw_printenv
return the environment, so we can just get sure it matches the linked sources.
Just to rule it out: Does the latest Armbian image work for you @as-shura?
Interesting enough good news @MichaIng !!!!!
There is a heart beat and the blue led is blinking normal but the kernel is not loading. I will try to flash another SD card and see if the problem is at that level.
Is there anything suspicious in this log ?
I am sorry my bad this is the last result
There is a problem with the the device I have an external HD connected and it doesn't get recognized at boot.
When I plug one mouse and keyboard and the external HD somehow it gets detected. So the old bug is still there ...
2+ usb devices get recognized. How is it that they could not fix this yet ....
Okay so far so good. Since we used FAT32 before, still no idea why now FAT16 is needed, or if it was just a coincidence.
I'll generate another ext4 image, but at least we have one that works again.
Okay so far so good. Since we used FAT32 before, still no idea why now FAT16 is needed, or if it was just a coincidence.
I'll generate another ext4 image, but at least we have one that works again.
Yes i wanted to ask you to generate a normal ext4 partition... I sometimes have corruption errors on sdcard while the os is running. How complicated will it be to test with the 6.x mainline serie? I think a lot of bugs were fixed for that branch.
I think that the USB bug is also fixed in the meson listing on https://linux-meson.com/mainlining.html if you search odroid-c1
I am now going to test https://dietpi.com/downloads/images/testing/DietPi_OdroidC1-ARMv7-Bookworm.7z
The Bookworm image is just the same with FAT16 partition. I just wanted to have it with this filesystem for our stable downloads, as it is now know to boot.
ext4 partition images currently build, ready in ~30 minutes.
Flash the image with Rufus and stick it into the sd slot on the ODROID-C1.
Image used : https://dietpi.com/downloads/images/DietPi_OdroidC1-ARMv7-Bullseye.7z
Serial Console logs:
Logfile attached. Click to expand!
``` QA5:A;SVN:B72;POC:17F;STS:0;BOOT:0;INIT:10;BOOT:1;INIT:0;READ:0;CHECK:0;PASS:1; ----------------------------------------------------------------------- * Welcome to Hardkernel's ODROID-C... (Built at 19:33:00 Dec 8 2014) * ----------------------------------------------------------------------- CPU : AMLogic S805 MEM : 1024MB (DDR3@792MHz) BID : HKC1310001 S/N : HKC11122F37DE839 0x0000009f check SD_boot_type:0x1 card_type:0x1 Loading U-boot...success. U-boot-00000-gb7b8dc2-dirty(odroidc@b7b8dc21) (Mar 08 2021 - 18:45:29) I2C: clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[20]=0 set output val 0xc1108058[20]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=fffcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffdcfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 out reg=c1108058,value=ffccfa00 set output en 0xc1108054[20]=0 set output val 0xc1108058[20]=0 clear pinmux reg1[24]=0 clear pinmux reg1[1]=0 out reg=c1108058,value=ffecfa00 set output en 0xc1108054[21]=0 set output val 0xc1108058[21]=0 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 clear pinmux reg1[25]=0 clear pinmux reg8[12]=0 clear pinmux reg1[3]=0 clear pinmux reg1[2]=0 set output en 0xc1108054[20]=1 ready DRAM: 1 GiB relocation Offset is: 2ff18000 MMC: SDCARD: 0, eMMC: 1 IR init is done! vpu clk_level = 3 set vpu clk: 182150000Hz, readback: 182150000Hz(0x701) mode = 6 vic = 4 set HDMI vic: 4 mode is: 6 viu chan = 1 config HPLL config HPLL done reconfig packet setting done MMC read: dev # 0, block # 33984, count 12288 ... 12288 blocks read: OK Error: Bad gzipped data There is no valid bmp file at the given address ============================================================ Vendor: Man 035344 Snr dcee2413 Rev: 8.0 Prod: SC32G Type: Removable Hard Disk Capacity: 30436.5 MB = 29.7 GB (62333952 x 512) ------------------------------------------------------------ Partition Start Sector Num Sectors Type 1 8192 262144 c 2 270336 760088 83 ============================================================ Net: Meson_Ethernet init suspend firmware done. (ret:0) Hit Enter key to stop autoboot -- : 0 exit abortboot: 0 reading boot.ini 3236 bytes read Loading boot.ini from mmc0:1 (vfat) Executing the script... setenv m "1080p" # 1080P@60Hz setenv vout "hdmi" setenv m_bpp "32" setenv monitor_onoff "true" setenv condev "console=ttyAML0,115200n8 console=tty1" setenv max_freq "1536" if test "${hpd}" = "0"; then setenv hdmi_hpd "disablehpd=true"; fi if test "${cec}" = "1"; then setenv hdmi_cec "hdmitx=cecf"; fi if test "${disable_vu7}" = "false"; then setenv hid_quirks "usbhid.quirks=0x0eef:0x0005:0x0004"; fi setenv bootargs "root=UUID=b83304f6-e29e-411d-ae85-421876dfcce1 rootfstype=ext4 rootwait rw ${condev} loglevel=4 no_console_suspend consoleblank=0 vdaccfg=0xa000 dmfc=3 cvbsmode=576cvbs hdmimode=${m} m_bpp=${m_bpp} vout=${vout} ${disableuhs} ${hdmi_hpd} ${hdmi_cec} ${enabledac} monitor_onoff=${monitor_onoff} max_freq=${max_freq} ${hid_quirks} ${extraargs}" fatload mmc 0:1 0x20800000 uImage reading uImage Invalid FAT entry ** Unable to read "uImage" from mmc 0:1 ** fatload mmc 0:1 0x22000000 uInitrd reading uInitrd Invalid FAT entry ** Unable to read "uInitrd" from mmc 0:1 ** fatload mmc 0:1 0x21800000 dtb/meson8b-odroidc1.dtb reading dtb/meson8b-odroidc1.dtb Invalid FAT entry ** Unable to read "dtb/meson8b-odroidc1.dtb" from mmc 0:1 ** fdt addr 21800000 libfdt fdt_check_header(): FDT_ERR_BADMAGIC if test "${vpu}" = "0"; then fdt rm /mesonstream; fdt rm /vdec; fdt rm /ppmgr; fi libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC if test "${hdmioutput}" = "0"; then fdt rm /mesonfb; fi libfdt fdt_path_offset() returned FDT_ERR_BADMAGIC bootm 0x20800000 0x22000000 0x21800000 Wrong Image Format for bootm command ERROR: can't get kernel image! ▒ Unknown command '▒' - try 'help' MMC read: dev # 0, block # 1216, count 16384 ... 16384 blocks read: OK MMC read: dev # 0, block # 1088, count 128 ... 128 blocks read: OK Wrong Image Format for bootm command ERROR: can't get kernel image! ```