Le 30/10/2010 15:45, Alexander Holler a écrit : > Hello, > > Am 30.10.2010 15:36, schrieb Albert ARIBAUD: > >>> The code is moved upwards, but that code still uses the data at d. >>> This results another problem: Some parts in the code are assuming that d >>> is cleared (set to zero in start.S). But what start.S does it to clear >>> the new location (z in the picture below). >> >> Wait a minute. No parts of the code assume BSS is *cleared*, or at least >> no pat of the should *should ever* assume that. BSS is not "zeroed >> data", it is "uninitialized data". > > Thats true for normal C, but I assume that is not true for u-boot.
You mean the rule is not respected for u-boot? then you should point out (or better yet, submit a patch to fix) parts of code which assume BSS is zero. Besides... U-boot *is* normal C (apart from the part before relocation where constraints prevent the use of any variable other than GD). > This reminds me on some problems I've had long long time ago, with > switching from debug to optimized code using vc++. I don't know if it is > still true (>10a ago), but in those days, vc++ had preset all not > initialized data with zero when optimization was turned off. > > If the code in u-boot would not assume that bss is zero, I don't > understand why clear_bss in start.S exists. As I said, out of courtesy. Still, BSS zeroing does not seem to relate to what you witness. You're not reading a variable that you think should be zero; you're writing then reading a BSS variable, and find that you read something different from what you read. BTW, can you add printfs() with the nand init functions to see where it writes? As it uses a pointer, if this pointer is not passed correctly for some reason, we'll be able to see. > Regards, > > Alexander Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
