All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon van der Veldt <simon.vanderveldt@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] Handling of rpi-firmware blobs broken for certain cases
Date: Sat, 23 Feb 2019 19:59:41 +0100	[thread overview]
Message-ID: <CAKDzfnqJfpgU3S1ZVSBcZFG87vZk=+EBykqUJUG4LMajCNSmoQ@mail.gmail.com> (raw)

Good evening everyone,

I just ran into an issue where the .elf and .dat files copied into
/boot by buildroot when building for a Raspberry Pi are incorrect.

Overview of the problem using current master (or 2018.11.2 which is
the same apart from the version):
- Put gpu_mem=16 in config.txt (the config file for the videocore of a
raspberry)
- When using <32M GPU memory the videocore needs the so called cut
down versions ("start_cd.elf" and "fixup_cd.dat") of the binary blobs
to boot. By emperical testing it seems@least "start_cd.elf" needs
to be present under that exact name to be able to boot the rpi
- Buildroot has some custom handling for these files
(https://github.com/buildroot/buildroot/blob/master/package/rpi-firmware/rpi-firmware.mk#L40)
and copies the correctly named "source" files from the rpi-firmware
package to the incorrect "start.elf" and "fixup.dat" names
- When trying to boot the RPi won't book (note I've only tested this
with a CM3, not sure if behavior is different for other RPis)

Whilst I'm sure this is solvable I'm wondering why this level of
micro-management of these blobs is necessary? The .elf files are
12.2MB and the .dat files are 28.6KB for all of them.
These files only get copied into the image directory from where one
can then choose which files to include in the actual image using the
genimage config. I don't think copying +-12MB should be a problem.

Also users have the possibility of changing the config.txt file
(assume a writeable boot filesystem of course) which means they might
need different versions of these start and fixup files and by
extension multiple/all different versions of these blobs need to be
present.

With all of this said my suggestion would be to simplify how this is
handled in buildroot by just copying all *.elf and *.dat files in the
boot directory of rpi-firmware to the image directory.
Then the person building the image can choose which of these (specific
ones or all of them) to include using the genimage config.

An example/suggestion for a fix can be found here
https://github.com/simonvanderveldt/buildroot/commit/16880713c2c03ad50e8cfe7bf05331718d52742e
I've tested this and it works like a charm :)

Kind regards,
Simon

             reply	other threads:[~2019-02-23 18:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-23 18:59 Simon van der Veldt [this message]
2019-02-23 21:53 ` [Buildroot] Handling of rpi-firmware blobs broken for certain cases Peter Seiderer
2019-02-24 10:22   ` Simon van der Veldt

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='CAKDzfnqJfpgU3S1ZVSBcZFG87vZk=+EBykqUJUG4LMajCNSmoQ@mail.gmail.com' \
    --to=simon.vanderveldt@gmail.com \
    --cc=buildroot@busybox.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.