Re: [PATCH v3 4/4] doc: spacemit: k3: Add Pico-ITX board

[Yixun Lan <dlan@kernel.org>]

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 <dlan@kernel.org>
> > ---
> >  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/20260924063843.8934-1-e@freeshell.de/
> 
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)