[PATCH v4 2/2] doc: spacemit: bananapi_f3: document Banana Pi F3 board

Marcel Ziswiler marcel at ziswiler.com
Wed Dec 11 09:35:12 CET 2024


Hi Huan

On Sun, 2024-12-08 at 14:51 +0800, Huan Zhou wrote:
> On Wed, Dec 04, 2024 at 09:52:09AM +0100, Marcel Ziswiler wrote:
> > Hi Yixun Lan
> > 
> > On Wed, 2024-12-04 at 08:58 +0800, Yixun Lan wrote:
> > > Hi Marcel, Huan
> > > 
> > > On 18:52 Tue 03 Dec     , Marcel Ziswiler wrote:
> > > > Hi Huan Zhou 
> > > > 
> > > > On Fri, 2024-11-29 at 13:37 +0800, Huan Zhou wrote:
> > > > > From: Kongyang Liu <seashell11234455 at gmail.com>
> > > > > 
> > > > > Add document for Banana Pi F3 board which based on SpacemiT's K1 SoC.
> > > > > 
> > > > > Signed-off-by: Kongyang Liu <seashell11234455 at gmail.com>
> > > > > Signed-off-by: Huan Zhou <pericycle.cc at gmail.com>
> > > > > ---
> > > > >  doc/board/index.rst                |  1 +
> > > > >  doc/board/spacemit/bananapi-f3.rst | 86 ++++++++++++++++++++++++++++++++++++++
> > > > >  doc/board/spacemit/index.rst       |  8 ++++
> > > > >  3 files changed, 95 insertions(+)
> > > > > 
> > > > > diff --git a/doc/board/index.rst b/doc/board/index.rst
> > > > > index 417c128c7af6ad2267ef1bc743c7f10ae70b6de7..367da2d62316d4cab25ecc53f852ef742eba13dd 100644
> > > > > --- a/doc/board/index.rst
> > > > > +++ b/doc/board/index.rst
> > > > > @@ -51,6 +51,7 @@ Board-specific doc
> > > > >     sipeed/index
> > > > >     socionext/index
> > > > >     sophgo/index
> > > > > +   spacemit/index
> > > > >     st/index
> > > > >     starfive/index
> > > > >     ste/index
> > > > > diff --git a/doc/board/spacemit/bananapi-f3.rst b/doc/board/spacemit/bananapi-f3.rst
> > > > > new file mode 100644
> > > > > index 0000000000000000000000000000000000000000..1e6d6ef19be7e25684966bd4a727bd21b147330a
> > > > > --- /dev/null
> > > > > +++ b/doc/board/spacemit/bananapi-f3.rst
> > > > > @@ -0,0 +1,86 @@
> > > > > +.. SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +
> > > > > +Banana Pi F3
> > > > 
> > > > Officially they call it Banana Pi BPI-F3.
> > > > 
> > > > > +============
> > > > > +
> > > > > +Building
> > > > > +~~~~~~~~
> > > > > +1. Install the spacemit riscv cross compile toolchain_, or skip it if riscv toolchain is installed.
> > > > 
> > > > I would not use a specific such toolchain but rather a regular RISC-V one e.g.
> > > > 
> > > > https://github.com/riscv-collab/riscv-gnu-toolchain
> > > > 
> > > 
> > > I think any riscv toolchain should work fine here, as I'm using Gentoo specific riscv toolchain..
> > > so consider it's merely an example provided to demonstrate whole process working
> > 
> > Okay.
> > 
> > > > > +
> > > > > +.. _toolchain: https://archive.spacemit.com/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->
> > > > > +
> > > > > +3. Before building U-Boot, OpenSBI should be built first. OpenSBI can be
> > > > > +built for SpacemiT K1 SoC as below:
> > > > > +
> > > > > +.. code-block:: console
> > > > > +
> > > > > +   git clone https://github.com/cyyself/opensbi -b k1-opensbi
> > > > > +   cd opensbi
> > > > > +   make PLATFORM=generic
> > > > 
> > > > What speaks against using regular master opensbi?
> > > > 
> > > no idea if master of opensbi would work here, we can certainly try..
> > 
> > I tried and it seems to work fine, resp. the only difference I could spot is that instead of 'crc32+ OK' it
> > prints some random ASCII characters in the last line before any U-Boot output:
> do you mean the extra '\n'?

No, it literally printed some random chars, but now it seems fine. Probably some unrelated glitch maybe UART
related.

Actually, one out of five to ten boots it prints such random chars: �,��&�%Hj�H�

I tried cyyself opensbi again and after 10 boots it also printed similar random chars. Actually, it even always
prints the exact same ones when it happens. I guess, sooner than later, somebody might need to debug into what
exactly is happening there (;-p).

[   0.579] ## Checking hash(es) for Image opensbi ...�,��&�%Hj�H�

Anyway, regular upstream opensbi seems to work just fine, good.

> > [   0.490] ## Checking hash(es) for Image opensbi ... crc32+ OK
> > 
> > > but I think it's another story, as we are focusing on mainlining uboot
> > 
> > Yes, exactly. I am just curious if it needs combining with some obscure vendor stuff.
> the spl phase need some obscure vendor stuff.

Sure, but I hope we can still upstream it after this first part landed.

> > > FWIK, this branch is generally same version as vendor opensbi, but slightly
> > >  rebase to more recent opensbi version
> > > 
> > > > > +
> > > > > +4. Then build U-Boot as following:
> > > > > +
> > > > > +.. code-block:: console
> > > > > +
> > > > > +   cd <U-Boot-dir>
> > > > > +   make bananapi-f3_defconfig
> > > > > +   make OPENSBI=<OpenSBI-dir>/build/platform/generic/firmware/fw_dynamic.bin
> > > > > +
> > > > > +This will generate u-boot.itb
> > > > > +
> > > > > +Booting
> > > > > +~~~~~~~
> > > > > +Actually, we can replace the uboot part from bianbu linux which is the bsp_ to validate this patch,
> > > > > +use `balena etcher` to burn the bianbu-minimal.img to the sd card, 
> > > > 
> > > > trailing whitespace
> > > > 
> > > > > +and replace the /dev/sdx4 where places the uboot_ with the `u-boot.itb` generated from this patch.
> > > > > +
> > > > > +.. _bsp: https://archive.spacemit.com/image/k1/version/bianbu/v2.0/
> > > > > +.. _uboot: https://bianbu-linux.spacemit.com/en/device/boot#21-firmware-layout
> > > > > +
> > > > > +Sample boot log from Banana Pi F3 board
> > > > 
> > > > BPI-F3
> > > > 
> > > > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > +.. code-block:: none
> > > > > +
> > > > > +   try sd...
> > > > > +   bm:3
> > > > > +   j...
> > > > > +
> > > > > +   U-Boot SPL 2022.10spacemit-dirty (Oct 21 2024 - 09:01:13 +0000)
> > > > > +   [   0.279] DDR type LPDDR4X
> > > > > +   [   0.292] lpddr4_silicon_init consume 13ms
> > > > > +   [   0.293] Change DDR data rate to 2400MT/s
> > > > > +   [   0.430] ## Checking hash(es) for config conf-1 ... OK
> > > > > +   [   0.432] ## Checking hash(es) for Image opensbi ... OK
> > > > > +   [   0.437] ## Checking hash(es) for Image uboot ... OK
> > > > > +   [   0.443] ## Checking hash(es) for Image fdt-1 ... OK
> > > > > +   [   0.488] ## Checking hash(es) for config config_1 ... OK
> > > > > +   [   0.490] ## Checking hash(es) for Image opensbi ... crc32+ OK
> > > > > +
> > > > > +
> > > > > +   U-Boot 2024.10-rc4-00462-g5b138cfcc587-dirty (Nov 28 2024 - 14:56:49 +0800)
> > > > > +
> > > > > +   DRAM:  4 GiB
> > > > 
> > > > I guess it does not yet detect the amount of RAM available.
> > > > 
> > > I would be fine with this, as currently the memory size is hardcoded,
> > > we should work on follow-up patch to auto probe DDR size, and corret it
> > 
> > Yes, I agree.
> > 
> > > > > +   Core:  19 devices, 8 uclasses, devicetree: separate
> > > > > +   Loading Environment from nowhere... OK
> > > > > +   In:    serial at d4017000
> > > > > +   Out:   serial at d4017000
> > > > > +   Err:   serial at d4017000
> > > > > +   Net:   No ethernet found.
> > > > > +   => cpu list
> > > > > +   0: cpu at 0      spacemit,x60
> > > > > +   1: cpu at 1      spacemit,x60
> > > > > +   2: cpu at 2      spacemit,x60
> > > > > +   3: cpu at 3      spacemit,x60
> > > > > +   4: cpu at 4      spacemit,x60
> > > > > +   5: cpu at 5      spacemit,x60
> > > > > +   6: cpu at 6      spacemit,x60
> > > > > +   7: cpu at 7      spacemit,x60
> > > > > +   => test
> > > > > +   => 
> > > > 
> > > > trailing whitespace
> > > > 
> > > > > +
> > > > > diff --git a/doc/board/spacemit/index.rst b/doc/board/spacemit/index.rst
> > > > > new file mode 100644
> > > > > index 0000000000000000000000000000000000000000..3fb7d804ac8fc8dd4c7ee67ffc877f9ad323162d
> > > > > --- /dev/null
> > > > > +++ b/doc/board/spacemit/index.rst
> > > > > @@ -0,0 +1,8 @@
> > > > > +.. SPDX-License-Identifier: GPL-2.0-or-later
> > > > > +
> > > > > +SpacemiT
> > > > > +========
> > > > > +.. toctree::
> > > > > +   :maxdepth: 1
> > > > > +
> > > > > +   bananapi-f3
> > > > > 
> > > > 
> > > > new blank line at EOF
> fixed.

Thanks!

Cheers

Marcel
-- 
Marcel Ziswiler         | mailto:marcel at ziswiler.com
Chäppelirain 4          | https://www.ziswiler.net
CH-6018 Buttisholz      | mobile: +41 (76) 338-0382
Switzerland             | phone: +41 (41) 928-0509


More information about the U-Boot mailing list