All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Harvey <tharvey@gateworks.com>
To: Simon Glass <sjg@chromium.org>
Cc: u-boot <u-boot@lists.denx.de>
Subject: Re: using binman fails boot
Date: Fri, 23 Jul 2021 14:06:24 -0700	[thread overview]
Message-ID: <CAJ+vNU1g-U=62+U3U1C5SU0tWt-1GnsmzgzEN7B1E5ObmdJ6gA@mail.gmail.com> (raw)
In-Reply-To: <CAPnjgZ2v2P+_yb7Da+izkSUktvSAxcLbhUrEm9ShmgnOQHvbKg@mail.gmail.com>

On Thu, Jul 22, 2021 at 8:07 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tim,
>
> On Mon, 19 Jul 2021 at 17:23, Tim Harvey <tharvey@gateworks.com> wrote:
> >
> > On Sat, Jul 17, 2021 at 7:22 PM Simon Glass <sjg@chromium.org> wrote:
> > >
>
> [..]
>
> > > > But isn't blob-ext@4 a correct name? I can't use 'blob-ext-4' as
> > > > that's an unknown entry type.
> > >
> > > Well you can use any name and specify the type:
> > >
> > > my-name {
> > >    type = "blob-ext";
> > > };
> > >
> >
> > Ok - I understand.
> >
> > > >
> > > > >
> > > > > If you can push your tree somewhere (with this problem) I'll see if I
> > > > > can figure out why.
> > > > >
> > > >
> > > > Sure, I pushed it to
> > > > https://github.com/Gateworks/uboot-venice/tree/WIP-venice-binman
> > > > make imx8mm_venice_defconfig
> > > > make
> > >
> > > OK
> > >
> > > >
> > > > > >
> > > > > > BINMAN_VERBOSE=4 indeed prints out a tone of stuff but I'm not seeing
> > > > > > anything for 'blob' below that would seem to indicate one node name vs
> > > > > > another:
> > > > >
> > > > > Oops you need BINMAN_VERBOSE=5 - see elf.py LookupAndWriteSymbols()
> > > > > which has tout.Debug() which is level 5.
> > > > >
> > > >
> > > > LookupAndWriteSymbols ends up doing nothing because
> > > > syms.get('__image_copy_start') returns None.
> > >
> > > Well that is likely the problem.
>
> I sent a patch to make binman report this as an error.
>
> I pushed the resulting tree to:
>
> https://github.com/sjg20/u-boot/tree/try-tim
>
> Now the error is:
>
> binman: Section '/binman/u-boot-spl-ddr': Symbol
> '_binman_u_boot_any_prop_image_pos'
>
>    in entry '/binman/u-boot-spl-ddr/u-boot-spl/u-boot-spl-nodtb':
> Entry 'u-boot-any' not found in list
> (u-boot-spl-nodtb,u-boot-spl-dtb,u-boot-spl,blob-ext@1,blob-ext@2,blob-ext@3,blob-ext@4,main-section)
>
> The problem seems to be that you are asking binman to generate three
> independent images. U-Boot is in a FIT which is not in the same image
> as SPL. So it is not possible to locate the flash offset of U-Boot
> (with in the FIT).
>
> Can you give me a bit more info about your intent here? Is it to load
> U-Boot from the FIT? I so, I suppose it is possible to make binman
> access an independent image, if it is told where it starts.
>
> But why is everything not in one image?
>

Simon,

I would rather have 1 image. I was going off of the imx8mm_evk switch
to binman which creates the separate images.

The whole point of what I'm investigating here has to do with the SPL.
OCRAM is at a premium and the current way the IMX8M is handling DDR
firmware is to tack it on after the code in the SPL image and it gets
padded to make it easy to locate which is a huge waste of space. I
figured we can use binman to locate the blobs without the padding.

So, if you take 'just' the spl image here:
        spl: u-boot-spl-ddr {
                filename = "u-boot-spl-ddr.bin";
                pad-byte = <0xff>;
                align-size = <4>;
                align = <4>;

                u-boot-spl {
                        align-end = <4>;
                };

                blob_1: blob-ext@1 {
                        filename = "lpddr4_pmu_train_1d_imem.bin";
                        size = <0x8000>;
                };

                blob_2: blob-ext@2 {
                        filename = "lpddr4_pmu_train_1d_dmem.bin";
                        size = <0x4000>;
                };

                blob_3: blob-ext@3 {
                        filename = "lpddr4_pmu_train_2d_imem.bin";
                        size = <0x8000>;
                };

                blob_4: blob-ext@4 {
                        filename = "lpddr4_pmu_train_2d_dmem.bin";
                        size = <0x4000>;
                };
        };

My intention is to remove the size arguments above which are currently
forcing wasted padding and locate the blobs at runtime with binman.

Based on your other patch it it would seem I'm missing something from
my lds to add __image_copy_start yet in
arch/arm/cpu/armv8/u-boot-spl.lds I see:
        .text : {
                . = ALIGN(8);
                *(.__image_copy_start)
                CPUDIR/start.o (.text*)
                *(.text*)
        } >.sram

My understanding of linker files is pretty slim so perhaps there's
something missing above.

Regards,

Tim

  reply	other threads:[~2021-07-23 21:06 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15 22:57 using binman fails boot Tim Harvey
2021-07-16  4:30 ` Simon Glass
2021-07-16 21:43   ` Tim Harvey
2021-07-16 22:11     ` Simon Glass
2021-07-16 23:15       ` Tim Harvey
2021-07-18  2:22         ` Simon Glass
2021-07-19 23:23           ` Tim Harvey
2021-07-23  3:07             ` Simon Glass
2021-07-23 21:06               ` Tim Harvey [this message]
2021-07-23 21:41                 ` Simon Glass
2021-07-23 22:51                   ` Tim Harvey
2021-07-24 22:01                     ` Simon Glass
2021-07-26 18:42                       ` Tim Harvey
2021-07-28  2:46                         ` Simon Glass

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='CAJ+vNU1g-U=62+U3U1C5SU0tWt-1GnsmzgzEN7B1E5ObmdJ6gA@mail.gmail.com' \
    --to=tharvey@gateworks.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /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.