Mainline firmware for ODROID-M1

Post Reply
usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Mainline firmware for ODROID-M1

Post by usual user »

Since U-Boot v2023.10 General Availability out-of-the-box support for the ODROID M1 is now available. It can be used to build a mainline firmware on a solid basis for it. The mainline universality allows a single firmware to be build that can be used for a variety of operation systems. Unfortunately, not all features that are in the works for the Rockchip platform, which would also benefit an ODROID M1 build, have made it into the current release. In order to demonstrate all publicly available features and you not have to build the firmware yourself, I share my mainline firmware build for easy consumption.
These are the features of my firmware build:
  • Enabled standard boot methods: extlinux (extlinux.conf), EFI, legacy script (boot.src) and PXE
  • Boot artefacts are be loaded from microSD-, eMMC-, NVME-, SATA-, USB-storage or network
  • Autoboot starts after two seconds with first found valid bootflow
  • Boot menu at the serial console with
    • Entries to switch the ODROID M1 to USB storage mode for NVME, SCSI, eMMC or microSD via the micro USB port
    • Entry to power down in preperation to power up with powerkey.
    • Enumerated partition entries to choose additional EFI boot method locations
    • Entry to switch to U-Boot console

    Code: Select all

    *** U-Boot Boot Menu ***
        Standard Boot
        NVME USB Mass Storage
        SCSI USB Mass Storage
        eMMC USB Mass Storage
        microSD USB Mass Storage
        Power Off
        usb 0:3
        nvme 0:1
        mmc 1:2
        U-Boot console
    Hit any key to stop autoboot: 2
    Press UP/DOWN to move, ENTER to select, ESC to quit
  • Compressed kernel binaries are supported
  • USB keyboard can be used for U-Boot console input
The firmware build is standalone, which means that it uses a single binary that can be placed in the firmware section of a microSD, eMMc, or SPI flash. If the partition layout of the operating system allows it (spares the firmware section), it can be colocated within the OS image.

To prepare a microSD-card or a eMMC with u-boot-rockchip.bin in place use:

Code: Select all

dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-device-to-be-used}
Since a wise person has decided that it is a good idea to anchor the Petitboot SPI flash layout carved in stone in the mainline DTB, it is not so easy to use a mainline OS to put mainline firmware into SPI flash from there. I have therefore decided to create a self-contained solution for my firmware build.
At the serial U-Boot console, the firmware binary can be transferred from microSD or eMMC to the SPI flash.
To take advantage of this, prepare a microSD or an eMMC with the u-boot-rockchip.bin. It does not matter whether the storage contains already an OS image or is otherwise completely empty.
Start the ODROID M1 with the prepared storage in place. You have to hold the SPI recovery button (RCY) while powering up to get it started if a valid firmware is already in SPI flash.
Interrupt the autoboot timer by pressing a keyboard-key and switch to the U-Boot console.
At the console you have to choose the source device of the firmware binary.

For eMMC use:

Code: Select all

=> mmc dev 0
and for microSD use:

Code: Select all

=> mmc dev 1
Then execute:

Code: Select all

=> run mmc-fw-to-sf

MMC read: dev # 1, block # 64, count 6080 ... 6080 blocks read: OK
SF: Detected mx25u12835f with page size 256 Bytes, erase size 4 KiB, total 16 MiB
SF: 3145728 bytes @ 0x0 Erased: OK
device 0 offset 0x8000, size 0x2f8000
SF: 3112960 bytes @ 0x8000 Written: OK
to transfere the firmware into SPI flash.

To re-enter the boot menu with an autoboot timeout of e.g. 15 seconds, execute:

Code: Select all

=> botmenu 15
With firmware in SPI flash you can now put unmodified OS images on storage devices. The only requirement for this is that they use one of the supported boot methods.

To facilitate the transfer of an OS image, the ODROID M1 can be switched to USB storage mode in the console menu for a specific storage device.
Wire the ODROID M1 to your host PC via the micro USB port and a suitable cable.
After selecting the appropriate boot menu entry, the ODROID M1 switches to USB storage mode and a rotating cursor is displayed.
Pressing Ctrl-C will terminate the mode.
While in USB storage mode a new USB storage device should now be detected on the host PC. This storage device can now be used by the host PC in exactly the same way as if the corresponding ODROID M1 storage were directly connected to the host PC. This means that arbitrary tools can be used to transfer an OS image or file management tools are used to access files from an already existing file system.

If no supported boot method is available on the OS image, you can switch to the extlinux boot method by adding a single bootflow configuration file. In the /extlinux directory, simply create an extlinux.conf file with e.g. the following content as a bare minimum for autoboot without U-Boot console intervention:

Code: Select all

label ODROID-M1 fedora
        fdtdir /usr/lib/modules/linux/dtb/
        kernel /usr/lib/modules/linux/vmlinuz
        append root=PARTUUID=696d6701-01 console=ttyS02,1500000 console=tty0 rootwait
Of course, values have to be adapted to your own needs and the configuration can also be made much more complex if necessary. See here for details.

Unfortunately, I am not yet aware of any work for the Rockchip VOP2 support in U-boot, so the full range of functions can currently only be used with the serial U-Boot console.
Last edited by usual user on Tue Mar 05, 2024 6:22 am, edited 2 times in total.
These users thanked the author usual user for the post (total 10):
rooted (Wed Oct 04, 2023 4:55 am) • odroid (Wed Oct 04, 2023 9:06 am) • andi_ad42 (Sat Oct 07, 2023 5:17 pm) • butmonkeh (Sun Oct 08, 2023 4:52 am) • rmsc (Tue Oct 24, 2023 6:28 pm) • joco (Sun Oct 29, 2023 2:58 am) • iav (Mon Dec 25, 2023 1:22 pm) • n00bie (Wed Jan 17, 2024 7:06 am) • mmoll (Thu Mar 21, 2024 9:33 pm) • glenno (Thu May 02, 2024 7:26 am)

User avatar
rooted
Posts: 10633
Joined: Fri Dec 19, 2014 9:12 am
languages_spoken: english
Location: Gulf of Mexico, US
Has thanked: 822 times
Been thanked: 737 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by rooted »

Very nice write-up. Thank you for the great information and sharing your build of uboot with the community.

User avatar
mad_ady
Posts: 12061
Joined: Wed Jul 15, 2015 5:00 pm
languages_spoken: english
ODROIDs: XU4 (HC1, HC2), C1+, C2, C4 (HC4), N1, N2, N2L, H2, H3+, Go, Go Advance, M1, M1S
Location: Bucharest, Romania
Has thanked: 663 times
Been thanked: 1309 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by mad_ady »

Yes, great addition for the M1 (and I suspect other rockchip boards)!

andi_ad42
Posts: 22
Joined: Mon Nov 07, 2022 11:54 pm
languages_spoken: english, german
ODROIDs: Odroid M1
Has thanked: 7 times
Been thanked: 4 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by andi_ad42 »

Hi, thanks for sharing your efforts! I tried your firmware today, but can't get it to work (or show?) properly. I downloaded your firmware, extracted the u-boot-rockchip.img from the archive and copied it to a SD-card using

Code: Select all

sudo dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.img of=/dev/sdd
, where /dev/sdd is the SD-card in my card-reader. Putting it into the M1 with no other storage attached, doesn't yield any output on my monitor (powering up with RCY button pressed), while not pressing the RCY button brings up petiboot as normal. However, having an NVME drive with Manjaro Arm attached, it will boot up Manjaro when pressing the RCY while powering up. So I guess your firmware does work, but somehow there is no boot menu showing on my screen (HDMI). Am I missing something here? As it is, I won't be able to copy the firmware to SPI...
These users thanked the author andi_ad42 for the post:
usual user (Sat Oct 07, 2023 11:20 pm)

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

mad_ady wrote:
Thu Oct 05, 2023 8:10 pm
and I suspect other rockchip boards
Mainline support is already available for a
variety of Rockchip boards
, so firmware with similar functionality can be built for them. And Rockchip is far from the only SOC platform supported.
andi_ad42 wrote:
Sat Oct 07, 2023 4:09 pm
So I guess your firmware does work, but somehow there is no boot menu showing on my screen (HDMI). Am I missing something here?
It all works as expected. As explained in the introductory article in the last sentence, HDMI support for U-Boot is not yet available. Even the proprietary legacy U-Boot that Petitboot uses does not have this ability. The HDMI output there is provided by the minimal operating system with the help of the Linux kernel loaded from U-Boot. And this intermediate stage does not exist in my firmware, all functionality is provided natively by U-Boot. I can't really say why the HDMI output hasn't been ported yet, but I suspect it's because the mainline kernel implementation can still be improved and people are waiting for that to avoid duplicate work.
Anyway, not having an HDMI output for the firmware isn't an absolute showstopper. IMHO, any sensible SBC user tinkering with his device should have the ability to use the serial console as a minimum basic requirement. If only to be able to provide useful logs in case of a problem. Using it for the one-time installation of the firmware shouldn't be a problem either. As you've already noticed, basic functionality with a single operating system doesn't require any further interaction with the firmware. Only for maintenance or the use of the additional features is the serial console required again.
Not having an HDMI output from the firmware is also preferred by most users, as they use it as a justification to whine when something doesn't work and they don't know what's going on. And logs they don't understand only make them feel annoyed. ;-)
You could also get the firmware into the SPI flash with a modified dd command, but the prerequisites would then have to be provided in every operating system used, and that is beyond my control.

User avatar
rmsc
Posts: 20
Joined: Sun Jul 03, 2022 3:09 am
languages_spoken: english
ODROIDs: 4x M1
Location: Portugal
Has thanked: 3 times
Been thanked: 4 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by rmsc »

Thank you! This thread should be pinned!

This works really well and the menu is really well designed. It solved all the issues I had, and I can now boot CoreOS from the NVME.

One problem I hit occasionally is that if I stay in ums mode too long I get this warning:

Code: Select all

-WARNING at drivers/usb/dwc3/gadget.c:1767/dwc3_cleanup_done_reqs()!
And from then on ums on the host gets completely broken. I have to reboot it, which is really annoying. This is likely a bug in the host's kernel, which will hopefully be addressed in a future update.

:arrow: By the way, would you share the u-boot config you've created? I'd really like to be able to build u-boot locally.

User avatar
rmsc
Posts: 20
Joined: Sun Jul 03, 2022 3:09 am
languages_spoken: english
ODROIDs: 4x M1
Location: Portugal
Has thanked: 3 times
Been thanked: 4 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by rmsc »

Following up on the previous problem, this time UMS is broken on u-boot as well:

Code: Select all

=> ums 0 nvme 0
** Invalid partition 1 **
Couldn't find partition nvme 0
The nvme is properly detected, but has no partition table, could that be the issue?

Code: Select all

=> nvme info
Device 0: Vendor: 0x1e0f Rev: ECFA12.b Prod: Z18A10DXK2Q2
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
=> nvme part 0

Partition Map for NVMe device 0  --   Partition Type: EFI

Part	Start LBA	End LBA		Name
	Attributes
	Type GUID
	Partition GUID
Any ideas?

User avatar
rmsc
Posts: 20
Joined: Sun Jul 03, 2022 3:09 am
languages_spoken: english
ODROIDs: 4x M1
Location: Portugal
Has thanked: 3 times
Been thanked: 4 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by rmsc »

I think I found the solution:

Code: Select all

ums 0 nvme 0:0
It seems that if partnum is not specified, a corrupted partition table will confuse u-boot (even if it is supposed to be 0 by default).

You may want to update the bootmenu script :D

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

rmsc wrote:
Tue Oct 24, 2023 6:28 pm
One problem I hit occasionally is that if I stay in ums mode too long I get this warning:

Code: Select all

-WARNING at drivers/usb/dwc3/gadget.c:1767/dwc3_cleanup_done_reqs()!
It is known that the dwc3 driver in U-Boot is buggy. I've seen patches on the mailing lists several times that try to fix this, but the U-Boot maintainer keeps rejecting them. He insists on synchronizing the driver with the current state in the Linux kernel first, but there is no one who wants to do this task.
rmsc wrote:
Tue Oct 24, 2023 6:28 pm
By the way, would you share the u-boot config you've created?
The .config that was used for my build is uploaded here.
rmsc wrote:
Tue Oct 24, 2023 6:58 pm
You may want to update the bootmenu script
I was recently inspired by an Armbian forum post to set up a shortcut for common UMS functions in the menu for convenience. I have inserted the commands as they are documented. It is not really practical to establish a menu item for all conceivable combinations. All special variants can be used at the U-Boot console, which can be accessed via a menu item.
rmsc wrote:
Tue Oct 24, 2023 6:45 pm
Any ideas?
UMS functionality is a general U-Boot feature that should work the same for all devices. If there is indeed a misbehavior, it should be reported to mainline development so that it can be fixed for all users. Unfortunately, I don't have a spare NVME on hand to run my own experiments. But it's good to know that

Code: Select all

ums 0 nvme 0:0
can serve as a workaround.

joco
Posts: 4
Joined: Sat Oct 01, 2022 1:47 am
languages_spoken: english
ODROIDs: M1
Has thanked: 4 times
Been thanked: 1 time
Contact:

Re: Mainline firmware for ODROID-M1

Post by joco »

I've tried to compile the u-boot with the config file you've shared, and I've some experiences that I'd like to share.
(Just in case anyone else has the same idea.)

After git clone both the u-boot and the rkbin repositories, I've checked out the v2023.10 branch

Code: Select all

git checkout v2023.10
then copied the config file to the u-boot directory

Code: Select all

make menuconfig
make CROSS_COMPILE=aarch64-linux-gnu-
This attempt is resulted an error message:

Code: Select all

aarch64-linux-gnu-ld.bfd: common/board_r.o:(.data.init_sequence_r+0x110): undefined reference to `last_stage_init'
make: *** [Makefile:1764: u-boot] Error 1
I have also tried to compile the current master and have no problems with it.

Useful links on this topic:
https://github.com/u-boot/u-boot/blob/m ... ckchip.rst
https://github.com/inindev/odroid-m1/tree/main/uboot

andi_ad42
Posts: 22
Joined: Mon Nov 07, 2022 11:54 pm
languages_spoken: english, german
ODROIDs: Odroid M1
Has thanked: 7 times
Been thanked: 4 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by andi_ad42 »

@usual user: I now got myself a UART converter and am able to test your firmware for my needs more thoroughly ;)
However, after tinkering with boot scripts and extlinux.conf I noticed, that your firmware doesn't support dtb-overlays.
Is there are specific reason for this? Would it be possible for you to build a version with CONFIG_OF_LIBFDT_OVERLAY enabled to fully support everything this board has to offer?

By the way: I have bought a UART to usb converter with the cp2102 chip and seemingly there is a driver issue under linux that makes it impossible to use it with the Odroid at 1500000 baud. With windows 10 it works perfectly... Can you recommend a chip that is fully supported under linux?

Best regards and a happy new year!
Andi

User avatar
odroid
Site Admin
Posts: 42535
Joined: Fri Feb 22, 2013 11:14 pm
languages_spoken: English, Korean
ODROIDs: ODROID
Has thanked: 3733 times
Been thanked: 2102 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by odroid »

andi_ad42 wrote:
Wed Jan 03, 2024 2:07 am
By the way: I have bought a UART to usb converter with the cp2102 chip and seemingly there is a driver issue under linux that makes it impossible to use it with the Odroid at 1500000 baud. With windows 10 it works perfectly... Can you recommend a chip that is fully supported under linux?
Very weird.
Our USB-UART kit has the CP2102N chip which works fine at 1.5Mbps with Linux out of the box.
https://www.hardkernel.com/shop/usb-uar ... -kit-copy/

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

andi_ad42 wrote:
Wed Jan 03, 2024 2:07 am
I have bought a UART to usb converter with the cp2102 chip and seemingly there is a driver issue under linux that makes it impossible to use it with the Odroid at 1500000 baud.
It's not a driver issue, it's a matter of hardware specification:
CP2102.png
CP2102.png (377.06 KiB) Viewed 1264 times
CP2102N.png
CP2102N.png (293.1 KiB) Viewed 1264 times
Linux is likely to stick to the specs, while Windows is running it outside the specs. Stable operation cannot be guaranteed under all circumstances.
For the selection of the UART adapter, it is not the chipset used that is of utmost importance, but whether the desired baud rate (1.5Mbit/s) and the necessary signal voltage (3.3V) are supported.
andi_ad42 wrote:
Wed Jan 03, 2024 2:07 am
Is there are specific reason for this?
The reason for this is that it is not necessary.
The board does not provide a way to automatically detect required overlays, nor does U-Boot provide an infrastructure to grant the application of overlays for various SOCs. There is absolutely no basis for the dynamic application of overlays.
My kernel packages contain only a "limited" selection of supported boards. See tree-dtb.log for reference.
To establish a dynamic overlay application management for them would not scale in any way. And at 10 ... 15 ... Kernels installed at the same time it would not be feasible in any way, especially since there is absolutely no need for it.
The key word is "static" applied overlays.
E.g. for M1 my default DTB looks like this: rk3568-odroid-m1-con1-lk-oled1.dtb
It is composed by:

Code: Select all

fdtoverlay --input rk3568-odroid-m1-native.dtb --output rk3568-odroid-m1-con1-lk-oled1.dtb overlay/rk3568-odroid-m1-con1.dtbo overlay/rk3568-odroid-m1-lk-oled1.dtbo
As the

Code: Select all

fdtdir /usr/lib/modules/linux/dtb/
extlinunx.conf option loads

Code: Select all

rockchip/rk3568-odroid-m1.dtb
for M1 by default, I have a symlink pointing to my desired default DTB (rk3568-odroid-m1.dtb -> rk3568-odroid-m1-con1-lk-oled1.dtb). In this way, I can keep several DTBs with different overlay sets and select them by simply adjusting the symlink for the default one.
With e.g.:

Code: Select all

fdt /usr/lib/modules/linux/dtb/amlogic/meson-g12b-odroid-n2-plus-con1-opp-nor-key.dtb
an explicit DTB can be selected in a separate boot stanza. For the M1 this is not quite as practical, but for the N2+ with its HDMI firmware menu display it is very handy to temporarily choose a different configuration at boot time.
For the N2+ firmware

Code: Select all

fdtdir /usr/lib/modules/linux/dtb/
of course
loads

Code: Select all

/amlogic/meson-g12b-odroid-n2-plus.dtb
by default. And the T4 firmware pulls in

Code: Select all

rockchip/rk3399-nanopc-t4.dtb
So I have an OS image that can be used unmodified by any board, as long as there is a suitable firmware available that supports extlinux boot. Overlays can be used for everyone in the same way and for everyone in the same image at the same time.
Now try to explain to me how you think your planned implementation can meet all the requirements with dynamic overlay application likewise.
andi_ad42 wrote:
Wed Jan 03, 2024 2:07 am
to fully support everything this board has to offer?
The only missing feature for full board support is the vop2 driver, but this applies to all rk35xx SOCs. With this driver, the U-Boot console could also be used with all other supported displays and you would not have to rely solely on the serial console.
tree-dtb.log
(34.29 KiB) Downloaded 42 times
These users thanked the author usual user for the post (total 2):
odroid (Thu Jan 04, 2024 9:25 am) • andi_ad42 (Thu Jan 04, 2024 9:13 pm)

andi_ad42
Posts: 22
Joined: Mon Nov 07, 2022 11:54 pm
languages_spoken: english, german
ODROIDs: Odroid M1
Has thanked: 7 times
Been thanked: 4 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by andi_ad42 »

usual user wrote:
Thu Jan 04, 2024 5:30 am
It's not a driver issue, it's a matter of hardware specification:CP2102.pngCP2102N.pngLinux is likely to stick to the specs, while Windows is running it outside the specs. Stable operation cannot be guaranteed under all circumstances.
For the selection of the UART adapter, it is not the chipset used that is of utmost importance, but whether the desired baud rate (1.5Mbit/s) and the necessary signal voltage (3.3V) are supported.
Ok, seems like my cheap adapter board uses a chip version that doesn' fully support the 1.5Mbit/s - for now, it worked using the Win10 driver, but if I need one in the future, I will know what to look out for - thanks :-)

Regarding the device tree overlay: Sorry, being someone with limited knowledge about this stuff I just didn't know that applying an overlay "static" is possible/so easy. I thought the dynamic application was the standard way because that's whats described in the hardkernel wiki (and raspberry pi documentation, which is the only other SBC I used so far). So, thanks again for the detailed explanation - I applied my overlays as you said and everything just works now :)

Best regards
Andi

n00bie
Posts: 5
Joined: Wed Jan 17, 2024 7:04 am
languages_spoken: english, dutch
ODROIDs: ODROID-M1
Has thanked: 2 times
Been thanked: 0
Contact:

Re: Mainline firmware for ODROID-M1

Post by n00bie »

Hi. Thank you very much for your u-boot build! It smoothly boots F39 from the NVMe drive :D Is there perhaps a public repo (gitlab/github?) where I can see how you built it? I previously built the odroid-m1-rk3568 config from the tree at https://github.com/Kwiboo/u-boot-rockchip That worked fine but did not have your very useful menu. I'm interested to learn how to add that. Anyway, thanks again for sharing. Much appreciated!

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

n00bie wrote:
Wed Jan 17, 2024 7:18 am
It smoothly boots F39 from the NVMe drive
It will do the same from any other storage device the M1 supports you put the image on. You can even have different images on multiple storage devices at the same time and then choose which one to boot via the menu option. This is interesting, for example, if you want to try out a nightly image. If you copy it to a microSD card, you don't even need to use the boot menu option, because the valid boot method found first will start automatically and the microSD card will be scanned first. After removing the microSD card, the NMVE's system will automatically booted again.
n00bie wrote:
Wed Jan 17, 2024 7:18 am
Is there perhaps a public repo (gitlab/github?) where I can see how you built it?
Such a thing does not even exist locally. I'm just rebuilding the fedora uboot-tools package. Of course, I had to extend it to build the firmwares for my devices, because none can be offered by Fedora. This is because, for licensing reasons, this is not allowed for one or the other binary bloob that is still necessary. But not really complicated due to the mainline support available in U-BOOT. You can't build the binary bloobs yourself anyway, so all you need to do is copy them in place. Of course, I'm also adding Kwiboo's patches, among others, but as you can see from the compare, they don't really contain anything M1 relevant anymore. So pure mainline U-Boot source is therefore sufficient. Basically, it's just the deviations from the default config according to my personal preferences.
n00bie wrote:
Wed Jan 17, 2024 7:18 am
That worked fine but did not have your very useful menu.nu. I'm interested to learn how to add that.
The bootmenu command is enabled by the configuration options "AUTOBOOT_MENU_SHOW=y" and "CMD_BOOTMENU=y", as can be seen in the .config file referenced a few posts earlier. Its use is explained in the documentation that comes with the U-Boot source code.

n00bie
Posts: 5
Joined: Wed Jan 17, 2024 7:04 am
languages_spoken: english, dutch
ODROIDs: ODROID-M1
Has thanked: 2 times
Been thanked: 0
Contact:

Re: Mainline firmware for ODROID-M1

Post by n00bie »

Hi, thank you for your feedback!
usual user wrote:
Thu Jan 18, 2024 5:51 am
It will do the same from any other storage device the M1 supports you put the image on. You can even have different images on multiple storage devices at the same time and then choose which one to boot via the menu option. This is interesting, for example, if you want to try out a nightly image. If you copy it to a microSD card, you don't even need to use the boot menu option, because the valid boot method found first will start automatically and the microSD card will be scanned first. After removing the microSD card, the NMVE's system will automatically booted again.
I'm assuming this is with your u-boot-rockchip.img written to the SPI right? Before I do that, is that reversible? So if I dd spiupdate_odroidm1_20220304.img to an SD card and copy spiboot-20240109.img to the SD cardt as spiboot.img and boot the M1 from this SD card, it will be able to write spiboot-20240109.img to the SPI returning it to its original state?

For F40 it seems the ARM nightlies will soon go through a new build process. I found no details but the proposal: https://lists.fedoraproject.org/archive ... JQOYWNBR/ . I hope that the first partition is moved from 2048 to 32768 so it's possible to have u-boot and the Fedora image on a single SD card.
usual user wrote:
Thu Jan 18, 2024 5:51 am
Such a thing does not even exist locally. I'm just rebuilding the fedora uboot-tools package. Of course, I had to extend it to build the firmwares for my devices, because none can be offered by Fedora. This is because, for licensing reasons, this is not allowed for one or the other binary bloob that is still necessary. But not really complicated due to the mainline support available in U-BOOT. You can't build the binary bloobs yourself anyway, so all you need to do is copy them in place. Of course, I'm also adding Kwiboo's patches, among others, but as you can see from the compare, they don't really contain anything M1 relevant anymore. So pure mainline U-Boot source is therefore sufficient. Basically, it's just the deviations from the default config according to my personal preferences.
Understood. About the blobs: Fedora's uboot-tools.spec at https://src.fedoraproject.org/rpms/uboo ... tools.spec has a BuildRequires: arm-trusted-firmware-armv8 from https://src.fedoraproject.org/rpms/arm- ... mware.spec which contains the bl31 blob. So AFAICT it is possible to create a customized uboot-tools project on https://copr.fedorainfracloud.org/ to generate your builds should you want to.
usual user wrote:
Thu Jan 18, 2024 5:51 am
The bootmenu command is enabled by the configuration options "AUTOBOOT_MENU_SHOW=y" and "CMD_BOOTMENU=y", as can be seen in the .config file referenced a few posts earlier. Its use is explained in the documentation that comes with the U-Boot source code.
Thanks for explaining that and the link. Time to tinker with the configuration options.

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

n00bie wrote:
Sat Jan 20, 2024 3:00 am
I'm assuming this is with your u-boot-rockchip.img written to the SPI right?
Not necessarily, all you need is an otherwise empty microSD card with just the firmware in place. Of course, you have to press the RCY button every time you boot to skip a valid SPI firmware. If you now copy the raw unmodified fedora image to another storage medium (e.g. USB stick), the firmware will find the OS there and boot it. The advantage of having the firmware in SPI flash only makes the microSD card port available for an OS and saves the RCY button press when booting.
The OS on the USB stick remains device-agnostic and can be started unmodified, e.g. from an ODROID-N2+, of course a firmware suitable for the N2+ is required. But it's in the SPI flash there anyway for me.
Such a USB stick is suitable for all devices as long as a suitable firmware for booting from a different location is available and sufficient mainline kernel support (DTB) is available.
With an x86 architecture device, no one comes up with the idea of placing the ROM BIOS of the motherboard on the OS drive.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
Before I do that, is that reversible?
I don't see any reason why not. SPI flash is storage that can be repeatedly erased and rewritten.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
it will be able to write spiboot-20240109.img to the SPI returning it to its original state?
I don't know exactly how the Petitboot recovery process works, but I would expect it to be able to restore its firmware regardless of what code was previously in the SPI flash area to be used. If necessary, you can also erase the area beforehand using the U-Boot console.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
For F40 it seems the ARM nightlies will soon go through a new build process.
It only changes the image build process, but the image structure remains the same for now, as you can see from the comments.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
https://src.fedoraproject.org/rpms/arm- ... mware.spec which contains the bl31 blob.
Only the necessary support is not even remotely available yet, not to mention TPL.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
So AFAICT it is possible to create a customized uboot-tools project on https://copr.fedorainfracloud.org/ to generate your builds
I suspect that the same license specifications for the Rockchip blobs that prevent them from being included in Fedora will prevent them from being used there as well.

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

I have just installed an updated version of my firmware build into the SPI flash of my ODROID-M1. In case anyone is interested in a preview of 2024.04, the firmware is uploaded and the download link in the first post adjusted.

n00bie
Posts: 5
Joined: Wed Jan 17, 2024 7:04 am
languages_spoken: english, dutch
ODROIDs: ODROID-M1
Has thanked: 2 times
Been thanked: 0
Contact:

Re: Mainline firmware for ODROID-M1

Post by n00bie »

usual user wrote:
Sun Jan 28, 2024 9:54 am
I have just installed an updated version of my firmware build into the SPI flash of my ODROID-M1. In case anyone is interested in a preview of 2024.04, the firmware is uploaded and the download link in the first post adjusted.
Thanks for sharing the update. I'll give that a try.

n00bie
Posts: 5
Joined: Wed Jan 17, 2024 7:04 am
languages_spoken: english, dutch
ODROIDs: ODROID-M1
Has thanked: 2 times
Been thanked: 0
Contact:

Re: Mainline firmware for ODROID-M1

Post by n00bie »

n00bie wrote:
Sat Jan 20, 2024 3:00 am
I'm assuming this is with your u-boot-rockchip.img written to the SPI right?
usual user wrote:
Sat Jan 20, 2024 6:05 am
Not necessarily, all you need is an otherwise empty microSD card with just the firmware in place. Of course, you have to press the RCY button every time you boot to skip a valid SPI firmware. If you now copy the raw unmodified fedora image to another storage medium (e.g. USB stick), the firmware will find the OS there and boot it. The advantage of having the firmware in SPI flash only makes the microSD card port available for an OS and saves the RCY button press when booting.
Got it. Having to press the RCY button is something I want to get rid off.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
Before I do that, is that reversible?
usual user wrote:
Sat Jan 20, 2024 6:05 am
I don't see any reason why not. SPI flash is storage that can be repeatedly erased and rewritten.
Ok, good to know.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
it will be able to write spiboot-20240109.img to the SPI returning it to its original state?
usual user wrote:
Sat Jan 20, 2024 6:05 am
I don't know exactly how the Petitboot recovery process works, but I would expect it to be able to restore its firmware regardless of what code was previously in the SPI flash area to be used. If necessary, you can also erase the area beforehand using the U-Boot console.
Petitboot recovery steps, probably helpful for others:

Download the latest spiupgrade image from http://ppa.linuxfactory.or.kr/images/pe ... /odroidm1/
spiupdate_odroidm1_20220304.img.xz
spiupdate_odroidm1_20220304.img.xz.md5sum

Check the integrity of the spiupdate image:
$ md5sum -c spiupdate_odroidm1_20220304.img.xz.md5sum
spiupdate_odroidm1_20220304.img.xz: OK

and download the latest spiboot image (currently):
spiboot-20240109.img
spiboot-20240109.img.md5sum

Check the integrity of the spiboot image:
$ md5sum -c spiupdate_odroidm1_20220304.img.xz.md5sum
spiboot-20240109.img: OK

Write the spiupdate image to the SD card:
# xzcat spiupdate_odroidm1_20220304.img.xz | dd status=progress of=/dev/sdX conv=notrunc,fsync oflag=direct

Mount the first partition on the SD card (it's about 50MB in size)
# mount /dev/sdX1 /mnt

And copy the latest spiboot image file to that partition on the SD card. Make sure you rename it to spiboot.img !!!
# cp spiboot-20240109.img /mnt/spiboot.img

Unmount /dev/sdX1
# sudo umount /mnt

Put the SD card into the ODROID-M1 and power it on while pressing the RCY button so it boots from the SD card.

Wait while it writes spiboot.img to SPI.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
For F40 it seems the ARM nightlies will soon go through a new build process.
usual user wrote:
Sat Jan 20, 2024 6:05 am
It only changes the image build process, but the image structure remains the same for now, as you can see from the comments.
Ah right. I hope they start the first sector if the first partition at 32768 like armbian, arch and debian. Right now it's at 2048 and I read that the 1-2047 space is too small to write u-boot too.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
https://src.fedoraproject.org/rpms/arm- ... mware.spec which contains the bl31 blob.
usual user wrote:
Sat Jan 20, 2024 6:05 am
Only the necessary support is not even remotely available yet, not to mention TPL.
n00bie wrote:
Sat Jan 20, 2024 3:00 am
So AFAICT it is possible to create a customized uboot-tools project on https://copr.fedorainfracloud.org/ to generate your builds
usual user wrote:
Sat Jan 20, 2024 6:05 am
I suspect that the same license specifications for the Rockchip blobs that prevent them from being included in Fedora will prevent them from being used there as well.
Hmm, let's hope the 3568/3588 will soon get added to the trusted firmware.

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

Rebased on 2024.04-rc2-g8190a7d, nothing ODROID-M1 specific has changed. But a lot of general fixes and improvements have landed. Of course, the ODROID-M1 build also benefits from this.
In case anyone is interested, the firmware is uploaded and the download link in the first post adjusted.
These users thanked the author usual user for the post (total 3):
n00bie (Fri Mar 08, 2024 11:00 pm) • joco (Sat Mar 09, 2024 1:35 am) • mmoll (Thu Mar 21, 2024 9:33 pm)

usual user
Posts: 140
Joined: Sat Sep 10, 2022 10:47 pm
languages_spoken: english
Has thanked: 4 times
Been thanked: 55 times
Contact:

Re: Mainline firmware for ODROID-M1

Post by usual user »

usual user wrote:
Sat Jan 20, 2024 6:05 am
Only the necessary support is not even remotely available yet, not to mention TPL.

feat(rockchip): add RK3566/RK3568 Socs support

Wow! One year and eight months later, let's see how long TPL takes.

n00bie
Posts: 5
Joined: Wed Jan 17, 2024 7:04 am
languages_spoken: english, dutch
ODROIDs: ODROID-M1
Has thanked: 2 times
Been thanked: 0
Contact:

Re: Mainline firmware for ODROID-M1

Post by n00bie »

usual user wrote:
Sun Jun 09, 2024 8:34 pm
Wow! One year and eight months later, let's see how long TPL takes.
Thanks for mentioning it. On the bright site, I can now try to build u-boot 2024.rc5 with TA and see if I can make it do something similar to your much appreciated builds.

Post Reply

Return to “Projects”

Who is online

Users browsing this forum: No registered users and 1 guest