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 <[email protected]> >>> >>> 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 <[email protected]> >>> Tested-by: Stefan Agner <[email protected]> >> >> 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/[email protected]/ 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 >>>> [...]
