[U-Boot-Users] u-boot BOOTELF clearing SHT_NOBITS sections
Hi,
u-boot's bootelf clears (memset to 0) sections of SHT_NOBITS type. This covers .bss sections - however, it might also includes other sections, not expected to be cleared as per some users expectations (stacks, for example).
I am beginning to wonder if this behavior is correct/desired: if one tries to bootelf an ELF file which happens to resizde somewhere inside the .bss section, or some other data section of the loaded code, bootelf clears it (or part of it...) while loading, corrupting the code to be loaded.
AFAIK, .bss is normally zeroed out in crt0 (or equivalent), so there is no need (?) to zero it in bootelf. Bootelf may also defer all such actions (clearing section) to the end of the loading process.
Please feel free to correct me I I am wrong...
Thanks,
Baruch Cochavy
On Sunday 04 May 2008, Baruch Cochavy wrote:
u-boot's bootelf clears (memset to 0) sections of SHT_NOBITS type. This covers .bss sections - however, it might also includes other sections, not expected to be cleared as per some users expectations (stacks, for example).
most people dont declare sections for stacks. i dont think ive ever seen an ELF that does it.
I am beginning to wonder if this behavior is correct/desired: if one tries to bootelf an ELF file which happens to resizde somewhere inside the .bss section, or some other data section of the loaded code, bootelf clears it (or part of it...) while loading, corrupting the code to be loaded.
if you have overlapping sections, then your ELF is broken. if you have data in the middle of the .bss, then it isnt a NOBITS by definition, it's PROGBITS. you're describing invalid scenarios.
AFAIK, .bss is normally zeroed out in crt0 (or equivalent), so there is no need (?) to zero it in bootelf. Bootelf may also defer all such actions (clearing section) to the end of the loading process.
there is no normal sense here. the only real guarantee is that when main() starts executing, the C runtime environment is entirely valid (or any pre-main initializers that get run). by dropping the behavior in question, you'd be breaking things that are working today, so it's pretty hard to change it at all.
really though, using the section headers is going to always lead to conflicting needs. the program headers should be used instead ... perhaps a new command (or option) can be added for it ... -mike
Many thanks for the quick reply/comments. Please allow me to explain: I try to bootelf from ELF bits residing in a region of memory (address range) that partially overlaps the loaded code .bss (the ELFs bits just happen to reside in that specific memory region that will eventually become the .bss by pure coincidence of address selection.)
Of course, a section of memory outside the reach of the application can be found to hold the ELF bits. Unfortunately, this also wastes valuable RAM bits (the Elf bits get downloaded; they are at no stage ROM resident), or will otherwise require some run-time memory layout calculation trickery I would rather avoid.
And a final note: try as I may, I could find no specific reference (ABI or otherwise) to indicate whose responsibility is it to clear the .bss. As for u-boot, I assume any change here would break things working today. Possibly, a bootelf invocation option would be nice....
Thanks again, Baruch
-----Original Message----- From: Mike Frysinger [mailto:vapier@gentoo.org] Sent: Sunday, May 04, 2008 11:16 AM To: u-boot-users@lists.sourceforge.net Cc: Baruch Cochavy Subject: Re: [U-Boot-Users] u-boot BOOTELF clearing SHT_NOBITS
sections
On Sunday 04 May 2008, Baruch Cochavy wrote:
u-boot's bootelf clears (memset to 0) sections of SHT_NOBITS type.
This
covers .bss sections - however, it might also includes other
sections,
not expected to be cleared as per some users expectations (stacks,
for
example).
most people dont declare sections for stacks. i dont think ive ever
seen
an ELF that does it.
I am beginning to wonder if this behavior is correct/desired: if one tries to bootelf an ELF file which happens to resizde somewhere
inside
the .bss section, or some other data section of the loaded code,
bootelf
clears it (or part of it...) while loading, corrupting the code to
be
loaded.
if you have overlapping sections, then your ELF is broken. if you
have
data in the middle of the .bss, then it isnt a NOBITS by definition, it's PROGBITS. you're describing invalid scenarios.
AFAIK, .bss is normally zeroed out in crt0 (or equivalent), so there
is
no need (?) to zero it in bootelf. Bootelf may also defer all such actions (clearing section) to the end of the loading process.
there is no normal sense here. the only real guarantee is that when main() starts executing, the C runtime environment is entirely valid (or any pre-main initializers that get run). by dropping the behavior in question, you'd be breaking things that are working today, so it's pretty hard
to
change it at all.
really though, using the section headers is going to always lead to conflicting needs. the program headers should be used instead ...
perhaps
a new command (or option) can be added for it ... -mike
On Sunday 04 May 2008, Baruch Cochavy wrote:
Many thanks for the quick reply/comments. Please allow me to explain: I try to bootelf from ELF bits residing in a region of memory (address range) that partially overlaps the loaded code .bss (the ELFs bits just happen to reside in that specific memory region that will eventually become the .bss by pure coincidence of address selection.)
converting the ELF into a bootable U-Boot image may work better ...
Of course, a section of memory outside the reach of the application can be found to hold the ELF bits. Unfortunately, this also wastes valuable RAM bits (the Elf bits get downloaded; they are at no stage ROM resident), or will otherwise require some run-time memory layout calculation trickery I would rather avoid.
as soon as you say "load an ELF", you've already agreed to waste space. the ELF itself is full of information that is not needed at all. this is why we have the bootable U-Boot format. or you convert it to binary using objcopy, and just execute that.
And a final note: try as I may, I could find no specific reference (ABI or otherwise) to indicate whose responsibility is it to clear the .bss. As for u-boot, I assume any change here would break things working today. Possibly, a bootelf invocation option would be nice....
i would be willing to bet that there is no document anywhere. there are general guidelines, but really the only requirement as i mentioned is that as soon as you do start executing C, the C runtime environment must have been fully initialized. some people think the crt objects (either from the toolchain or hand written) should do it. others think the ELF loader should be doing it. -mike
Hi, Similar problem I have also faced, We used bootelf to boot a big image (really big around 7.5 MB ELF image). Situation is like this, We have 32 MB of RAM in our board. And we load this image via TFTP to lower memory , but when i do bootelf, some how BSS section is getting overlapped with the starting of the memory where i had load the elf image using TFTP earlier. Thus initial portion of ELF (at least ELF header) is getting cleared, and As you know ELF header is containing the information about the location where to jump. So my control is jumping to 0x00000000 location. In order to solve this problem I save this address (entry point) in a local variable and jumped to that location. I think cmd_elf.c need some modification, and I was thinking of sending a patch to this problem
Thanks, Chetan Nanda
On Sun, May 4, 2008 at 2:19 PM, Mike Frysinger vapier@gentoo.org wrote:
On Sunday 04 May 2008, Baruch Cochavy wrote:
Many thanks for the quick reply/comments. Please allow me to explain: I try to bootelf from ELF bits residing in a region of memory (address range) that partially overlaps the loaded code .bss (the ELFs bits just happen to reside in that specific memory region that will eventually become the .bss by pure coincidence of address selection.)
converting the ELF into a bootable U-Boot image may work better ...
Of course, a section of memory outside the reach of the application can be found to hold the ELF bits. Unfortunately, this also wastes valuable RAM bits (the Elf bits get downloaded; they are at no stage ROM resident), or will otherwise require some run-time memory layout calculation trickery I would rather avoid.
as soon as you say "load an ELF", you've already agreed to waste space. the ELF itself is full of information that is not needed at all. this is why we have the bootable U-Boot format. or you convert it to binary using objcopy, and just execute that.
And a final note: try as I may, I could find no specific reference (ABI or otherwise) to indicate whose responsibility is it to clear the .bss. As for u-boot, I assume any change here would break things working today. Possibly, a bootelf invocation option would be nice....
i would be willing to bet that there is no document anywhere. there are general guidelines, but really the only requirement as i mentioned is that as soon as you do start executing C, the C runtime environment must have been fully initialized. some people think the crt objects (either from the toolchain or hand written) should do it. others think the ELF loader should be doing it. -mike
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Sorry to be a pest but I just can't figure out how to set the CPU properly in u-boot for my s3c2410. I think I have the first part correct for 266mHz but I get usb and other problems when booting the kernel. If I use the s3c24xx speed set 266 (openmoko patch) then things work flawlessly.
This is what I'm trying for FCLK = 266 MHz, HCLK = 133 MHz, PCLK = 66 MHz, UCLK = 48 MHz
The relvent sections of cmd_s3cxx.c from the openmoko patch show
#define CLKDIVN_1_2_4 0x03
static const u_int32_t upllcon = ((0x78 << 12) + (0x2 << 4) + 0x3);
static const struct s3c24x0_pll_speed pll_configs[] = { ... (omitted other speeds) { .mhz = 266, .mpllcon = ((0x7d << 12) + (0x1 << 4) + 0x1), .clkdivn = CLKDIVN_1_2_4, }, };
Here's what I have in the u-Boot board config so far
#define M_MDIV 0x7d #define M_PDIV 0x1 #define M_SDIV 0x1
#define U_M_MDIV 0x78 #define U_M_PDIV 0x2 #define U_M_SDIV 0x3
I know I stumbled across a clock calculator for the s3c2410 somewhere on the net but of course now I can't find it anywhere.
Thanks for any help you can render. This is the last thing I need to be able to complete my u-boot setup.
On Sunday 04 May 2008, p wrote:
please do not hijack threads. start a new e-mail, dont pick a random thread and hit "reply". deleting the subject/body is not sufficient. -mike
participants (4)
-
Baruch Cochavy -
Chetan Nanda -
Mike Frysinger -
p