Hi E Shattow, On 05:43 Sat 03 Oct , E Shattow wrote: > Hi Yixun, > > On 10/2/26 17:34, Yixun Lan wrote: > > Add documentation for how to test the mainline U-Boot on SpacemiT > > K3 Pico-ITX board, currently it still rely on using vendor FSBL.bin > > file to initialize DDR and boot U-Boot proper, and the opensbi > > firmware is built from an on-going mainline branch. > > > > Signed-off-by: Yixun Lan <[email protected]> > > --- > > doc/board/spacemit/index.rst | 1 + > > doc/board/spacemit/spacemit-pico-itx.rst | 204 > > +++++++++++++++++++++++++++++++ > > 2 files changed, 205 insertions(+) > > > > diff --git a/doc/board/spacemit/index.rst b/doc/board/spacemit/index.rst > > index 71854e5735b..51918f0acc7 100644 > > --- a/doc/board/spacemit/index.rst > > +++ b/doc/board/spacemit/index.rst > > @@ -8,4 +8,5 @@ SpacemiT > > bananapi-f3 > > k1-mmc > > k1-spl > > + spacemit-pico-itx > > > > diff --git a/doc/board/spacemit/spacemit-pico-itx.rst > > b/doc/board/spacemit/spacemit-pico-itx.rst > > new file mode 100644 > > index 00000000000..dd29e3c31c8 > > --- /dev/null > > +++ b/doc/board/spacemit/spacemit-pico-itx.rst > > @@ -0,0 +1,204 @@ > > +.. SPDX-License-Identifier: GPL-2.0-or-later > > + > > +SpacemiT K3 Pico-ITX > > +==================== > > + > > +Building > > +~~~~~~~~ > > +1. Install the SpacemiT riscv cross compile toolchain_, or skip it if > > riscv toolchain is installed. > > + > > +.. _toolchain: https://archive.spacemit.com/toolchain/ > > + > > Avoid the advertisement for any unnecessary vendor-specific information. > Ok > The packaged toolchain from any generic Linux distro is fine enough to > build with as "1. Add a RISC-V toolchain to your PATH." and no other > explanation is required. > > I have tested with Debian forky/testing for example, it is fine. Code > size differences between output of GCC major versions may be detailed in > a future update if it becomes important. > Ok, I generally agree, any riscv toolchain should works fine here, no specific requirement, this is just a copy-and-poaste from K1 doc, and should consider as one of many ways to setup compiling toolchain
> > +2. Setup cross compilation environment variable: > > + > > +.. code-block:: console > > + > > + export CROSS_COMPILE=<riscv64 toolchain prefix, e.g > > /opt/spacemit/bin/riscv64-unknown-linux-gnu-> > > + > > Likewise, it is enough to have "2. Set a cross-compilation environment > variable if needed: export CROSS_COMPILE=<riscv64 toolchain prefix>" > > There is much documentation about compiling U-Boot at > doc/build/index.rst and so do not name a specific vendor toolchain path > name here. > Ok > > +3. Before building U-Boot, OpenSBI should be built first. OpenSBI can be > > +built for SpacemiT K1 SoC as below: > > built for SpacemiT K3 SoC ? > > However it is clearer to re-phrase that as a statement of requirements. > "3. U-Boot for SpacemiT K3 SoC requires OpenSBI in-development generic > platform object fw_dynamic.bin to be included in the Flattened Image > Tree blob. OpenSBI may be first built as below: ..." > > Please if it will help you then do copy any build examples adapted from > my own writing in doc/board/starfive/jh7110_common.rst which contains a > small error in build command details corrected at > https://lore.kernel.org/u-boot/[email protected]/ > I will try to do some ajdustment to make it more generic.. > Additional phrasing may be as "Review the OpenSBI developer mailing list > archives for patches to apply in support of SpacemiT K3 Pico-ITX". Let > this be generic enough that we are not dead-linking to something 10 > years later when a user is viewing this old document from the future. > But, well, either way isn't perfect, I didn't expect this is an unchanged doc which will last 10years long, instead it should be kept improved. > > + > > +.. code-block:: console > > + > > + git clone https://github.com/spacemit-com/opensbi-upstream opensbi > > + cd opensbi > > + make PLATFORM=generic > > Please refer to upstream directly. I appreciate to make it convenient > with patches curated on a fork repository but this is not durable for > documentation purpose, is this going to exist in 2 years? 10 years? 20 Shouldn't be problem for 2years, while not sure for more than 10years, but I don't think this is really a problem, see below > years?. Mailing list archives are durable and if we depend on OpenSBI > then I expect at least upstream OpenSBI git repository to be durable, too. > I'd hope patches for opensbi will be finally accepted into mainline, then update the doc here accordingly, providing a fork repo is just a conveniet way for people to download, I could adjust to use mainline opensbi repo + applying extra patches, but to be honest, I don't see that's much different.. so, I'd rather not change it now, or let's say, do update the doc when above fork repo is really broken/or opensbi patches accepted. > > + > > +4. Then build U-Boot as following: > > + > > +.. code-block:: console > > + > > + cd <U-Boot-dir> > > + make spacemit_k3_defconfig > > + make > > OPENSBI=<OpenSBI-dir>/build/platform/generic/firmware/fw_dynamic.bin > > + > > +This will generate u-boot.itb > > + > > +Testing > > +~~~~~~~ > > +Currently, in this stage, the U-Boot SPL isn't ready, and has no ddr > > initialization code > > Instead, as "Currently there is no U-Boot SPL build target. It is > required to use 'FSBL.bin' vendor board support package SPL for DDR > initialization and testing u-boot.itb" > Ok > May SPI NOR be erased empty? what exactly must be present in SPI NOR for > successful testing? > Doesn't matter if there is fw present in SPI NOR, for my testing, my board do has SPI nor firmware exist > > +Thus please test with fasboot command via USB download. > > fastboot > thanks > > + > > +First, retrieve Bianbu Linux image from archive_ and extract the FSBL.bin > > firmware. > > We should build any out-of-tree dependencies (FSBL.bin) from from source > if it is possible. This is a cheap operation to 'git remote add -f > spacemit-com https://...spacemit-com/uboot-2022.10' on an existing > u-boot git repo. > > Assume SPI NOR content is erased. Is there something vendor-specific you > need that is not available by compiling spacemit-com k3-br-v1.0.y branch? > I don't want to put too much effort to document about building vendor-specific firmware.. currently, providing one way to test is enough, since there is a work-on-porgress project, and we target having a mainline SPL support in tree finally -- Yixun Lan (dlan)
