mbox series

[v3,00/19] vbe: Series part E

Message ID 20241207172412.1124558-1-sjg@chromium.org
Headers show
Series vbe: Series part E | expand

Message

Simon Glass Dec. 7, 2024, 5:23 p.m. UTC 
This includes various patches towards implementing the VBE abrec
bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
fatures are available in VPL.

Changes in v3:
- Add new patch to avoid size growth in spl_mmc_find_device() debug
- Use strlcpy() instead of strncpy()
- Rebase to master

Changes in v2:
- Add field names into the message
- Fix 'depends on SPL' to depend on TPL
- Depend on TPL/VPL as well
- Drop patch 'serial: ns16550: Allow clocks to be missing'

Simon Glass (19):
  spl: mmc: Avoid size growth in spl_mmc_find_device() debug
  image: Add a prototype for fit_image_get_phase()
  boot: Allow FIT to fall back from best-match option
  bootstd: Avoid sprintf() in SPL when creating bootdevs
  boot: Respect the load_op in fit_image_load()
  malloc: Show amount of used space when memory runs out
  malloc: Provide a simple malloc for VPL
  Support setting a maximum size for the VPL image
  spl: Report a loader failure
  spl: Allow serial to be disabled in any XPL phase
  spl: Support a relocated stack in any XPL phase
  spl: Drop use of uintptr_t
  spl: Drop a duplicate variable in boot_from_devices()
  spl: Add some more debugging to load_simple_fit()
  spl: lib: Allow for decompression in any SPL build
  boot: Allow use of FIT in TPL and VPL
  lib: Allow crc8 in TPL and VPL
  boot: Imply CRC8 with VBE
  hash: Plumb crc8 into the hash functions

 boot/Kconfig                  | 71 ++++++++++++++++++++++++++++++++++-
 boot/bootdev-uclass.c         | 10 ++++-
 boot/image-fit.c              | 29 ++++++++------
 common/hash.c                 |  8 ++++
 common/malloc_simple.c        |  3 +-
 common/spl/Kconfig.vpl        | 17 +++++++++
 common/spl/spl.c              | 15 +++++---
 common/spl/spl_atf.c          | 36 +++++++++---------
 common/spl/spl_fit.c          | 12 +++++-
 common/spl/spl_legacy.c       |  8 ++--
 common/spl/spl_mmc.c          |  6 ++-
 configs/sandbox_vpl_defconfig |  2 +
 include/image.h               | 16 +++++++-
 include/spl.h                 | 28 +++++++-------
 include/u-boot/crc.h          |  3 ++
 lib/Kconfig                   | 53 ++++++++++++++++++++++++++
 lib/Makefile                  | 12 +++---
 lib/crc8.c                    |  6 +++
 18 files changed, 267 insertions(+), 68 deletions(-)

Comments

Tom Rini Dec. 13, 2024, 1:11 a.m. UTC | #1 
On Sat, 07 Dec 2024 10:23:53 -0700, Simon Glass wrote:

> This includes various patches towards implementing the VBE abrec
> bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
> fatures are available in VPL.
> 
> Changes in v3:
> - Add new patch to avoid size growth in spl_mmc_find_device() debug
> - Use strlcpy() instead of strncpy()
> - Rebase to master
> 
> [...]

Applied to u-boot/next, thanks!
Tom Rini Dec. 13, 2024, 3:09 a.m. UTC | #2 
On Thu, Dec 12, 2024 at 07:11:55PM -0600, Tom Rini wrote:
> On Sat, 07 Dec 2024 10:23:53 -0700, Simon Glass wrote:
> 
> > This includes various patches towards implementing the VBE abrec
> > bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
> > fatures are available in VPL.
> > 
> > Changes in v3:
> > - Add new patch to avoid size growth in spl_mmc_find_device() debug
> > - Use strlcpy() instead of strncpy()
> > - Rebase to master
> > 
> > [...]
> 
> Applied to u-boot/next, thanks!

And, ugh, I missed that CI was failing for real. This causes
rcar3_salvator-x to fail to link due to size growth, so I'm reverting
this for now, sorry. I thought the CI failure I saw was due to something
else at the time.
Simon Glass Dec. 13, 2024, 3:24 a.m. UTC | #3 
Hi Tom,

On Thu, 12 Dec 2024 at 20:09, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 12, 2024 at 07:11:55PM -0600, Tom Rini wrote:
> > On Sat, 07 Dec 2024 10:23:53 -0700, Simon Glass wrote:
> >
> > > This includes various patches towards implementing the VBE abrec
> > > bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
> > > fatures are available in VPL.
> > >
> > > Changes in v3:
> > > - Add new patch to avoid size growth in spl_mmc_find_device() debug
> > > - Use strlcpy() instead of strncpy()
> > > - Rebase to master
> > >
> > > [...]
> >
> > Applied to u-boot/next, thanks!
>
> And, ugh, I missed that CI was failing for real. This causes
> rcar3_salvator-x to fail to link due to size growth, so I'm reverting
> this for now, sorry. I thought the CI failure I saw was due to something
> else at the time.

Hmm, sorry about that...it passed CI when I sent it!

The growth is quite alarming and I am not sure how to make sense of
it. Here is the last patch:

21: hash: Plumb crc8 into the hash functions
   aarch64:  +   rcar3_salvator-x
   aarch64: (for 1/1 boards) all +2109.0 bss -48.0 data +56.0 rodata
+5.0 text +2096.0
            rcar3_salvator-x: all +2109 bss -48 data +56 rodata +5 text +2096
               u-boot: add: 1/0, grow: 1/0 bytes: 136/0 (136)
                 function                                   old     new   delta
                 crc8_wd_buf                                  -      80     +80
                 hash_algo                                  280     336     +56

So perhaps apply all but the final patch? Then I can sort out things from there.

Regards,
Simon
Tom Rini Dec. 13, 2024, 2:05 p.m. UTC | #4 
On Thu, Dec 12, 2024 at 08:24:06PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 12 Dec 2024 at 20:09, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 12, 2024 at 07:11:55PM -0600, Tom Rini wrote:
> > > On Sat, 07 Dec 2024 10:23:53 -0700, Simon Glass wrote:
> > >
> > > > This includes various patches towards implementing the VBE abrec
> > > > bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
> > > > fatures are available in VPL.
> > > >
> > > > Changes in v3:
> > > > - Add new patch to avoid size growth in spl_mmc_find_device() debug
> > > > - Use strlcpy() instead of strncpy()
> > > > - Rebase to master
> > > >
> > > > [...]
> > >
> > > Applied to u-boot/next, thanks!
> >
> > And, ugh, I missed that CI was failing for real. This causes
> > rcar3_salvator-x to fail to link due to size growth, so I'm reverting
> > this for now, sorry. I thought the CI failure I saw was due to something
> > else at the time.
> 
> Hmm, sorry about that...it passed CI when I sent it!
> 
> The growth is quite alarming and I am not sure how to make sense of
> it. Here is the last patch:
> 
> 21: hash: Plumb crc8 into the hash functions
>    aarch64:  +   rcar3_salvator-x
>    aarch64: (for 1/1 boards) all +2109.0 bss -48.0 data +56.0 rodata
> +5.0 text +2096.0
>             rcar3_salvator-x: all +2109 bss -48 data +56 rodata +5 text +2096
>                u-boot: add: 1/0, grow: 1/0 bytes: 136/0 (136)
>                  function                                   old     new   delta
>                  crc8_wd_buf                                  -      80     +80
>                  hash_algo                                  280     336     +56
> 
> So perhaps apply all but the final patch? Then I can sort out things from there.

I tried that before going off for the night without remembering that the
problem is:
+(rcar3_salvator-x) u-boot.img exceeds file size limit:
+(rcar3_salvator-x)   limit:  0x100000 bytes
+(rcar3_salvator-x)   actual: 0x100392 bytes
+(rcar3_salvator-x)   excess: 0x392 bytes

So no, just the last patch alone is not enough. You need to sync up with
Marek about what can/can't be disabled on the platform (or more likely
really, r-car gen3 platforms overall0.
Simon Glass Dec. 13, 2024, 2:32 p.m. UTC | #5 
Hi Tom,

On Fri, 13 Dec 2024 at 07:05, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 12, 2024 at 08:24:06PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 12 Dec 2024 at 20:09, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 12, 2024 at 07:11:55PM -0600, Tom Rini wrote:
> > > > On Sat, 07 Dec 2024 10:23:53 -0700, Simon Glass wrote:
> > > >
> > > > > This includes various patches towards implementing the VBE abrec
> > > > > bootmeth in U-Boot. It mostly focuses on SPL tweaks and adjusting what
> > > > > fatures are available in VPL.
> > > > >
> > > > > Changes in v3:
> > > > > - Add new patch to avoid size growth in spl_mmc_find_device() debug
> > > > > - Use strlcpy() instead of strncpy()
> > > > > - Rebase to master
> > > > >
> > > > > [...]
> > > >
> > > > Applied to u-boot/next, thanks!
> > >
> > > And, ugh, I missed that CI was failing for real. This causes
> > > rcar3_salvator-x to fail to link due to size growth, so I'm reverting
> > > this for now, sorry. I thought the CI failure I saw was due to something
> > > else at the time.
> >
> > Hmm, sorry about that...it passed CI when I sent it!
> >
> > The growth is quite alarming and I am not sure how to make sense of
> > it. Here is the last patch:
> >
> > 21: hash: Plumb crc8 into the hash functions
> >    aarch64:  +   rcar3_salvator-x
> >    aarch64: (for 1/1 boards) all +2109.0 bss -48.0 data +56.0 rodata
> > +5.0 text +2096.0
> >             rcar3_salvator-x: all +2109 bss -48 data +56 rodata +5 text +2096
> >                u-boot: add: 1/0, grow: 1/0 bytes: 136/0 (136)
> >                  function                                   old     new   delta
> >                  crc8_wd_buf                                  -      80     +80
> >                  hash_algo                                  280     336     +56
> >
> > So perhaps apply all but the final patch? Then I can sort out things from there.
>
> I tried that before going off for the night without remembering that the
> problem is:
> +(rcar3_salvator-x) u-boot.img exceeds file size limit:
> +(rcar3_salvator-x)   limit:  0x100000 bytes
> +(rcar3_salvator-x)   actual: 0x100392 bytes
> +(rcar3_salvator-x)   excess: 0x392 bytes
>
> So no, just the last patch alone is not enough. You need to sync up with
> Marek about what can/can't be disabled on the platform (or more likely
> really, r-car gen3 platforms overall0.

I don't really like the size growth and I think it might be better to
put my hash addition behind a Kconfig. While these boards are
inconvenient, they do keep us honest, on code size.

Regards,
Simon