Add support for Odroid M1S Board

[darkxst]

Hardkernel have recently released the Odroid M1S which is a slimmed down version of the original Odroid M1.

Features:

• Rockchip RK3566
• 4 or 8GB LPDDR4 RAM
• 64GB eMMC (soldered)
• Pcie 2.1 NVMe M2 slot
• new 14pin GPIO header that supports a variety of addon boards (most require DT overlays though)

This needs to be added as a new board since it uses a different TPL blob for DDR initialiasation.

There is no upstream support for this board just yet, however that is in progress. For now I am using the following:
Uboot using generic-rk3568 target
Linux device tree synced from the unofficial hardkernel 6.1 linux
https://github.com/tobetter/linux/tree/odroid-6.1.y

Installation to eMMC can be done directly with Hardkernel's USB UMS tool
https://wiki.odroid.com/odroid-m1s/getting_started/os_installation_guide?redirect=1#install_over_usb_from_pc

[sairon]

Although this PR is still a draft, could you please put it on hold? We plan to merge #3063 this week and it will need to be updated afterwards, so I wanted to give you a heads-up about that. I remember you wrote you developed the support also for 6.6 kernel, so I hope this is not a big complication for you.

Maybe @agners has some more comments regarding this PR as well.

But anyway, thanks for your work!

[darkxst]

I remember you wrote you developed the support also for 6.6 kernel, so I hope this is not a big complication for you.

Yes, I have a 6.6 branch as well, so no issues there. I will rebase onto that once 6.6 is merged.

[darkxst]

First 2 patches are actually from PR #3165, but apart from that this should be ready for review.

Changes from first round:

• Rebased onto 6.6 12.0dev branch
• Switch to full uboot config, as there were issues with ethernet and nvme after booting kernel when using generic config. This also will read the proper MAC address from /dev/mmcblk0boot0. (Based on patch from uboot lists, but it wont be merged until device tree is in linux!)
• Activate UMS gadget on OTG port,allowing to mount internal eMMC on PC, making it easy for user to reinstall etc if required. The hardkernel UMS tool wont boot once mainline uboot is installed. I've also included a serial console on the OTG at the same time.

[sairon]

Looks good from my perspective 👍 There are just some nits below.

However I don't have M1S yet to try it out - but it should be somewhere on the way, same for @agners.

If there's no concern on Stefan's side, we could merge it before we start 12.0 beta, hopefully we should get M1S and add it to our board farm for testing before the public release.

[agners]

Thanks for your work, this looks great!

• Activate UMS gadget on OTG port,allowing to mount internal eMMC on PC, making it easy for user to reinstall etc if required. The hardkernel UMS tool wont boot once mainline uboot is installed. I've also included a serial console on the OTG at the same time.

So you are exporting /dev/mmcblk0 as a block device, but that is also used for the data partition etc. I don't think it is safe to mount partitions/write to the block device when there are read-write partitions on that device 😰

That said I like adding UMS gadget support, that allows for some neat user experience. We could use that for other boards as well. However, the concurrent access for the block device is a problem 😢

You are currently using the kernel modules directly, from what I know this is the legacy way of enabling USB gadget modules (e.g. the drivers are in a legacy directory https://github.com/torvalds/linux/blob/v6.1/drivers/usb/gadget/legacy/Kconfig). The modern way is to use configfs to configure gadget devices. There are libraries with tools which allow to describe the gadget devices, see https://github.com/linux-usb-gadgets/libusbgx/blob/master/doc/gadget_schemes.txt.

Since we just step into this, I think it would be better if we go the modern approach 🤔

[darkxst]

So you are exporting /dev/mmcblk0 as a block device, but that is also used for the data partition etc. I don't think it is safe to mount partitions/write to the block device when there are read-write partitions on that device 😰

Yes, that could be an issue, I was thinking it would provide an easy way for user to reinstall system etc, but even that wont necessarily be safe. Not sure if there is a way around this?

You are currently using the kernel modules directly, from what I know this is the legacy way of enabling USB gadget modules

Yes I am aware that modules are considered legacy, however the configfs way is 100x more complicated than the legacy modules when used directly. I will however have alook and see if some tools help with that!

[agners]

Yes, that could be an issue, I was thinking it would provide an easy way for user to reinstall system etc, but even that wont necessarily be safe. Not sure if there is a way around this?

We could introduce a separate systemd target which stops before mounting the data partition, but instead enables USB gadget mode (e.g. haos-recovery.target). Altough, I guess it would still not be safe as the OS might read things from the squashfs still 😢

I guess the only way to do this safe would be a rootfs/squashfs we load into RAM at boot. Or pivot into a temporary root. That is what OpenWrt does IIRC.

In any case, I'd suggest to split out/revert the USB gadget stuff from this PR so we can get ODROID-M1S going.

Yes I am aware that modules are considered legacy, however the configfs way is 100x more complicated than the legacy modules when used directly. I will however have alook and see if some tools help with that!

Yeah tools make it easier, but it is still more complicated. But then, also more flexible 😅

[sairon]

I agree with Stefan, let's separate the basic board support from the USB gadget stuff, as it may get fairly complex. Then, and after fixing merge conflicts caused by #3165 merge, we can move on with merging the M1S support 🎉

[darkxst]

We could introduce a separate systemd target which stops before mounting the data partition, but instead enables USB gadget mode (e.g. haos-recovery.target).

I guess the only way to do this safe would be a rootfs/squashfs we load into RAM at boot. Or pivot into a temporary root. That is what OpenWrt does IIRC.

Yeh either of those could work.

I have rebased on dev and split out the UMS, will create a separate PR for it.

[sairon]

Looks good, thank you for your work 👍