* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... [not found] <b4480088deb34022b5f2e6e8f7c42015@in.bosch.com> @ 2019-09-05 14:14 ` Moses Christopher 2019-09-06 6:13 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Moses Christopher @ 2019-09-05 14:14 UTC (permalink / raw) To: u-boot 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 ? Best regards, *Moses Christopher* ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-05 14:14 ` [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory Moses Christopher @ 2019-09-06 6:13 ` Simon Goldschmidt 2019-09-09 9:28 ` Moses Christopher 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2019-09-06 6:13 UTC (permalink / raw) To: u-boot Hi, On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher <moseschristopherb@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. 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. Regards, Simon > > Best regards, > Moses Christopher ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-06 6:13 ` Simon Goldschmidt @ 2019-09-09 9:28 ` Moses Christopher 2019-09-11 8:32 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Moses Christopher @ 2019-09-09 9:28 UTC (permalink / raw) To: u-boot Hi Simon, Thanks for the prompt reply. On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, < simon.k.r.goldschmidt@gmail.com> wrote: Hi, On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher <moseschristopherb@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 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-09 9:28 ` Moses Christopher @ 2019-09-11 8:32 ` Simon Goldschmidt 2019-09-11 9:44 ` Moses Christopher 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2019-09-11 8:32 UTC (permalink / raw) To: u-boot On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher <moseschristopherb@gmail.com> wrote: > > Hi Simon, > > > Thanks for the prompt reply. > > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, <simon.k.r.goldschmidt@gmail.com> wrote: > > Hi, > > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher > <moseschristopherb@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 > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-11 8:32 ` Simon Goldschmidt @ 2019-09-11 9:44 ` Moses Christopher 2019-09-11 14:43 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Moses Christopher @ 2019-09-11 9:44 UTC (permalink / raw) To: u-boot On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, < simon.k.r.goldschmidt@gmail.com> wrote: > On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher > <moseschristopherb@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@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 ?* > > > > 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-11 9:44 ` Moses Christopher @ 2019-09-11 14:43 ` Simon Goldschmidt 2019-09-11 18:59 ` Moses Christopher 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2019-09-11 14:43 UTC (permalink / raw) To: u-boot On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher <moseschristopherb@gmail.com> wrote: > > > > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, <simon.k.r.goldschmidt@gmail.com> wrote: >> >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher >> <moseschristopherb@gmail.com> wrote: >> > >> > Hi Simon, >> > >> > >> > Thanks for the prompt reply. >> > >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, <simon.k.r.goldschmidt@gmail.com> wrote: >> > >> > Hi, >> > >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher >> > <moseschristopherb@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? 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 > > >> >> > >> > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-11 14:43 ` Simon Goldschmidt @ 2019-09-11 18:59 ` Moses Christopher 2019-09-11 19:12 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Moses Christopher @ 2019-09-11 18:59 UTC (permalink / raw) To: u-boot On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt, < simon.k.r.goldschmidt@gmail.com> wrote: > On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher > <moseschristopherb@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@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@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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-11 18:59 ` Moses Christopher @ 2019-09-11 19:12 ` Simon Goldschmidt 2019-09-11 19:33 ` Moses Christopher 0 siblings, 1 reply; 11+ messages in thread From: Simon Goldschmidt @ 2019-09-11 19:12 UTC (permalink / raw) To: u-boot On 11.09.19 20:59, Moses Christopher wrote: > > On Wed, 11 Sep, 2019, 4:43 PM Simon Goldschmidt, > <simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com>> wrote: > > On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher > <moseschristopherb at gmail.com <mailto:moseschristopherb@gmail.com>> > wrote: > > > > > > > > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, > <simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com>> wrote: > >> > >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher > >> <moseschristopherb@gmail.com > <mailto:moseschristopherb@gmail.com>> wrote: > >> > > >> > Hi Simon, > >> > > >> > > >> > Thanks for the prompt reply. > >> > > >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, > <simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com>> wrote: > >> > > >> > Hi, > >> > > >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher > >> > <moseschristopherb@gmail.com > <mailto:moseschristopherb@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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-11 19:12 ` Simon Goldschmidt @ 2019-09-11 19:33 ` Moses Christopher 2019-09-11 20:24 ` Simon Goldschmidt 0 siblings, 1 reply; 11+ messages in thread From: Moses Christopher @ 2019-09-11 19:33 UTC (permalink / raw) To: u-boot On Wed, 11 Sep, 2019, 9:12 PM Simon Goldschmidt, < simon.k.r.goldschmidt@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@gmail.com > > <mailto:simon.k.r.goldschmidt@gmail.com>> wrote: > > > > On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher > > <moseschristopherb at gmail.com <mailto:moseschristopherb@gmail.com>> > > wrote: > > > > > > > > > > > > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, > > <simon.k.r.goldschmidt@gmail.com > > <mailto:simon.k.r.goldschmidt@gmail.com>> wrote: > > >> > > >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher > > >> <moseschristopherb@gmail.com > > <mailto:moseschristopherb@gmail.com>> wrote: > > >> > > > >> > Hi Simon, > > >> > > > >> > > > >> > Thanks for the prompt reply. > > >> > > > >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, > > <simon.k.r.goldschmidt@gmail.com > > <mailto:simon.k.r.goldschmidt@gmail.com>> wrote: > > >> > > > >> > Hi, > > >> > > > >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher > > >> > <moseschristopherb@gmail.com > > <mailto:moseschristopherb@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.., 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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... 2019-09-11 19:33 ` Moses Christopher @ 2019-09-11 20:24 ` Simon Goldschmidt 0 siblings, 0 replies; 11+ messages in thread From: Simon Goldschmidt @ 2019-09-11 20:24 UTC (permalink / raw) To: u-boot On 11.09.19 21:33, Moses Christopher wrote: > > On Wed, 11 Sep, 2019, 9:12 PM Simon Goldschmidt, > <simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@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@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com> > > <mailto:simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com>>> wrote: > > > > On Wed, Sep 11, 2019 at 11:44 AM Moses Christopher > > <moseschristopherb@gmail.com > <mailto:moseschristopherb@gmail.com> > <mailto:moseschristopherb@gmail.com > <mailto:moseschristopherb@gmail.com>>> > > wrote: > > > > > > > > > > > > On Wed, 11 Sep, 2019, 10:32 AM Simon Goldschmidt, > > <simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com> > > <mailto:simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com>>> wrote: > > >> > > >> On Mon, Sep 9, 2019 at 11:29 AM Moses Christopher > > >> <moseschristopherb@gmail.com > <mailto:moseschristopherb@gmail.com> > > <mailto:moseschristopherb@gmail.com > <mailto:moseschristopherb@gmail.com>>> wrote: > > >> > > > >> > Hi Simon, > > >> > > > >> > > > >> > Thanks for the prompt reply. > > >> > > > >> > On Fri, 6 Sep, 2019, 8:13 AM Simon Goldschmidt, > > <simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com> > > <mailto:simon.k.r.goldschmidt@gmail.com > <mailto:simon.k.r.goldschmidt@gmail.com>>> wrote: > > >> > > > >> > Hi, > > >> > > > >> > On Thu, Sep 5, 2019 at 4:14 PM Moses Christopher > > >> > <moseschristopherb@gmail.com > <mailto:moseschristopherb@gmail.com> > > <mailto:moseschristopherb@gmail.com > <mailto:moseschristopherb@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 > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory... @ 2020-11-12 15:27 Bernhard Kirchen 0 siblings, 0 replies; 11+ messages in thread From: Bernhard Kirchen @ 2020-11-12 15:27 UTC (permalink / raw) To: u-boot Hello Christopher, hello SImon, today I debugged this problem, as tftp was not working in my u-boot SPL (AM335x based custom board) for the reasons described in this thread. It turns out that lmb_init_and_reserve() could not set proper values as bd->bi_dram[0].size = 00000000. The reason IMHO is that dram_init_banksize() is NOT called in SPL unless CONFIG_SPL_OS_BOOT or CONFIG_HANDOFF or CONFIG_SPL_ATF is defined (see common/spl/spl.c:board_init_r(). As I have no use to set any of those, dram_init_banksize() is never called in my case. Subsequently, tftp fails when checking available memory. By calling dram_init_banksize() from my board's am33xx_spl_board_init() I can work around the issue. However, I think that dram_init_banksize() should be called in common/spl/spl.c:board_init_r() also if CONFIG_LBM is defined. Best, Bernhard ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-11-12 15:27 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <b4480088deb34022b5f2e6e8f7c42015@in.bosch.com>
2019-09-05 14:14 ` [U-Boot] Issue in u-boot; TFTP error: trying to overwrite reserved memory Moses Christopher
2019-09-06 6:13 ` Simon Goldschmidt
2019-09-09 9:28 ` Moses Christopher
2019-09-11 8:32 ` Simon Goldschmidt
2019-09-11 9:44 ` Moses Christopher
2019-09-11 14:43 ` Simon Goldschmidt
2019-09-11 18:59 ` Moses Christopher
2019-09-11 19:12 ` Simon Goldschmidt
2019-09-11 19:33 ` Moses Christopher
2019-09-11 20:24 ` Simon Goldschmidt
2020-11-12 15:27 Bernhard Kirchen
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.