On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt, < [email protected]> wrote:
> On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher > <[email protected]> wrote: > > > > > > > > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, < > [email protected]> wrote: > >> > >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher > >> <[email protected]> wrote: > >> > > >> > Hi Simon, > >> > > >> > > >> > Thanks for the prompt reply. > >> > > >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, < > [email protected]> wrote: > >> > > >> > Hi, > >> > > >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher > >> > <[email protected]> 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 > _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
