• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 97 subscribers
  • Views 3034 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

AM3352: USB-ETH boot fails

AM3352: TFTP load error

Moses Christopher Bollavarapu
Intellectual 980 points

Part Number: AM3352

Hi,

I am getting following error, TFTP error: trying to overwrite reserved memory...


This pops up, because the CONFIG_LMB has been enabled in net/tftp.c file and now it checks for the memory if the address is reserved or free.
I would like to know, from where can I configure reserved/free addresses, if at all it is configurable.

FYI, Refer the following patch, 

Use case: When NAND is empty, I am trying to load SPL and u-boot via USB-ETH onto the RAM.

This works fine by undefining the CONFIG_LMB in net/tftp.c (avoiding the check for reserved memory regions).
But, I would like to have a proper solution to solve this issue.

Kindly, let me know how this memory address is marked as reserved or free. So that, I can use a free memory region of RAM to load the file.

  • 0
    TI__Mastermind 40890 points

    Hi,

    The code you are referring to is beyond the scope of what TI contributed to U-Boot. The patch that you are referencing was not contributed by TI so we will not be able to comment on it. Here are a couple of things I will recommend that might help to track down the issue:

    - Take a look at this link, it is about the patch you submitted but has a lot of the back and forth emails between the maintainer/reviewer and the developer concerning the patch that could provide additional insight concerning the patch.

    Expanded Patch Link

    - I would recommend adding the #define DEBUG to the lib/lmb.c file, this should output debug information on the LMB.

    - I am not aware of configuration for LMB memory size (that does not mean there is not any), but take a look at the memory size of your board vs. the TI EVM you might have used for a design base. The LMB size may be derived from board memory size, that is kind of a I hint I took from the link above. This assumes the custom board has a larger memory but U-Boot is configured for the EVM size. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Intellectual 980 points

    Hi Schuyler,

    Thanks for the prompt reply.

    Schuyler Patton said:

    Hi,

    The code you are referring to is beyond the scope of what TI contributed to U-Boot. The patch that you are referencing was not contributed by TI so we will not be able to comment on it. Here are a couple of things I will recommend that might help to track down the issue:

    - Take a look at this link, it is about the patch you submitted but has a lot of the back and forth emails between the maintainer/reviewer and the developer concerning the patch that could provide additional insight concerning the patch.

    Expanded Patch Link

    - I would recommend adding the #define DEBUG to the lib/lmb.c file, this should output debug information on the LMB.

    Yes I did that, I'll check in depth again.


    Schuyler Patton said:

    - I am not aware of configuration for LMB memory size (that does not mean there is not any), but take a look at the memory size of your board vs. the TI EVM you might have used for a design base. The LMB size may be derived from board memory size, that is kind of a I hint I took from the link above. This assumes the custom board has a larger memory but U-Boot is configured for the EVM size.

    Best Regards,

    Schuyler

    I'll try checking for the memory configuration, once again and figure it out.

     

  • 0 in reply to Schuyler Patton
    Intellectual 980 points

    Hi Schuyler,

    I am currently following up on this, I have debugged the lmb by calling lmb_dump_all from tftp.c, it says RAM size as unknown in SPL stage but is showing properly in u-boot stage,

    Kindly have a look at the following logs,

    Log Taken in SPL stage,

    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

    Log Taken in u-boot stage,

    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

    As far as I understand the am335x-*-u-boot.dtsi is the only file used by u-boot-spl.bin when the config option is set to OF_EMBED, is that right ?
    If yes, then the memory information is not defined there, but only defined in am335x-*.dts file. Hence, the RAM details are available with u-boot but not with SPL.

  • 0 in reply to Schuyler Patton
    Intellectual 980 points

    Hi Schuyler,

    I have tested the same on Beaglebone Black. Unfortunately, the Beagle Bone Black is also not having RAM size known in SPL stage or the blob used in SPL stage, which produces the following error in BBB as well,

    TFTP error: trying to overwrite reserved memory...

    I think, TI should note this down for the next u-boot release or so, because without configuring RAM size in SPL, or making LMB know the RAM size in SPL, the device can't boot from Ethernet, since SPL has to load u-boot on to the RAM then tftp would throw an error saying it can't write to RAM, as LMB does a memory check before tftp downloads a file on to the RAM.

  • 0 in reply to Moses Christopher Bollavarapu
    TI__Mastermind 40890 points

    Hi,

    Were you seeing this on the BBB with USB eth or were you using the ethernet connector on the board?

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Intellectual 980 points

    Schuyler Patton said:

    Were you seeing this on the BBB with USB eth or were you using the ethernet connector on the board?

    I have tested with USB-ETH. But, this should have no dependency right ?
    Because as far as I understand, using usb eth or ethernet connector, the next step would be execution of tftp and tftp has LMB check, which fails in SPL stage.

    FYI,
    My setup is BBB with USB-ETH -> trying to load SPL and U-boot from TFTP server.
    ROM code loads SPL from TFTP, now SPL is in RAM and tries to load U-boot from TFTP and now it fails.

    As far as I understand, LMB check is not applicable for AM335x boards in SPL stage.
    I'm not sure to what extent this is applicable for the whole AM33XX family.
    Should I send a patch to the community for further discussion on this ?

    in net/tftp.c it should be somewhat like this,

    #if defined(CONFIG_SPL_BUILD) && defined(CONFIG_AM33XX)
#undef CONFIG_LMB
#endif

  • 0 in reply to Moses Christopher Bollavarapu
    TI__Mastermind 40890 points

    Hi,

    Sorry for the delay in responding. I don't have access to the source at the moment but the file where you have the config check (net/tftp.c) is typically in an area where the community might reject specific architecture dependencies. I will check internally if your suggestion would be recommended.

    Best Regards,

    Schuyler 

  • 0 in reply to Schuyler Patton
    Intellectual 980 points

    Hi Schuyler,

    Yeah I guess that's not a good idea to have this check in net/tftp.c but somehow I sticked to the easy way rather than the standard way. I've just started working with u-boot recently and I'm still learning so much in that.

    I also think, there is an other way to tackle this issue, that's to provide a mechanism to read the memory size and reserved regions in SPL stage and update the lib/lmb.c to handle the case where fdtblob was not available.

    Thanks for your support.