Jump to content

Odroid M1

Igor

By Igor
in Odroid M1

 Share

Recommended Posts

Shaun Maher

Shaun Maher

Posted
Posted

Hi all.

 

Regarding Petitboot that comes pre-installed in the Odroid M1's SPI.  I 100% understand that the current image does not support Petitboot.  I understand it is a work in progress.  Is the intention though, to have the final production image support
Petitboot?

 

My understanding (and am happy to be corrected) is that without petitboot, booting from SATA/NVMe, without any other storage devices attached, isn't possible (u-boot limitation?).

 

I've been stuffing about and I have been able to get the current WIP build copied to NVMe SSD and booting from petitboot (with one outstanding limitation).  At a high level:

  • Copy the "Armbian_22.11.0-trunk_Odroidm1_kinetic_edge_6.1.0-rc1.img.xz" to a USB stick.  Not DD/Etcher/whatever.  Just copied to the USB stick
    • It might be possible to download the image directly within the petitboot shell but the bundled busybox wget command doesn't support https.
  • Boot the M1 into petitboot with the above USB stick plugged in.
  • Extract and DD the image onto the NVMe block device
    • The USB stick will likely already be mounted in /usr/var/petitboot/mnt/dev/sda1/, so...
    • xz -d -c /usr/var/petitboot/mnt/dev/sda1/Armbian_22.11.0-trunk_Odroidm1_kinetic_edge_6.1.0-rc1.img.xz | dd of=/dev/nvme0n1 bs=4k
  • Tamper with the installed image a little before attempting to boot it:
    • mkdir /mnt/nvme0n1p1
    • mount /dev/nvme0n1p1 /mnt/nvme0n1p1
    • rm /mnt/nvme0n1p1/boot/boot.scr (this file existing seems to the petitboot parser segfault)
    • rm /mnt/nvme0n1p1/boot/boot.ini  (for good measure)
    • Create a petitboot kboot.conf file with suitable settings:
      • echo "Armbian=/boot/Image initrd=/boot/uInitrd dtb=/boot/dtb/rockchip/rk3568-odroid-m1.dtb root=/dev/disk/by-label/armbi_root rootwait rootfstype=ext4 consoleblank=0 loglevel=5 splash=verbose earlycon console=ttyS2,1500000"  >/mnt/nvme0n1p1/etc/kboot.conf
    • Reboot
      • echo 1 > /proc/sys/kernel/sysrq
      • echo b > /proc/sysrq-trigger

 

The main limitation with the above, which might be entirely because I'm only a few hours into learning about petitboot, is that using the above method still requires manual intervention at boot time.  The above will add Armbian into the petitboot menu but it won't boot it automatically.  You need to select it with the arrows and hit enter to start it booting.  I'm going to post some questions on the Odroid forum and hopefully get this final quirk resolved.

 

Cheers

Shaun

0
Igor

Igor

Posted
  • Author
Posted
  On 11/2/2022 at 8:03 AM, Shaun Maher said:

current image does not support Petitboot.

Expand  

 

Idea is to get rid of everything that smells on proprietary boot loader and all dirty hacks that are required that this hardware boots up. But when this is not finished and become stable there is little to do.

0
hi-ko

hi-ko

Posted
Posted

a big thumbs up! With the odroidm1 sid-build I managed for the first time to successfully test my use case with lxd and zfs!

Only problem I had:
After installing the zfsutils-linux the kernel module was missing:
  

# /sbin/modprobe zfs
modprobe: FATAL: Module zfs not found in directory /lib/modules/5.19.0-odroid-arm64

I got it working by manually installing/compiling the kernel module:
  

apt install linux-headers-arm64 zfs-dkms


Is this an issue in the debian upstream or in the armbian build?
I am looking forward to a first release!

0
rpardini

rpardini

Posted
Posted

I've had great success with the new 6.1-rcX based images. Applying mmind's tree for the DTS only. Good chance we'll be able to merge this board with the rest of rockchip64 around the 6.2 timeframe, with zero patches if that DTS is merged.

 

Keep in mind these images don't use Petitboot "the kexec stuff" itself but does use the u-boot included in SPI (which is part of Petitboot), and require the env to skip petitboot.

 

 

 

 

0
rpardini

rpardini

Posted
Posted
  On 11/2/2022 at 8:03 AM, Shaun Maher said:

Tamper with the installed image a little before attempting to boot it:

  • mkdir /mnt/nvme0n1p1
  • mount /dev/nvme0n1p1 /mnt/nvme0n1p1
  • rm /mnt/nvme0n1p1/boot/boot.scr (this file existing seems to the petitboot parser segfault)
  • rm /mnt/nvme0n1p1/boot/boot.ini  (for good measure)
  • Create a petitboot kboot.conf file with suitable settings:
    • echo "Armbian=/boot/Image initrd=/boot/uInitrd dtb=/boot/dtb/rockchip/rk3568-odroid-m1.dtb root=/dev/disk/by-label/armbi_root rootwait rootfstype=ext4 consoleblank=0 loglevel=5 splash=verbose earlycon console=ttyS2,1500000"  >/mnt/nvme0n1p1/etc/kboot.conf
  •  

 

Expand  

 

Yeah, you can convince Petitboot to `kexec` into Armbian's kernel. Probably can be done on other Petitboot boards too. By then, vendor's uboot, and vendor's kernel is already loaded, `kexec`'ing then into an Armbian mainline kernel. "It works" until it doesn't...

0
usual user

usual user

Posted
Posted
  On 11/4/2022 at 6:23 PM, rpardini said:

Good chance we'll be able to merge this board with the rest of rockchip64 around the 6.2 timeframe, with zero patches if that DTS is merged.

Expand  

I doubt it, if mainline development continues at the same rate as before, the next WIP patches for the pending drivers will certainly be available at this time.

0
j0ta

j0ta

Posted
Posted

After compiling Bullseye everything is ok, just one little problem I updated firmware using 

armbian-firmware-full

and it downgraded from 22.11.0-trunk to 22.08.6

0
rpardini

rpardini

Posted
Posted
  On 12/13/2022 at 10:02 AM, usual user said:

Odroid-M1 support has just landed  so will be available with 6.2.0-rc1 out-of-the-box. RGA support can be wired on top (v4l2-compliance.log), but the DMA deficiency for 32-bit addresses needs to be addressed for devices with more than 4GB of RAM.

Expand  

 

Excellent news @usual user. I've bumped Armbian to 6.1 plus the DTS patches. 

My own image at https://github.com/rpardini/armbian-release/releases/download/20221213a/Armbian_20221213a-rpardini_Odroidm1_kinetic_edge_6.1.0.img.xz

Igor has community images too, including desktops... https://github.com/armbian/community/releases (might be some 6.1-rcX still, should be updated the next few days).

 

Any news about ATF and u-boot?

0
usual user

usual user

Posted
Posted
  On 12/13/2022 at 6:27 PM, rpardini said:

Any news about ATF and u-boot?

Expand  

TF-A is progressing slowly, but there seem to be still open questions.
The DT rebase of u-boot has taken place. It still takes a rebase to be up to date, but this is only a small thing, because the basic structure conversion has already taken place.

But I haven't seen any movement in uboot WIP trees that I'm aware of. IMHO they are waiting to see how the TF-A development turns out in the end to develop u-boot accordingly further. I will report when I get news.
But the most important thing is that for the kernel only the rkvdec2 support is missing, and for the userspace only the FFmpeg v4l2-request support is missing to be usable out-of-the-box with pure mainline support for standard applications. It is thus available for all distributions without special effort for the Odroid-M1. They only have to maintain the distribution-specific modifications that they apply for other devices anyway.
I'm currently playing with jernej's FFmpeg patches for v4l2-request support and VP8 acceleration seems to work. H.264 fails with this error: 

[h264_v4l2m2m @ 0xaaaabfc5ae10] Could not find a valid device
[h264_v4l2m2m @ 0xaaaabfc5ae10] can't configure decoder

But I don't know if the 5.1.2 paches basically work or how I can inspect the FFmpeg framework appropriately. With the gstreamer framework, however, everything works as expected.

1
Kiendeleo

Kiendeleo

Posted
Posted

I know a solution is being worked on for the lack of NVME boot capability.

 

In the meantime, is there a way to install only the necessary files to an eMMC drive and the rest to an NVME to work around this limitation?

0
usual user

usual user

Posted
Posted
  On 12/28/2022 at 4:42 PM, Kiendeleo said:

is there a way to install only the necessary files to an eMMC drive and the rest to an NVME to work around this limitation?

Expand  

Sure, with distro-boot only a suitable firmware in the firmware area and three files in a partition accessible from the firmware is required.
Because I still have Petitboot in SPI flash, I used @rpardini's initial image as boot trampoline, because Petitboot requires a very special partition layout. Then the kernel binary, the DTB and extlinux.conf copied into the partition, and my operating system is entirely run by the NVME. It should be noted that the kernel binary must be uncompressed, as the legacy firmware does not even support compressed kernel binaries.
I use a microSD card as boot trampoline, because the firmware only reads it, and I only mount it from the operating system read-write if I want to update the kernel binary or the DTB. But an eMMC works the same way. The only annoying thing about this method is the need to copy the kernel binary and DTB over, but this is a simple workaround until mainline firmware is available.

0
rpardini

rpardini

Posted
Posted
  On 12/28/2022 at 4:42 PM, Kiendeleo said:

In the meantime, is there a way to install only the necessary files to an eMMC drive and the rest to an NVME to work around this limitation?

Expand  

 

I used `armbian-install` (nee `nand-sata-install`) for this with success.

It can use a small boot partition (/boot) on the eMMC to jumpstart kernel, but mount root in NVMe.

Take care to not overwrite SPI/MTD accidentally.

 

1
Kiendeleo

Kiendeleo

Posted
Posted
  On 12/28/2022 at 7:33 PM, rpardini said:

I used `armbian-install` (nee `nand-sata-install`) for this with success.

Expand  

The first time I ran this command, I was only presented with "Boot from SD" and "Boot from SPI" as options. The only drives attached to the board were an eMMC and an NVME Drive. I chose the "Boot From SD" and selected my NVME drive as the target in the next step, which seems to work. After completing the conversion and rebooting, if I run the `sudo armbian-install` command, I am given options for the eMMC. It is working correctly. Is this a bug? Also, is there a manpage somewhere for the `armbian-install` command?

0
usual user

usual user

Posted
Posted

My first u-boot build:

  Reveal hidden contents

 

1
Vodalex

Vodalex

Posted
Posted

Hello guys!

 

Just tried another release (community) of armbian for Odroid M1 (Armbian_23.02.0-trunk_Odroidm1_sid_edge_6.1.11.img)

Network seems to work fine here but why does the device show random ip instead of using the physical one, printed on the board?

0
usual user

usual user

Posted
Posted
  On 3/31/2023 at 11:57 AM, rpardini said:

where lie the patches for this?

Expand  

They are floating around. Some of them are in flight to land in mainline, some are WIP in heavy flux. In terms of functionality, mainline would not be able to do more than legacy so far. And since your offered legacy firmware works so far, there is currently no reason to do the work now to use the current mainline version. It is only interesting for someone who wants to add e.g. VOP2 or NVME driver support and ports the drivers from Linux kernel. For all pure users it is easier to wait until all outstanding components have landed and then just use mainline. Anyway, my SPEC file for the uboot-tools package is now ready to build M1 firmware as soon as needed. However, this will certainly take until 2023.07 at the earliest, because there are still some components under discussion and 2023.04 should be available next week.

0
rpardini

rpardini

Posted
Posted
  On 4/1/2023 at 1:38 PM, usual user said:

They are floating around

Expand  

 

Thanks for the report. For a minute I thought something more radical had happened, but it seems situation is mostly the same. In the end, it's about SPI -> NVMe boot, possibly with basic EFI support, that would shift the status quo.

For now it seems "interested-enough" users can manage to make pboot boot the Armbian image and make it work decently well for most server/NAS/etc needs.

We do have a few outstanding issues, like Eth MAC being random, any idea about that? (usually also at u-boot level, but I haven't looked into how HK does things)

 

0
Michel Lamoré

Michel Lamoré

Posted
Posted (edited)

I've recently installed Armbian 23.02 on my Odroid. It boots faster than the official Ubuntu 20.04 build from Hardkernel, which I find quite impressive! One problem I run into is how my display looks. When I set the resolution to 1280*720, everything looks fine. However, when I set the resolution to the native resolution of my monitor, 1680*1050, letters are not always correctly displayed. Is this some kind of HiDPI font issue? The display I am using is connected via VGA (using a HDMI to VGA adapter). On the official build text looks normal at 1680*1050.


PXL-20230405-095701773.jpg

(1280*720 on Armbian)

 

PXL-20230405-095721361.jpg (1680*1050 on Armbian. Notice the distorted text below "fractional scaling")

 

PXL-20230405-100912795.jpg (1680*1050 on Ubuntu, no distortion here)

Edited by Michel Lamoré
Added more details
0
usual user

usual user

Posted
Posted (edited)

@Kwiboo did a fantastic job. Mainline u-boot becomes usable (console.log) for me.
It enumerates my different systems on different storage media and can natively load the boot components from them.
The use of compressed kernels does not work yet, it bails out like this:

  Reveal hidden contents

The u-boot control still has to be done with the serial console, as HDMI support is still missing, but it is still an early stage and the development is vivid.

 

In the meantime, I have solved the problem with loading compressed kernels for me. Also, I can now use a USB keyboard (usbkbd) for stdin. Both require a correction of the mainline code, but since unfortunately too many in-flight patches have not yet landed, it is still too early to go into detail here. If you already want to play with the functionality that will be provided by the mainline u-boot in the future out-of-the-box, I have uploaded my firmware build here. The firmware can be put in place by: 

dd bs=512 seek=64 conv=notrunc,fsync if=u-boot-rockchip.bin of=/dev/${entire-device-to-be-used}

into the firmware area of an SD card or an eMMC. If it is started during power-up by holding the SPI recovery button (RCY), it will scan all connected storage media for a usable bootflow.

Supported boot methodes are: extlinux (extlinux.conf), efiboot and legacy-boot (boot.scr).
As soon as video support is available, "U-Boot Standard Boot" will be fully usable, but VOB2 support is still open.

Edited by usual user
0
mhoffrogge

mhoffrogge

Posted
Posted

@usual user

  On 4/22/2023 at 12:04 PM, usual user said:

I have solved the problem with loading compressed kernels for me. Also, I can now use a USB keyboard (usbkbd) for stdin. Both require a correction of the mainline code,

Expand  

I would be interested in those adaptions - can you provide those changes as a patch or is there a fork repo branch where those patches can be looked up?

0
usual user

usual user

Posted
Posted
  On 6/19/2023 at 12:14 PM, mhoffrogge said:

can you provide those changes

Expand  

Since I haven't gotten any feedback on my build so far, I don't see much sense in it. In my experience, Armbian users tend to stick to legacy methods  and my extensions only affect the upcomming U-Boot Standard Boot. In addition, the adoption of reviewed-by patches from the patchwork to the mainline tree seems to have stalled. So it may take some time until the general support is available out-of-the-box. And these are valuable improvements to the Rockchip platform, which also benefit ODROID-M1 support.
Since Armbian already has a working boot method, I don't see any reason for an  underpaid Armbian developer to invest his valuable time in an unfinished solution that anyone can have for free when everything finally lands.
For me, it's different story because my preferred distro requires different prerequisites. I had made my build available so that others could save themselves the trouble of self-building, but there doesn't seem to be any particular interest.

0
emk2203

emk2203

Posted
Posted (edited)

What are the recommended steps to get the M1 boot from eMMC with the current standard Armbian image?

Just skip spi boot, write image to eMMC as usual and boot without a µSD card?

 

@usual userI would very much like to test your build and would also give feedback after.

 

I have just discovered the M1 and I think it is necessary to have as many options as possible. There may be interest from others who, like me, are late to the game, but for this we would need to be able to replicate your build. From what you write, it sounds very promising so far.

 

It would also open the door for more variety in the distributions offered.

Edited by emk2203
additional topic
0
usual user

usual user

Posted
Posted
  On 8/9/2023 at 9:03 AM, emk2203 said:

late to the game, but for this we would need to be able to replicate your build.

Expand  

With the release of U-Boot v2023.10, everyone will be able to create their own firmware on a stable basis.
The only difference to other firmware builds is a  

make odroid-m1-rk3568_defconfig

to setup a suitable configuration for the ODROID-M1.
If you want to build beforehand, you need to dig mailing lists and patchwork for non-landed fixes and improvements to pick them up.

 

  On 8/9/2023 at 9:03 AM, emk2203 said:

It would also open the door for more variety in the distributions offered.

Expand  

As you can see here this has already happened. They use distributions that are not in any way designed specifically for the ODROID-M1 and where Petitboot is not able to support the bootflow used. And this is possible because the rk3568 SOC has sufficient mainline kernel support.

0
emk2203

emk2203

Posted
Posted

Wow, thanks, these are great news! I wait until the 2023.10 release then. I cross my fingers, though -- in the ARM world, I have seen promising stuff delayed for ages or infinitely quite often.

0
rpardini

rpardini

Posted
Posted

https://github.com/armbian/build/pull/5606

 

Testing image:

https://github.com/rpardini/armbian-release/releases/download/23.08.18-rpardini-434/Armbian_23.08.18-rpardini-434_Odroidm1_bookworm_edge_6.5.0-rc6.img.xz

 

#### `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works; bump kernel to 6.5-rcX

- `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.4.y, update config, rebase patches to 6.4.10
- `odroidm1`/`edge` (`rk3568-odroid`): bump to 6.5-rc6; manually fix RK808 breakage in .config; externalize overlays; use Makefile autopatcher; rebase patches
- `odroidm1`/`edge` (`rk3568-odroid`): drop 6.3 and 6.4 patches
- `odroidm1`: de-infest Petitboot 🔥 use Kwiboo's 2023.10 u-boot; UMS works
  - using Kwiboo's `rk3568-2023.10` branch  with BINMAN-handled blobs
  - patches (defconfig unless indicated):
    - boot usb first (rockchip-common)
    - blink leds & keep red one one on preboot; reset SPI env once after deinfesting from Petitboot
    - change usb_host0_xhci to otg (u-boot dtsi)
    - enable DM_GADGET, UMS 🔥 and RockUSB
  - **usage instructions**:
    - build & burn image to SD card
    - insert SD card into board
    - **hold the recovery (RCY) button** and power on the board
    - watch board boot
    - **de-infest Petitboot**: use `armbian-install` to install bootloader to MTD
      - if you don't, you'll need to hold the recovery button every boot
      - optionally: use `armbian-install` to install OS to eMMC/NVMe/USB
    - power-off board
    - remove SD card (new u-boot always boots SD first!)
    - boot into your newly de-infested machine
      - boot order: USB, SD, MMC, NVME, SCSI
  - de-infested machine can now boot (directly) from USB/SATA/NVMe, possibly via EFI:
    - Armbian UEFI-arm64
    - Fedora 38 aarch64
    - HASSOS for ODROID-M1
    - Talos arm64
    - others...
  - extra: new u-boot by Kwiboo (with GMAC patches) gives us stable MAC address
    - although it is based on cpuid#, doesn't match the HK sticker on the board
      - run `fw_setenv ethaddr XX:XX:XX:XX:XX:XX` to change eth addr in SPI flash environment if needed
  - `odroidm1`: update DDR/BL31 blobs (this depends on https://github.com/armbian/rkbin/pull/20)

1
emk2203

emk2203

Posted
Posted

@rpardiniThis testing image looks super promising. Basically everything from my wish list satisfied:

  • stable MAC address
  • boot from whatever is available via MTD/SPI
  • sane boot order which allows for rescue interventions

Only missing thing for me would be this image based on an Ubuntu userland, but it's just habit. Bookworm is not lacking in comparison.

 

Going to test it out as soon as I can, but first I need to properly diagnose a Odroid HC4 HDMI bug for eventually RMA'ing the board.

0
rpardini

rpardini

Posted
Posted
  On 8/19/2023 at 10:38 AM, emk2203 said:

Only missing thing for me would be this image based on an Ubuntu userland, but it's just habit. Bookworm is not lacking in comparison.

Expand  

 

Definitely pick the PR and build whatever userspace you need, there's not much that is userspace dependent (maybe mesa, but I've not tested desktop usage). I've tested on Bookworm, Jammy and Lunar, all work great.

 

  On 8/19/2023 at 10:38 AM, emk2203 said:

Basically everything from my wish list satisfied

Expand  

 

Also: UMS mode works absolutely great. Use an SD + recovery button to deinfest, after that you can stop u-boot with the serial console and for example run "pci enum; nvme scan; ums 0 nvme 0" and be able to flash to NVMe via UMS (usb otg) without any SD or eMMC.

Also2: you can fix the MAC address stored in the u-boot env in SPI to match the board sticker if you want. Otherwise, MAC address is generated based on CPU serial number, which is stable, but does not match what's on the sticker. Dunno where HK stores the sticker value (maybe some fuse/OTP?)

 

0
usual user

usual user

Posted
Posted
  On 8/19/2023 at 10:44 AM, rpardini said:

UMS mode works absolutely great.

Expand  

UMS has not interested me much so far. However, the mention still inspired me to bring forward my rebase, which was planned after the v2023.10 GA release. Now my serial console boots up with a nice little boot menu: 

  *** U-Boot Boot Menu ***

      Standard Boot
      NVME USB Mass Storage
      eMMC USB Mass Storage
      microSD USB Mass Storage
      usb 0:3
      nvme 0:1
      nvme 0:3
      nvme 0:4
      mmc 1:2
      U-Boot console


  Press UP/DOWN to move, ENTER to select, ESC to quit

Now I don't even need to physically insert the SD card back and forth between the card reader and the M1 when I want to perform a firmware update from my host build system, because the M1 can now act as a card reader itself. And that even for NVME, SATA and eMMC storage. I rarely need this because I usually run updates directly from the M1, but it's still nice to have.
However, this only becomes really interesting when HDMI video is also available and the EXPO menu can also be used.

I guess the day is approaching when I'll finally run this on the serial console: 

run mmc-fw-to-sf

It will transfer my self-contained firmware image build into the SPI flash. I will then lose the possibility to use outdated legacy OS forks and can only use modern operating systems with current bootflows, but if I understand correctly, I have never used anything so unmaintained 😉 But the need to press the RCY button at system startup is starting to get annoying.

0

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept