[U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory...
Simon Goldschmidt
simon.k.r.goldschmidt at gmail.com
Wed Sep 11 20:24:20 UTC 2019
On 11.09.19 21:33, Moses Christopher wrote:
>
> On Wed, 11 Sep, 2019, 9:12 PM Simon Goldschmidt,
> <simon.k.r.goldschmidt at gmail.com
> <mailto:simon.k.r.goldschmidt at gmail.com>> wrote:
>
>
>
> On 11.09.19 20:59, Moses Christopher wrote:
> >
> > On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt,
> > <simon.k.r.goldschmidt at gmail.com
> <mailto:simon.k.r.goldschmidt at gmail.com>
> > <mailto:simon.k.r.goldschmidt at gmail.com
> <mailto:simon.k.r.goldschmidt at gmail.com>>> wrote:
> >
> > On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
> > <moseschristopherb at gmail.com
> <mailto:moseschristopherb at gmail.com>
> <mailto:moseschristopherb at gmail.com
> <mailto:moseschristopherb at gmail.com>>>
> > wrote:
> > >
> > >
> > >
> > > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt,
> > <simon.k.r.goldschmidt at gmail.com
> <mailto:simon.k.r.goldschmidt at gmail.com>
> > <mailto:simon.k.r.goldschmidt at gmail.com
> <mailto:simon.k.r.goldschmidt at gmail.com>>> wrote:
> > >>
> > >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
> > >> <moseschristopherb at gmail.com
> <mailto:moseschristopherb at gmail.com>
> > <mailto:moseschristopherb at gmail.com
> <mailto: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
> <mailto:simon.k.r.goldschmidt at gmail.com>
> > <mailto:simon.k.r.goldschmidt at gmail.com
> <mailto:simon.k.r.goldschmidt at gmail.com>>> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher
> > >> > <moseschristopherb at gmail.com
> <mailto:moseschristopherb at gmail.com>
> > <mailto:moseschristopherb at gmail.com
> <mailto: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 = 0x1
> > memory.size = 0x0
> > memory.reg[0x0].base = 0x80000000
> > .size = 0x10000000
> >
> > reserved.cnt = 0x1
> > reserved.size = 0x0
> > reserved.reg[0x0].base = 0x8df2ab98
> > .size = 0x20d5468*
> > load_addr: 0x80200000
>
> OK, so that works for a start ;-)
>
> >
> >
> >
> > 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 ?
>
> Yes, SPL should do the same.
>
> >
> > 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 ?
>
> No. SPL still needs this check. On some platforms, SPL runs with BSS,
> stack or heap in RAM when executing this, so this is still an attack
> vector that should be prevented.
>
> Even if SPL does not use DRAM (only SRAM), we still have to check that
> we only write into valid DRAM addresses. E.g. a file larger than the
> DRAM would write to whatever comes next in the address range...
>
>
> Ah, that really makes sense. Sorry, if I'm asking too many basic questions.
>
> Which platform are you running this on, does SPL use a devicetree? In
> any case, you need your SPL to provide the valid RAM range.
>
>
> I'm using TI's AM335x based custom board, yes the SPL has the minimal
> devicetree embedded.
>
> If I understand it correctly, I've to configure my RAM information
> properly such that the SPL is able to get the RAM size, reserved size,
> free size, etc..,
Yes. I would have expected that to come from the devicetree though...
I'd appreciate if you could come back here with a solution what exactly
was missing to get it running, if only for the archives that other users
find the result.
Regards,
Simon
>
> Thanks again for you patience and time.
>
> Regards,
> Moses Christopher
>
>
> Regards,
> Simon
>
> >
> > 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
> >
>
More information about the U-Boot
mailing list