2011-09-04 11:06:05     Bf532-0.6 large BSS > 64K not clearing all the way

Document created by Aaronwu Employee on Sep 25, 2013
Version 1Show Document
  • View in full screen mode

2011-09-04 11:06:05     Bf532-0.6 large BSS > 64K not clearing all the way

Erik Lidgren (SWEDEN)

Message: 103271   

 

After adding video splash screen my BSS grew over 64K and I started to get some intermittent errors. It seems as if my BSS is only partially cleared. E.g. I have compiled some test code(without video) with a BSS of size 0x15258, it looks as it does not clear ram after offset 0x5258. If I print variables before offset 0x5258 they are always zero, after they vary and most are non-zero. I'm booting from SPI serial flash from a ldr image. The last block is a zerofill block to clear BSS with length 0x15258. If I add the BSS zero code in start.S so it zeros BSS regardless of relocation, all variables are zero. So it looks like the variables are not overwritten by something after start.S is run. Looking at the u-boot.ldr file all other blocks are less or max 32768 bytes in size. So I wonder if this is specific to my hardware, or if someone else have had similar problems. I did not find any similar thread, but it might be my search.

QuoteReplyEditDelete

 

 

2011-09-04 13:12:59     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Erik Lidgren (SWEDEN)

Message: 103272   

 

Some more details, I'm using u-boot-2010.06-2010R1-RC2 with blackfin-toolchain-2010R1-RC4 (gcc version 4.3.5 (ADI-2010R1-RC4)).

 

If I add padding to make BSS 0x10000 bytes in size it will clear entire BSS. If I make it 0x10004 bytes, only the first 4 bytes are cleared.

QuoteReplyEditDelete

 

 

2011-09-05 01:35:22     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Aaron Wu (CHINA)

Message: 103275   

 

Hi,

 

By "If I add the BSS zero code in start.S so it zeros BSS regardless of relocation, all variables are zero" what do you mean? Are you using the default u-boot, in the default code I find there is already BSS zero code like

 

        r0.l = __bss_vma;

        r0.h = __bss_vma;

        r1 = 0 (x);

        r2.l = __bss_len;

        r2.h = __bss_len;

        call _memset;

 

Do yo find the problem with or without these code? Thanks for clarification.

QuoteReplyEditDelete

 

 

2011-09-05 07:26:17     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Erik Lidgren (SWEDEN)

Message: 103280   

 

Sorry I'll try to explain better. When using spi flash to boot, start.S does not zero BSS since the it does not need to relocate. For my test I moved the .Lnorelocate label to before BSS zero code. That way it would zero BSS for spi flash boot too. With this change I don't see the problem.

 

.Lnorelocate:

 

/* Initialize BSS section ... we know that memset() does not

  * use the BSS, so it is safe to call here.  The bootrom LDR

  * takes care of clearing things for us.

  */

serial_early_puts("Zero BSS");

r0.l = __bss_vma;

r0.h = __bss_vma;

r1 = 0 (x);

r2.l = __bss_len;

r2.h = __bss_len;

call _memset;

QuoteReplyEditDelete

 

 

2011-09-06 01:54:15     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Mike Frysinger (UNITED STATES)

Message: 103282   

 

i recall there being problems with blocks that were greater than a certain size, but that was loading data and not zeroing things out

 

post `bfin-elf-ldr -qs u-boot.ldr` output

QuoteReplyEditDelete

 

 

2011-09-06 15:47:17     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Erik Lidgren (SWEDEN)

Message: 103311   

 

I don't have a 'bfin-elf-ldr', looking at the build output I can see that it uses 'bfin-uclinux-ldr'. Here is the output from that:

 

bfin-uclinux-ldr -qs u-boot.ldr

  DXE 1 at 0x00000000:

              Offset      Address     Bytes    Flags

    Block  1 0x00000000: 0xFFA08000 0x00001234 0x0008 ( init )

    Block  2 0x0000123E: 0x03FA0000 0x00008000 0x0000 ( )

    Block  3 0x00009248: 0x03FA8000 0x00008000 0x0000 ( )

    Block  4 0x00011252: 0x03FB0000 0x00008000 0x0000 ( )

    Block  5 0x0001925C: 0x03FB8000 0x00008000 0x0000 ( )

    Block  6 0x00021266: 0x03FC0000 0x00001868 0x0000 ( )

    Block  7 0x00022AD8: 0xFFA08000 0x00000028 0x0000 ( )

    Block  8 0x00022B0A: 0x03FC18A0 0x00010004 0x8001 ( zerofill final )

QuoteReplyEditDelete

 

 

2011-09-11 21:00:01     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Aaron Wu (CHINA)

Message: 103358   

 

bfin-uclinux-ldr -qs returns something on my side like the following, so yes, you need to move the BSS zero code to later for excution to clear the BSS section larger than 16bits address (64K)

 

Block 15 0x00047E5C: 0xAD6A0106 0x03F45C20 0x0007105C 0x00000000 ( 16bit-dma-from-16bit fill ) Means the ROM code will move and clear the BSS section to memory address 0x03F45C20 where DRAM is located with 16bits DMA, 64K at most.

 

Block  2 0x00000010: 0xADAF0806 0xFFA00000 0x00000170 0xDEADBEEF ( 16bit-dma-from-16bit init ), before the DRAM is ready to use, this move the DRAM realted init code to 0xFFA00000, where L1 is located, and the init code get executed to init the system.

 

Note that all above is performed by ROM code before the u-boot begins at start.S

 

bfin-uclinux-ldr -qs u-boot.ldr

  DXE 1 at 0x00000000:

              Offset      BlockCode  Address    Bytes      Argument

    Block  1 0x00000000: 0xADB25006 0xFFA00000 0x00000000 0x00047E6C ( 16bit-dma-from-16bit ignore first )

    Block  2 0x00000010: 0xADAF0806 0xFFA00000 0x00000170 0xDEADBEEF ( 16bit-dma-from-16bit init )

    Block  3 0x00000190: 0xAD340006 0x03F00000 0x00001E50 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block  4 0x00001FF0: 0xAD711006 0x00000000 0x00002000 0xBAADF00D ( 16bit-dma-from-16bit ignore )

    Block  5 0x00004000: 0xADE50006 0x03F01E50 0x000061B0 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block  6 0x0000A1C0: 0xAD7A0006 0x03F08000 0x00008000 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block  7 0x000121D0: 0xADFB0006 0x03F10000 0x00008000 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block  8 0x0001A1E0: 0xAD7B0006 0x03F18000 0x00008000 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block  9 0x000221F0: 0xADF80006 0x03F20000 0x00008000 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block 10 0x0002A200: 0xAD780006 0x03F28000 0x00008000 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block 11 0x00032210: 0xADF90006 0x03F30000 0x00008000 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block 12 0x0003A220: 0xAD790006 0x03F38000 0x00008000 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block 13 0x00042230: 0xADC10006 0x03F40000 0x00005BE4 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block 14 0x00047E24: 0xADFE0006 0xFFA00000 0x00000028 0xDEADBEEF ( 16bit-dma-from-16bit )

    Block 15 0x00047E5C: 0xAD6A0106 0x03F45C20 0x0007105C 0x00000000 ( 16bit-dma-from-16bit fill )

    Block 16 0x00047E6C: 0xAD748006 0xFFA00000 0x00000000 0x00000000 ( 16bit-dma-from-16bit final )

QuoteReplyEditDelete

 

 

2011-09-12 15:52:12     Re: Bf532-0.6 large BSS > 64K not clearing all the way

James Kosin (UNITED STATES)

Message: 103366   

 

Aaron,

 

Shouldn't the linker then generate multiple fill operations to properly fill the required area?

 

James

QuoteReplyEditDelete

 

 

2011-09-13 22:58:48     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Aaron Wu (CHINA)

Message: 103375   

 

Current solution is list above, we are thinking about moving the location of the BSS clear code in start.S and merge your change to the trunk. Thanks

QuoteReplyEditDelete

 

 

2011-09-17 22:56:35     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Mike Frysinger (UNITED STATES)

Message: 103437   

 

having u-boot zero the bss is wrong.  it needlessly slows down boot for most systems.  fix ldr-utils to generate multiple zero blocks based on the max size that the bootrom can zero out.

 

so talk to the bootrom team at ADI and see if the 64KiB limitation is specific to old versions (and so ldr-utils only needs to split large blocks with older ones), or to all.

QuoteReplyEditDelete

 

 

2011-09-18 22:27:00     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Aaron Wu (CHINA)

Message: 103442   

 

Thanks Mike, good point   Just discussed with Sonic, the Romcode is fixed in the chip after shipping out from the factory so for the first step we intend to add a Macro to enable the BSS clearing in u-boot but default it to be off. For customers encontering similar problem we suggest them to turn on the Macro. And talk to the bootrom code team for long term solution. How do you think about this?

QuoteReplyEditDelete

 

 

2011-09-19 01:46:30     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Mike Frysinger (UNITED STATES)

Message: 103444   

 

the user has already declared what cpu/silicon rev they're using, and that info gets passed to ldr-utils.  so the ldr-utils package knows exactly whether it should automatically split up the zero regions up into 64KiB chunks.  there should be no need for the user to specify bss clearing in the u-boot config.

 

all you have to ask the bootrom team is which cpus/silicon rev combos have this bug where the max zero region is 64KiB.  with that, you can tweak ldr-utils accordingly.

 

also, if you leave it as a config option, you still have the problem that the bss gets cleared too many times -- first the bootrom does it, and then u-boot does it.

QuoteReplyEditDelete

 

 

2011-09-19 15:00:47     Re: Bf532-0.6 large BSS > 64K not clearing all the way

James Kosin (UNITED STATES)

Message: 103449   

 

Mike & Aaron,

 

Came across this and don't know if this is related.

 

http://ez.analog.com/docs/DOC-1875

 

James

QuoteReplyEditDelete

 

 

2011-09-20 05:55:53     Re: Bf532-0.6 large BSS > 64K not clearing all the way

Aaron Wu (CHINA)

Message: 103458   

 

Hi James,

 

Sonic has just add the support for multiple fill blocks in the LDR utility in toolchain source code, if  you want to have a try you may fetch the latest toolchain code and compile it, then compile the u-boot, this should fix this problem without your current work around.

 

Aaron

QuoteReplyEditDelete

 

 

2011-09-22 22:24:31     Re: Bf532-0.6 large BSS > 64K not clearing all the way

James Kosin (UNITED STATES)

Message: 103503   

 

Aaron,

 

Seems to be working... though it chops the data up into 32K chunks.

 

James

Attachments

    Outcomes