[U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory...

[Moses Christopher]

On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt, <
simon.k.r.goldschmidt at gmail.com> wrote:

> On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
> <moseschristopherb at gmail.com> wrote:
> >
> >
> >
> > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, <
> simon.k.r.goldschmidt at gmail.com> wrote:
> >>
> >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
> >> <moseschristopherb at gmail.com> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> >
> >> > Thanks for the prompt reply.
> >> >
> >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, <
> simon.k.r.goldschmidt at gmail.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher
> >> > <moseschristopherb at gmail.com> wrote:
> >> > > Hello together,
> >> > >
> >> > > I was trying to build u-boot and spl for the arm target and tried
> to boot via usb-ethernet.
> >> > > I found an issue with one of the commit made in the early 2019,
> >> > > http://patchwork.ozlabs.org/patch/1024795/
> >> > >
> >> > > When using this CONFIG_LMB the max_size or the
> lmb_get_free_size(&lmb, load_addr); returns 0, no matter what.
> >> > > And it triggers the following error,
> >> > > TFTP error: trying to overwrite reserved memory...
> >> > > I did a quick fix by adding #undef CONFIG_LMB in the file,
> net/tftp.c
> >> > > So, I would like to know why this doesn’t work as it was working
> before applying this patch ?
> >> >
> >> > Can you add "#define DEBUG" as the first line in 'lib/lmb.c'? That
> >> > should give you debug
> >> > output when lmb is used.
> >> >
> >> >
> >> > I did add DEBUG macro to lmb.c but the function having the debug
> messages isn't getting called. I suppose it was from fs/fs.c
> >>
> >> Right, tftp.c is missing the call to that funcftion. Could you add the
> >> call to 'lmb_dump_all(&lmb);'
> >> right below 'lmb_init_and_reserve()' in tftp.c?
> >>
> >> That should give you the output required. And while at it, tell us
> >> what 'load_addr' is set to
> >> (by adding a printf in tftp.c, too).
> >>
> >> Thanks,
> >> Simon
> >
> >
> > Thanks for your patience and time.
> >
> > Please find the log below,
> >
> >
> >
> > DHCP client bound to address 172.17.0.2 (1285 ms)
> >
> > Using usb_ether device
> >
> > TFTP from server 172.17.0.1; our IP address is 172.17.0.2
> >
> > Filename 'u-boot.img'.
> >
> > lmb_dump_all:
> >
> >     memory.cnt             = 0x0
> >
> >     memory.size            = 0xx
> >
> >
> >
> >     reserved.cnt           = 0x0
> >
> >     reserved.size          = 0xx
> >
> > load_addr: 0x82000000
> >
> >
> >
> > TFTP error: trying to overwrite reserved memory...
> >
> > Problem booting with BOOTP
> >
> >
> >
> > In my u-boot it shows the DRAM size properly as 256MiB
> >
> > So, do I need to configure my RAM size in SPL stage as well, such that
> SPL is aware of the memory size ?
>
> Ehrm, are you doing this from SPL?
>

Yes, SPL loads u-boot onto the DRAM from Network, when the NAND is empty.

By flashing the same MLO and u-boot binaries onto the NAND, and then
doing *dhcp
MLO *from u-boot prompt gives the following log,

Using usb_ether device
TFTP from server 172.17.0.1; our IP address is 172.17.0.2
Filename 'MLO'.
*lmb_dump_all:*








*memory.cnt = 0x1memory.size = 0x0memory.reg[0x0].base = 0x80000000.size =
0x10000000reserved.cnt = 0x1reserved.size = 0x0reserved.reg[0x0].base =
0x8df2ab98.size = 0x20d5468*
load_addr: 0x80200000


>
> You need the RAM size for 'lmb_init_and_reserve()' to read, yes.
> Otherwise it can't know
> where to safely allocate things.
>
> Regards,
> Simon
>

Would you think, SPL should also do the same or is this valid only for
u-boot ?

Because, during SPL stage, the RAM would be mostly free anyway, so would
you think, we can just use this lmb check only for u-boot but not for SPL ?

Regards,
Moses Christopher

>

>
> >>
> >> >
> >> > FYI,
> >> > I'm trying to load SPL and uboot on RAM, using USB-ETH. Also the
> environment is not stored separately, neither the device tree.
> >> >
> >> >
> >> > The lmb code works by getting the RAM size, adding reserved areas and
> then only
> >> > allowing allocations in non-reserved areay. However, the RAM size is
> >> > not fully used
> >> > depending on some config options and/or environment variables.
> There's possibly
> >> > something wrong in your configuration around that.
> >> >
> >> >
> >> > Because, earlier to this patch, net/tftp.c isn't actually checking
> for the reserved memory regions and is able to download the files properly
> on the RAM and it works. I know, that's not a good approach, hence you've
> made the necessary changes to correct it.
> >> >
> >> > Could you kindly provide me some information, where I can read more
> about the reserved memory regions and how exactly some region is treated as
> reserved region ?
> >> >
> >> > Also, it'd be great if you could provide some information related to
> the configuration of Reserved and free addresses of RAM.
> >> >
> >> > Thank you for your patience and time.
> >> >
> >> > Regards,
> >> > Simon
> >> >
> >> > >
> >> > > Best regards,
> >> > > Moses Christopher
> >> >
> >> > Best regards,
> >> > Moses Christopher
>