On 11.09.19 20:59, Moses Christopher wrote:
On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt,
<simon.k.r.goldschm...@gmail.com
<mailto:simon.k.r.goldschm...@gmail.com>> wrote:
On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher
<moseschristoph...@gmail.com <mailto:moseschristoph...@gmail.com>>
wrote:
>
>
>
> On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt,
<simon.k.r.goldschm...@gmail.com
<mailto:simon.k.r.goldschm...@gmail.com>> wrote:
>>
>> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher
>> <moseschristoph...@gmail.com
<mailto:moseschristoph...@gmail.com>> wrote:
>> >
>> > Hi Simon,
>> >
>> >
>> > Thanks for the prompt reply.
>> >
>> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt,
<simon.k.r.goldschm...@gmail.com
<mailto:simon.k.r.goldschm...@gmail.com>> wrote:
>> >
>> > Hi,
>> >
>> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher
>> > <moseschristoph...@gmail.com
<mailto:moseschristoph...@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...
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.
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
