[PATCH 2/2] board: rockchip: Add Hardkernel ODROID-M1

[Jonas Karlman]

On 2023-07-06 14:23, Stefan Agner wrote:
> On 2023-07-06 07:08, Jonas Karlman wrote:
>> On 2023-07-06 01:27, Stefan Agner wrote:
>>> On 2023-07-02 22:47, Jonas Karlman wrote:
>>>> Hardkernel ODROID-M1 is a single board computer with a RK3568B2 SoC,
>>>> a slightly modified version of the RK3568 SoC.
>>>>
>>>> Features tested on a ODROID-M1 8GB v1.0 2022-06-13:
>>>> - SD-card boot
>>>> - eMMC boot
>>>> - SPI Flash boot
>>>> - PCIe/NVMe/AHCI
>>>> - SATA port
>>>> - USB host
>>>>
>>>> Device tree is imported from linux v6.4.
>>>>
>>>> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
>>>
>>> Thanks for you patch! I've compared it to my version, and did not notice
>>> any downside/anything missing. If anything, your version is more feature
>>> complete. I've also tested it on an ODORID-M1 with 8GB of memory, it
>>> boots fine from SD card.
>>>
>>> Reviewed-by: Stefan Agner <stefan at agner.ch>
>>> Tested-by: Stefan Agner <stefan at agner.ch>
>>
>> Thanks for review and testing!
>>
>>>
>>> One thing I've noticed is that USB isn't working when I use the stock
>>> SPL (2017.09) running from the SPI RAM and upstream U-Boot (by writing
>>> u-boot.itb to a raw GPT partition named "uboot" to the SD-card). That is
>>> the same in my patchset. If the upstream SPL is used, things work. It
>>> seems that something is not (re)initialized in U-Boot. Not sure if we
>>> typically rely on the state the SPL leaves the HW at, but it would be
>>> nice if we are able to make that combination work. This allows to boot
>>> an upstream U-Boot from an SD-card without having to reflash the onboard
>>> SPI.
>>
>> Trying to use a combo of vendor u-boot SPL and mainline U-Boot proper is
>> not something I have tested or something I would recommend anyone to use.
>> To make use of all features one should press the "SPI recovery switch"
>> during boot or erase/replace U-Boot in SPI flash.
> 
> Yeah I understand that this is the correct way of doing things.
> 
> For Home Assistant OS we try to build an easy to use image which can be
> flashed to the SD card/eMMC and then booted directly. Unfortunately, the
> board doesn't allow to boot straight from eMMC/SD card. I'd prefer if we
> don't have to touch the SPI flash to avoid complexity and allow users to
> easily switch back to whatever the vendor offers.
> 
> In a way, this is similar to how things work on x86-64, to leave the
> BIOS (in this case SPL on SPI flash) up to the hardware vendor.

I will shortly send a v2 that enables a few more Kconfig options and
also did a quick test starting petitboot from mainline U-Boot.

> 
> I understand that this gets into out-of-scope/unsupported territory. I
> posing the question opportunistically: Since you worked with the
> platform quite a bit maybe you have a good guess/idea what could be the
> culprit.
> 
>>
>> Does this USB issue only affect U-Boot proper or also leave USB unusable
>> in linux? Booting OS from USB3 have been a little bit random when I have
>> tested, some of my USB3 devices work if plugged in from cold start
>> others needs to be removed and plugged in again for U-Boot to recognize
>> them. USB2 ports have been much more stable during my testing.
> 
> USB is usable on Linux, so this is just U-Boot. I've tested with a USB
> 2.0 flash drive.

Looks like vendor u-boot assert pipephy and suspend usb phy, see [3].
This could be related to the USB issue using vendor SPL.

[3] https://github.com/hardkernel/u-boot/blob/odroidm1-v2017.09/arch/arm/mach-rockchip/rk3568/rk3568.c#L873-L886

> 
>>
>>>
>>> On a different note: Do you know if PCIe/NVMe support in SPL is
>>> something which is in the cards for this board?
>>
>> As mentioned in the cover-letter this series has some dependencies for
>> all features enabled in defconfig to work, most notably PCIe/NVMe.
>>
>> You can use my rk3568-2023.07-rc6 branch at [1] that have all
>> dependencies included or test with an artifact from my github actions
>> test build workflow at [2].
>>
>> Or do you mean SPL to load FIT (U-Boot proper and TF-A) from NVMe?
> 
> Yes, I meant using the SPL to load the U-Boot FIT image from NVMe.

A "SPL NVMe support" series, see [4], was merged into next and now
master. Could be something to look into for loading FIT from NVMe.

[4] https://patchwork.ozlabs.org/project/uboot/cover/20230603140256.2443518-1-mchitale@ventanamicro.com/

Regards,
Jonas

> 
> --
> Stefan
> 
>>
>> [1] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-2023.07-rc6
>> [2] https://github.com/Kwiboo/u-boot-build/actions/runs/5448465108
>>
>> Regards,
>> Jonas
>>
>>>
>>> --
>>> Stefan
>>>
>>>> ---
>>>>  arch/arm/dts/Makefile                     |   1 +
>>>>  arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi |  46 ++
>>>>  arch/arm/dts/rk3568-odroid-m1.dts         | 744 ++++++++++++++++++++++
>>>>  board/rockchip/evb_rk3568/MAINTAINERS     |   7 +
>>>>  configs/odroid-m1-rk3568_defconfig        | 103 +++
>>>>  doc/board/rockchip/rockchip.rst           |   1 +
>>>>  6 files changed, 902 insertions(+)
>>>>  create mode 100644 arch/arm/dts/rk3568-odroid-m1-u-boot.dtsi
>>>>  create mode 100644 arch/arm/dts/rk3568-odroid-m1.dts
>>>>  create mode 100644 configs/odroid-m1-rk3568_defconfig
>>>> [...]