Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Zoltán Kócsi" <zoltan@bendor.com.au>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] User mailing list?
Date: Sat, 3 Aug 2024 11:44:15 +0200	[thread overview]
Message-ID: <20240803114415.1f26c88e@windsurf> (raw)
In-Reply-To: <20240803125013.5b7b907c@mazsola>

Hello,

On Sat, 3 Aug 2024 12:50:13 +1000
Zoltán Kócsi <zoltan@bendor.com.au> wrote:

> New board, with a Xilinx Zynq7 SoC (actually, SoM w/ DRAM). It's just
> an ARM Cortex-A9 with loads of peripherals and an FPGA. I can boot the
> board (with bare metal code), can load anything to RAM, configure all
> devices and all. But I want Linux on it.
> 
> Not the Xilinx one, but the mainline version (the Zynq7 is old enough
> so that all relevant Xilinx drivers are already on the mainline), with
> the RT patches applied. Don't really want uboot or anything fancy, I can
> load a kernel image, device tree and rootfs into RAM myself and start
> the kernel. So all I need is the kernel, the DTB and the rootfs.

So far, sounds good.

> Buildroot seems to be a perfect match for this.

Absolutely :-)

> Alas, from here, user stupidity and ignorance to be expected...
> 
> First step, let's make an SDK. Load a defconfig with a board using the

No, not an SDK. That's a first mistake on your side, running "make sdk"
is not what you want to do. You need to just run "make".

"make sdk" is to build a SDK, i.e Software Development Kit. In the
context of Buildroot what this does is generate a tarball that contains
the cross-compiler + sysroot, so that application developers can build
applications/libraries using the Buildroot cross-compiler, but outside
of Buildroot.

In practice, doing "make sdk" builds everything, but I believe it is
useful to clarify that building a SDK is not what you want to do here.

> same chip, then change the Buildroot config to use a mainline kernel +
> RT patch, disable everything that the manual says: busybox, init
> system, /bin/sh, and tar-ing the root file system.

Why do you disable everything? If you don't have busybox, if you don't
have an init system, how do you expect user-space to start up?

> Type make sdk.

No, just "make" in your case.

> It chugs along, then the kernel compilation fails with a prototype
> mismatch in the noveau video driver. Why would it need an nVidia driver
> for a headless board is a mystery, but ok. Let's configure the kernel.

Where did you specify that you are using a headless platform? You
didn't specify which defconfig you started from, so I can't really
comment, but maybe Buildroot defconfigs use Linux kernel defconfigs,
and kernel defconfigs are very often quite featureful, and include a
lot of drivers. This is not Buildroot's fault: it's up to you to pick
the right kernel configuration, and tune it to your needs.

> Turn off everything the board doesn't have and/or not needed.
> 
> make sdk again. Cool! The kernel compiles. Then Buildroot starts to
> build rootfs.ext2. First, a warning about 64-bit filesystem support not
> being enabled, but it builds it anyway.

Which warning?

> Writing superblocks and filesystem accounting information: done.
> Hurray!
> 
> Then:
> 
> >>>   Executing post-image script board/zynq/post-image.sh  
> INFO: cmd: "mkdir -p
> "/usr/local/work/Linux/test/buildroot-2024.05/output/build/genimage.tmp"" (stderr):
> INFO: cmd: "rm -rf
> "/usr/local/work/Linux/test/buildroot-2024.05/output/build/genimage.tmp"/*" (stderr):
> INFO: cmd: "mkdir -p
> "/usr/local/work/Linux/test/buildroot-2024.05/output/build/genimage.tmp"" (stderr):
> INFO: cmd: "cp -a "/tmp/tmp.piKMAgmzhv"
> "/usr/local/work/Linux/test/buildroot-2024.05/output/build/genimage.tmp/root"" (stderr):
> ERROR: file(boot.bin):
> stat(/usr/local/work/Linux/test/buildroot-2024.05/output/images/boot.bin)
> failed: No such file or directory
> ERROR: vfat(boot.vfat): could not setup boot.bin
> make: *** [Makefile:826: target-post-image] Error 1

Well, you've started from a defconfig, but then you've disabled random
stuff without really understanding what you were doing, what did you
expect?

Here what happens is that at the end of the build, Buildroot uses the
genimage utility to generate the final SD card image. The layout of the
SD card image is defined by a genimage configuration file, and this SD
card image layout expects to have a bootloader binary generated.. but I
presume you disabled building the bootloader in your Buildroot
configuration.

> I guess what happened was that Buildroot wanted to invoke the Xilinx
> tool 'genimage' to create boot.bin, which is the FSBL for the Zynq7
> chips.

No, genimage does not generate boot.bin, it consumes it. boot.bin
should have been generated by the U-Boot build... which you have
presumably disabled.

> Boot.bin is built from bare-metal code source (probably from Xilinx) and
> the resulting elf file is massaged to boot.bin by the Xilinx genimage
> tool.

No. genimage is not a Xilinx tool.

> But I don't need boot.bin (I have my own), just the kernel, rootfs and the dtb.

Well, then adjust the genimage configuration file.

However, to be honest, it is not very logical to not need a bootloader.
In the vast majority of embedded Linux projects, you will definitely
want to have a bootloader.

Hope this helps!

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

      reply	other threads:[~2024-08-03  9:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-02 20:25 [Buildroot] User mailing list? Zoltán Kócsi
2024-08-02 21:57 ` Thomas Petazzoni via buildroot
2024-08-03  2:50   ` Zoltán Kócsi
2024-08-03  9:44     ` Thomas Petazzoni via buildroot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240803114415.1f26c88e@windsurf \
    --to=buildroot@buildroot.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=zoltan@bendor.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox