[U-Boot-Users] Relocation of symbols?
Hi,
I've posted another question regarding this topic on 14th June 2005. Since I haven't received any answers, I'm unsure, if I'm in the correct mailinglist or if my problem was that trivial. In case of the latter one, please, give me a hint, where to post my questions instead.
So here's my new question:
I've declared a global array: char *walter[] = { "ABC", "DEF" };
The u-boot boots from flash and relocates itself into RAM. After relocation the array is relocated into RAM and so is its content (the pointers to strings). But the actual strings are still located in flash. "walter" is a global symbol located in ".data" section of the compiled object. Is this the behaviour I should expect, or is it a problem with u-boots relocation code?
Best regards, Andreas Block
Dear Andreas,
in message 3YJEA6HGSNLF3264765ZTQSQYSRNJI43.42bffa31@pc-block you wrote:
I've posted another question regarding this topic on 14th June 2005. Since I haven't received any answers, I'm unsure, if I'm in the correct mailinglist or if my problem was that trivial. In case of the latter one, please, give me a hint, where to post my questions instead.
You are on the right list here.
It's just that not many people really understand all the details how the relocation works.
The u-boot boots from flash and relocates itself into RAM. After relocation the array is relocated into RAM and so is its content (the pointers to strings). But the actual strings are still located in flash. "walter" is a global symbol located in ".data" section of the compiled object. Is this the behaviour I should expect, or is it a problem with u-boots relocation code?
If you look at the code, then you will find that the same thing happens to all pointers with static initialization. If you think a bit about it you will probably be not surprised - how should the compiler know that the addresses of your strings might change? and after the compiler generated code with a static initializer - who should then know that the contents of this variable might need to be relocated?
See for example how we manually adjust (= relocate) the command table and other pointer constants in board_init_r().
I guess you can probably tell GCC to add GOT entries for these pointers, but I have to admit that I don't know off-hand what's the most efficient way.
Best regards,
Wolfgang Denk
On 6/27/05, Wolfgang Denk wd@denx.de wrote:
Dear Andreas,
in message 3YJEA6HGSNLF3264765ZTQSQYSRNJI43.42bffa31@pc-block you wrote:
It's just that not many people really understand all the details how the relocation works.
<stuff deleted>
I guess you can probably tell GCC to add GOT entries for these pointers, but I have to admit that I don't know off-hand what's the most efficient way.
Just to satisfy my curiosity...
What is the design decision behind u-boot building as a single relocatable binary (with all the complexities associated with relocation)? As opposed to a a two stage process with a small chunk of bootstrap code encapsulating the main u-boot image. The bootstrap code being linked seperatly from the main image so each image runs in the address space it is linked to. (like a Linux zImage; bootstrap code only responsible for initializing RAM, copying the main image and jumping to it).
I can see that a two stage scheme would sidestep the relocation issues mentioned above and should make probing with a debugger simpler. What are the advantages of the single binary approach? Image size perhaps?
Cheers, g.
In message 528646bc05062709261380120e@mail.gmail.com you wrote:
What is the design decision behind u-boot building as a single relocatable binary (with all the complexities associated with
Making it as easy to port to new hardware and to debug as possible. Which includes for example initializing a serial (or other) console port as soon as possible in the initialization sequence. Which in turn requires access to a lot of functions in the "general" code like stdio and string functions, access to the environment (to read the baudrate definition), which in turn may require access to I2C (like to access an EEPROM) etc.
relocation)? As opposed to a a two stage process with a small chunk of bootstrap code encapsulating the main u-boot image. The bootstrap
Such a "small chunk" would have to include the most critical hadrware initialization, especially that of the SDRAM. If you follow this mailing list for a while you will know that this alone makes 99% of all the "help me" postings on this list, even though it is really easy to debug: you have printf() and all the like. Now assume this was in a "small chunk" which has to work without all these features - and which is failing silently as a black box.
code being linked seperatly from the main image so each image runs in the address space it is linked to. (like a Linux zImage; bootstrap code only responsible for initializing RAM, copying the main image and jumping to it).
The "only" in this sentence in inappropriate. This is one of the most critical areas, and you really want to have all comfort for debugging that you can get.
Try searching this list and count how many people report about problems where the system hangs or acts weird just after relocation. Assume this happened in some minimal assember code without console, without printf etc. You really don't want to have that.
I can see that a two stage scheme would sidestep the relocation issues mentioned above and should make probing with a debugger simpler. What are the advantages of the single binary approach? Image size perhaps?
No, the major concern is to make U-Boot easy to debug and to port. All the things that happen after relocation are "simple" issues ;-)
Best regards,
Wolfgang Denk
On 6/27/05, Wolfgang Denk wd@denx.de wrote:
In message 528646bc05062709261380120e@mail.gmail.com you wrote:
relocation)? As opposed to a a two stage process with a small chunk of bootstrap code encapsulating the main u-boot image. The bootstrap
Such a "small chunk" would have to include the most critical hadrware initialization, especially that of the SDRAM. If you follow this mailing list for a while you will know that this alone makes 99% of all the "help me" postings on this list, even though it is really easy to debug: you have printf() and all the like. Now assume this was in a "small chunk" which has to work without all these features - and which is failing silently as a black box.
I do understand this; I wasn't very clear what I meant, see below.
code being linked seperatly from the main image so each image runs in the address space it is linked to. (like a Linux zImage; bootstrap code only responsible for initializing RAM, copying the main image and jumping to it).
The "only" in this sentence in inappropriate. This is one of the most critical areas, and you really want to have all comfort for debugging that you can get.
Let me clarify: I'm using "only" to refer to responsibilities, not to code size or debug facilities. I agree that bootstrapping is the most critical function and debug support is non-negotiable. I meant that the bootstrap is responsible to get the board ready for the second stage; It would not have any exotic functionality for were to get the second stage or handling boot options. All that would stay in the second stage.
Try searching this list and count how many people report about problems where the system hangs or acts weird just after relocation. Assume this happened in some minimal assember code without console, without printf etc. You really don't want to have that.
And I do understand this; I was not suggesting an absolute minimalist environment. Other than final footprint size (which is not a small issue either), there is nothing preventing common code from being linked into both images. Are there any estimates/measurements on how much code is executed both before and after relocation?
The problem with relocation is that it adds a layer of complexity to the debug process after jumping into RAM. Things such as the manipulating the command tables so the pointers match up again. Every time a new static or global is added, you need to worry about such things.
For example; when built for flash you cannot load the image into RAM and run it (i.e. from dBug) to see if the code after relocation is working correctly. This makes it more difficult to track down a relocation problem. When relocation hangs, it can be difficult to isolate the problem down to code running before or after relocation. However, if it was a two stage image, you could run the RAM stage from dBug. If it doesn't work then you know you need to fix the RAM image problem before fixing the ROM code. If it does work then you know the problem is with the ROM portion. As a bonus, you know that code running out of RAM is identical regardless of whether you've booted from FLASH or not.
Ultimatly, I'm asking/debating whether or not a two-image scheme would make it simpler to debug. Granted there are other issues, such as duplicate copies of functions; but that's why I'm asking, to get other perspectives and become a better designer. :-)
Comments?
In message 528646bc050627152162d1dba@mail.gmail.com you wrote:
The problem with relocation is that it adds a layer of complexity to the debug process after jumping into RAM. Things such as the
It's nothing compared to what you get with a two stage process. You either end up with lots of code duplication (and duplication of problems and a huge memory footprint) or with a system that is a PITA to port to new hardware.
manipulating the command tables so the pointers match up again. Every time a new static or global is added, you need to worry about such things.
Remember that this effects only staticaly intialized pointers.
The simple thing to do is to avoid these.
There are other restrictions like having no writable data segment nor zeroed bss space in the starup phase. We can live with this just fine.
For example; when built for flash you cannot load the image into RAM and run it (i.e. from dBug) to see if the code after relocation is working correctly. This makes it more difficult to track down a
Sorry, I don't understand what you mean.
relocation problem. When relocation hangs, it can be difficult to isolate the problem down to code running before or after relocation.
No, this is a trivial case. When relocation hangs, then your SDRAM initialization is broken. Period.
However, if it was a two stage image, you could run the RAM stage from dBug. If it doesn't work then you know you need to fix the RAM image problem before fixing the ROM code. If it does work then you know the
You don't understand. The problems are NOT int the "running in RAM part". This is simple stuff. It usually just works, once you got there. We spend 95% of teh porting and debugging time in the other part.
Ultimatly, I'm asking/debating whether or not a two-image scheme would make it simpler to debug. Granted there are other issues, such as duplicate copies of functions; but that's why I'm asking, to get other perspectives and become a better designer. :-)
Been there before. I know exactly why I don't want to change this part of the design. Feel free to try it out on your own. Port your code to 3 or 4 boards. I'm sure we'll see you back here soon.
Best regards,
Wolfgang Denk
On 6/27/05, Wolfgang Denk wd@denx.de wrote:
In message 528646bc050627152162d1dba@mail.gmail.com you wrote:
Ultimatly, I'm asking/debating whether or not a two-image scheme would make it simpler to debug. Granted there are other issues, such as duplicate copies of functions; but that's why I'm asking, to get other perspectives and become a better designer. :-)
Been there before. I know exactly why I don't want to change this part of the design. Feel free to try it out on your own. Port your code to 3 or 4 boards. I'm sure we'll see you back here soon.
Thanks for the info; I'd been wondering about the design background for a while, so it's good to get the perspective.
Cheers, g.
Hello Wolfgang,
thanks for your quick reply.
27.06.2005 15:40:25, Wolfgang Denk wd@denx.de wrote:
Dear Andreas,
[cut...]
It's just that not many people really understand all the details how the relocation works.
The u-boot boots from flash and relocates itself into RAM. After relocation the array is relocated into RAM and so is its content (the pointers to strings). But the actual strings are still located in flash. "walter" is a global symbol located in ".data" section of the compiled object. Is this the behaviour I should expect, or is it a problem with u-boots relocation code?
If you look at the code, then you will find that the same thing happens to all pointers with static initialization. If you think a bit about it you will probably be not surprised - how should the compiler know that the addresses of your strings might change? and after the compiler generated code with a static initializer - who should then know that the contents of this variable might need to be relocated?
See for example how we manually adjust (= relocate) the command table and other pointer constants in board_init_r().
I guess you can probably tell GCC to add GOT entries for these pointers, but I have to admit that I don't know off-hand what's the most efficient way.
I'm not quite sure, if I understood you. Just to summerize: 1. Absolute symbols are always relocated (my mail: "Does u-boot relocate absolute symbols?", 14.06.2005). 2. Statically initialized pointers are never relocated.
I do understand the second point (and can live with this behaviour), but I'd like to know, where you loose the required information to relocate the pointers as well. The first point is more important to me. As I understand, absolute symbols shouldn't be relocated at all. But I guess, you've a similar reason as for the statically initialized pointers. Anyway: Is it possible in any way to locate the array at the position I want it to be? Or the other way round: Is it as difficult to prevent absolute symbols from being added to the GOT as adding something?
Regards, Andreas
Best regards,
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de He had quite a powerful intellect, but it was as powerful like a locomotive, and ran on rails and was therefore almost impossible to steer. - Terry Pratchett, _Lords and Ladies_
In message CNLTR94IEOA0NLOJC7FCATQTQJGRO.42c14780@pc-block you wrote:
Just to summerize:
- Absolute symbols are always relocated (my mail: "Does u-boot relocate absolute
symbols?", 14.06.2005).
I don't think so. An absolute symbol is, ummm, absolute.
- Statically initialized pointers are never relocated.
Right.
I do understand the second point (and can live with this behaviour), but I'd like to know, where you loose the required information to relocate the pointers as well.
We don't lose anything. The compiler / linker never has any such information.
For example, asssume we have three pointers that are statically initialized. One is initialized with the physical address of some peripheral on your board, the second one with the address of a function in the U-Boot code, and the third one with the constant 0x12345678;
For GCC all three of them are just initialized pointers. Who should decide which of these need relocation, and which not?
The first point is more important to me. As I understand, absolute symbols shouldn't be relocated at all. But I guess, you've a similar reason as for the statically
I can't parse this.
I don't think that GCC/gas will normally generate any absolute symbols at all. If you manually define such symbols you are expected to understand what you are doing.
initialized pointers. Anyway: Is it possible in any way to locate the array at the position I want it to be? Or the other way round: Is it as difficult to prevent absolute symbols from being added to the GOT as adding something?
I mentioned the simple solution before: either you avoid statically initialized function pointers (for examply by initializing these dynamically after relocation), of you manually adjust your pointers after relocation, like we do for example for the command table. I also mentioned that there may be ways (like putting your stuff in a special segment and taking care to relocate this) to handle this, but I don't have a solution ready, nor do I see an urgent need for it.
Best regards,
Wolfgang Denk
28.06.2005 16:01:56, Wolfgang Denk wd@denx.de wrote:
In message CNLTR94IEOA0NLOJC7FCATQTQJGRO.42c14780@pc-block you wrote:
Just to summerize:
- Absolute symbols are always relocated (my mail: "Does u-boot relocate absolute
symbols?", 14.06.2005).
I don't think so. An absolute symbol is, ummm, absolute.
- Statically initialized pointers are never relocated.
Right.
Well, then I don't get it. Perhaps you could have a look at my mail referenced above. There's an example of U-Boot relocating an absolute symbol.
[...]
For GCC all three of them are just initialized pointers. Who should decide which of these need relocation, and which not?
Well, I think there has to be a difference for the compiler in the next two cases:
char *walter = 0x4711; char *herbert = "Thommy, the cat";
The first one shouldn't be relocated by the compiler, but the last one has to be relocated, in order to make the program work. At least as far as I understand it, please correct me, if I'm wrong.
The first point is more important to me. As I understand, absolute symbols shouldn't be relocated at all. But I guess, you've a similar reason as for the statically
I can't parse this.
I don't think that GCC/gas will normally generate any absolute symbols at all. If you manually define such symbols you are expected to understand what you are doing.
Again, I'd like to reference my above mentioned first request from 14.06.2005. I think, I know what I'm doing and what I want to do, but the generated absolute symbol is relocated by U-Boot.
initialized pointers. Anyway: Is it possible in any way to locate the array at the position I want it to be? Or the other way round: Is it as difficult to prevent absolute symbols from being added to the GOT as adding something?
I mentioned the simple solution before: either you avoid statically initialized function pointers (for examply by initializing these dynamically after relocation), of you manually adjust your pointers after relocation, like we do for example for the command table. I also mentioned that there may be ways (like putting your stuff in a special segment and taking care to relocate this) to handle this, but I don't have a solution ready, nor do I see an urgent need for it.
Thanks for your suggestions, but my main problem is I'm not wanting to change any common code and want to solve my problem in the problem specific code.
Best regards, Andreas Block
In message 85W32HGVT4WOKE0XT1Y1XVTND0OM74.42c15f80@pc-block you wrote:
Well, then I don't get it. Perhaps you could have a look at my mail referenced above. There's an example of U-Boot relocating an absolute symbol.
I didn't see it. You claimed that there was an absolute symbol in an object file, but I have not seen the result of the linker run (i. e. the U-Boot ELF file, the System.map file or the u-boot.map file); nor do I know what you are doing in your linker script.
Is your symbol "fpgadata" really listed in the GOT?
You mentioned that it contains a bad value, but did you verify that this was indeed casued by relocation (i. e. was the value really off by the relocation distance) ?
Well, I think there has to be a difference for the compiler in the next two cases:
char *walter = 0x4711; char *herbert = "Thommy, the cat";
No. There may be a difference for you, or for the resultof the code execution, but for the compiler it's all the same. AFAIK the ESP module of GCC has not been implemented yet :-)
The first one shouldn't be relocated by the compiler, but the last one has to be relocated, in order to make the program work. At least as far as I understand it, please correct me, if I'm wrong.
The _compiler_ does not do any relocation at all. He doesn't even know that such a thing exists. For the _compiler_ a pointer is just a pointer, in no way more special than an int.
I don't think that GCC/gas will normally generate any absolute symbols at all. If you manually define such symbols you are expected to understand what you are doing.
^^^^^^^^^^
The emphasis is on "understand".
Again, I'd like to reference my above mentioned first request from 14.06.2005. I think, I know what I'm doing and what I want to do, but the generated absolute symbol is relocated by U-Boot.
You know what you did, but you posted here because you didn't understand the results, right? I don't understand it either, so I tend to avoid doing such things ;-)
Thanks for your suggestions, but my main problem is I'm not wanting to change any common code and want to solve my problem in the problem specific code.
I really don't understand why you need to statically intialize this pointer at all, or why you bother about it being relocated or not. You mentioned that this is an address to where the code is downloaded by TFTP first. So you will have to set up a TFTP transfer and all these things - so the address in RAM should be known. Why don't you simply use a plain assignment in your code, then?
Best regards,
Wolfgang Denk
28.06.2005 17:21:35, Wolfgang Denk wd@denx.de wrote:
In message 85W32HGVT4WOKE0XT1Y1XVTND0OM74.42c15f80@pc-block you wrote:
Well, then I don't get it. Perhaps you could have a look at my mail referenced above. There's an example of U-Boot relocating an absolute symbol.
I didn't see it. You claimed that there was an absolute symbol in an object file, but I have not seen the result of the linker run (i. e. the U-Boot ELF file, the System.map file or the u-boot.map file); nor do I know what you are doing in your linker script.
Is your symbol "fpgadata" really listed in the GOT?
You mentioned that it contains a bad value, but did you verify that this was indeed casued by relocation (i. e. was the value really off by the relocation distance) ?
Well, I did show you the output of the generated object itself (before it got linked against U-Boot) and all I did in my test-command in U-Boot was to print the address of the symbol. All I can think of is relocation. But I'll think again, do some more tests and send you the result tomorrow.
Well, I think there has to be a difference for the compiler in the next two cases:
char *walter = 0x4711; char *herbert = "Thommy, the cat";
No. There may be a difference for you, or for the resultof the code execution, but for the compiler it's all the same. AFAIK the ESP module of GCC has not been implemented yet :-)
Of course it's not the compiler, but the linker. When talking about compiler, I was speaking of the entire tool-chain, sorry, for this imprecision. But I can show you, that it is indeed two different thinks for the compiler (which reaches some information about this difference to the linker). I'll do this tomorrow, too.
The first one shouldn't be relocated by the compiler, but the last one has to be relocated, in order to make the program work. At least as far as I understand it, please correct me, if I'm wrong.
The _compiler_ does not do any relocation at all. He doesn't even know that such a thing exists. For the _compiler_ a pointer is just a pointer, in no way more special than an int.
But the compiler tags relocation marks for the linker, right?
I don't think that GCC/gas will normally generate any absolute symbols at all. If you manually define such symbols you are expected to understand what you are doing.
The emphasis is on "understand".
Thanks a lot, I got that one.
Again, I'd like to reference my above mentioned first request from 14.06.2005. I
think,
I know what I'm doing and what I want to do, but the generated absolute symbol is relocated by U-Boot.
You know what you did, but you posted here because you didn't understand the results, right? I don't understand it either, so I tend to avoid doing such things ;-)
If I avoided all things I don't understand, I wouldn't have much to do, would I?
Thanks for your suggestions, but my main problem is I'm not wanting to change any common code and want to solve my problem in the problem specific code.
I really don't understand why you need to statically intialize this pointer at all, or why you bother about it being relocated or not. You mentioned that this is an address to where the code is downloaded by TFTP first. So you will have to set up a TFTP transfer and all these things - so the address in RAM should be known. Why don't you simply use a plain assignment in your code, then?
I will explain this once more in detail tomorrow. The main problem lies in the fact, that I don't want to touch any common code, but want to achive a solution within my project's code, only.
Regards, Andreas Block
28.06.2005 17:21:35, Wolfgang Denk wd@denx.de wrote:
In message 85W32HGVT4WOKE0XT1Y1XVTND0OM74.42c15f80@pc-block you wrote:
Well, then I don't get it. Perhaps you could have a look at my mail referenced above. There's an example of U-Boot relocating an absolute symbol.
I didn't see it. You claimed that there was an absolute symbol in an object file, but I have not seen the result of the linker run (i. e. the U-Boot ELF file, the System.map file or the u-boot.map file); nor do I know what you are doing in your linker script.
Is your symbol "fpgadata" really listed in the GOT?
No, it is not. Do absolute symbols need to be entered into the GOT? It is generated as described in the mail from 24.6.05. Attached to this mail, you find two source files. reloc_test.c simply adds a new U-Boot command "test", which does nothing else but printing the address of the symbol array. This symbol is generated from the array.S assembler source. As you will see, array is not located at 0x400000 in U_Boot. At least not after relocation.
You mentioned that it contains a bad value, but did you verify that this was indeed casued by relocation (i. e. was the value really off by the relocation distance) ?
Attached to this mail, you find two very short source files, which show the problem. Compile it once into a u-boot (sorry, the relocation offset is calculated by the offset of a dummy function, when running in RAM compared to its address shown by nm in the u- boot-binary, this needs to be changed to your needs at the beginning of reloc-test.c) and you'll not only see, that the address is wrong, but it is exactly off by relocation distance. Have a look with nm at the generated array.o to see, that the symbol is really absolute. Remove the define of ABTEST_UBOOT at the beginning of reloc_test.c to compile the example for linux and see it working as expected.
Well, I think there has to be a difference for the compiler in the next two cases:
char *walter = 0x4711; char *herbert = "Thommy, the cat";
No. There may be a difference for you, or for the resultof the code execution, but for the compiler it's all the same. AFAIK the ESP module of GCC has not been implemented yet :-)
One can see the difference with objdump. Look at the attached example.c. Examine it's object with "objdump --reloc example.o". There you can see, that the compiler generated relocation entries for the function pointers m2 and m3 and for the static initializer "xxx", but NOT for the other static initializer 0x4712. See objdump output below:
example.o: file format elf32-i386
RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE 00000016 R_386_32 m2 00000025 R_386_32 m3
RELOCATION RECORDS FOR [.data]: OFFSET TYPE VALUE 00000000 R_386_32 xxx
The first one shouldn't be relocated by the compiler, but the last one has to be relocated, in order to make the program work. At least as far as I understand it, please correct me, if I'm wrong.
The _compiler_ does not do any relocation at all. He doesn't even know that such a thing exists. For the _compiler_ a pointer is just a pointer, in no way more special than an int.
As shown above, you're wrong at this point, sorry.
I don't think that GCC/gas will normally generate any absolute symbols at all. If you manually define such symbols you are expected to understand what you are doing.
^^^^^^^^^^The emphasis is on "understand".
Again, I'd like to reference my above mentioned first request from 14.06.2005. I
think,
I know what I'm doing and what I want to do, but the generated absolute symbol is relocated by U-Boot.
You know what you did, but you posted here because you didn't understand the results, right? I don't understand it either, so I tend to avoid doing such things ;-)
Thanks for blaming myself of not understanding and suggesting to avoid the work I've to do. Believe me, there're only a few things I would like to do even more. But I can't. The reason to do it in the way described above is already described in my mail 24.6.05. Since there's an array declared as
extern const unsigned char array[];
in a common-code section, and I can't include the data directly as an initialization inside of my program file, like it's done in other projects:
const unsigned char array[] = { #include "array_data.c" };
You might see the problem. I can't initialize the array in my project files, because I don't know the content and it's size at build time. And on the other hand I can't initialize the symbol as a pointer, because it's simply wrong:
NO GOOD: const unsigned char *array = 0x400000;
And since I don't want to touch code common to several projects, I can't initialize the pointer dynamically. So the only way for me seems to be to generate the symbol as shown in array.S. But this doesn't work.
Thanks for your suggestions, but my main problem is I'm not wanting to change any common code and want to solve my problem in the problem specific code.
I really don't understand why you need to statically intialize this pointer at all, or why you bother about it being relocated or not. You mentioned that this is an address to where the code is downloaded by TFTP first. So you will have to set up a TFTP transfer and all these things - so the address in RAM should be known. Why don't you simply use a plain assignment in your code, then?
See above.
Regards, Andreas Block
In message 1ZQN5YCAUQ07JHUTNMTVTZWLHCTQQM.42c27942@pc-block you wrote:
...
NO GOOD: const unsigned char *array = 0x400000;
And since I don't want to touch code common to several projects, I can't initialize the pointer dynamically. So the only way for me seems to be to generate the symbol as shown in array.S. But this doesn't work.
I still can't understand why you cannot simply use an unitialized pointer, or even one which has a random init value, and then adjust it in your board specific code, say in a misc_init_r() or maybe even in a board_early_init_r() function?
Best regards,
Wolfgang Denk
29.06.2005 15:32:17, Wolfgang Denk wd@denx.de wrote:
In message 1ZQN5YCAUQ07JHUTNMTVTZWLHCTQQM.42c27942@pc-block you wrote:
...
NO GOOD: const unsigned char *array = 0x400000;
And since I don't want to touch code common to several projects, I can't initialize the pointer dynamically. So the only way for me seems to be to generate the symbol as shown in array.S. But this doesn't work.
I still can't understand why you cannot simply use an unitialized pointer, or even one which has a random init value, and then adjust it in your board specific code, say in a misc_init_r() or maybe even in a board_early_init_r() function?
Hmm, I take this as a refusal to help and a refusal to acquire new information. For me this is quite a basic problem, perhaps with my understanding, but meanwhile I guess not with my understanding, but with U-Boot itself. I'm not really looking for a workaround. The workaround for me, would be to change the common code and do another round of testing on all affected systems (which by the way is also needed with your suggestion). I was looking for information, understanding and a reason, why the way I had chosen failed. And once again, your suggestion to initialize a pointer in my project dependent code, absolutely ignores the fact, that the array is declared in common code as:
extern const char walter[];
Perhaps you don't see a difference to the following notation, which I had to use in my project dependent code:
extern const char *walter;
But there is one, even if you refuse to recognize. Feel free to ask, if you'd like to know.
I also wonder, whether the issue with the relocation of statically initialized pointers is solved?
Regards, Andreas
In message 8ECMIB8MIIC528283SP05OJFEB784F.42c2ad3d@pc-block you wrote:
I still can't understand why you cannot simply use an unitialized pointer, or even one which has a random init value, and then adjust it in your board specific code, say in a misc_init_r() or maybe even in a board_early_init_r() function?
Hmm, I take this as a refusal to help and a refusal to acquire new information. For me
Bollocks. Why don't you just take it as what it is: a question, and the attempt to understand your situation?
The attitude you display here does not really add to my motivation to dig into this later tonight as I originally intended.
this is quite a basic problem, perhaps with my understanding, but meanwhile I guess not with my understanding, but with U-Boot itself. I'm not really looking for a workaround.
That's a pity, because a workaround is probably easier available.
The workaround for me, would be to change the common code and do another round of
I think you could do without such a change. This may require a little hack, and may even result in a not strictly standard conforming im- plementation, but I think it can be done.
failed. And once again, your suggestion to initialize a pointer in my project dependent code, absolutely ignores the fact, that the array is declared in common code as:
extern const char walter[];
Perhaps you don't see a difference to the following notation, which I had to use in my project dependent code:
extern const char *walter;
But there is one, even if you refuse to recognize. Feel free to ask, if you'd like to know.
I have no idea why you think I ignored your arguments. I never said anything like this. Of course there is a difference. I am perfectly aware of this. But does it really prevent you from doing what you want to do? There is so many things you can do. For a little demon- stration of what can be done in C have a look at the winning entries of the IOCCC at http://www.de.ioccc.org/years.html :-)
I also wonder, whether the issue with the relocation of statically initialized pointers is solved?
There is no "issue" from my point of view. We know the situation, and we know how to live with it (by manually relocating the pointers).
When I ran into this situation 5 years ago I didn't find a better solution in a reasonable time. Feel free to show me that there is a better approach.
Best regards,
Wolfgang Denk
29.06.2005 19:32:46, Wolfgang Denk wd@denx.de wrote:
In message 8ECMIB8MIIC528283SP05OJFEB784F.42c2ad3d@pc-block you wrote:
I still can't understand why you cannot simply use an unitialized pointer, or even one which has a random init value, and then adjust it in your board specific code, say in a misc_init_r() or maybe even in a board_early_init_r() function?
Hmm, I take this as a refusal to help and a refusal to acquire new information. For me
Bollocks. Why don't you just take it as what it is: a question, and the attempt to understand your situation?
The attitude you display here does not really add to my motivation to dig into this later tonight as I originally intended.
Well, I'm sorry. I didn't want to sound rude. I was a bit dissappointed, because it seemed to me like you were ignoring great parts of my last post and sort of retreated to safer grounds.
Perhaps you could explain to me, how you think I could initialize the declared array at those positions you propose (it's not a problem of finding the referenced functions, but of knowing how to do it). I've sent a small example as answer to Rune Torgersen, which shows quite well, that one can't initialize/locate an "open" array (like fpgadata []) by initializing a pointer of the same name. Seemingly it's me, who's failing to see, but I don't get how your hint helps me with this.
this is quite a basic problem, perhaps with my understanding, but meanwhile I guess not with my understanding, but with U-Boot itself. I'm not really looking for a workaround.
That's a pity, because a workaround is probably easier available.
Sure. The project is actually working. All I'd like to do is to remove the changes done to common code and understand, where my problem with U-Boot stems from. If it's me, who's not getting it or if there's perhaps a slightly strange/non-generic behaviour in U-Boot. It took me quite a while to find out about my initialization problem and the non-relocated array-content (it was actually my debug output, which stayed in flash and wasn't of any help, when my PLD programmer killed the PLD and thus the flash access) and I would like to avoid such pain in the future.
The workaround for me, would be to change the common code and do another round of
I think you could do without such a change. This may require a little hack, and may even result in a not strictly standard conforming im- plementation, but I think it can be done.
failed. And once again, your suggestion to initialize a pointer in my project dependent code, absolutely ignores the fact, that the array is declared in common code as:
extern const char walter[];
Perhaps you don't see a difference to the following notation, which I had to use in my project dependent code:
extern const char *walter;
But there is one, even if you refuse to recognize. Feel free to ask, if you'd like to know.
I have no idea why you think I ignored your arguments. I never said anything like this. Of course there is a difference. I am perfectly aware of this. But does it really prevent you from doing what you want to do? There is so many things you can do. For a little demon- stration of what can be done in C have a look at the winning entries of the IOCCC at http://www.de.ioccc.org/years.html :-)
Well, at first, you cut away three quarters of my last post. Second, you told me in one of your answers, that the compiler knows no differences between these initializations and told me, U-Boot wasn't able to distinguish between them either. And no, it does not entirely prevent me from what I want to do, but it keeps me from doing it the smoothest way or the way I'd like to do it best.
I also wonder, whether the issue with the relocation of statically initialized
pointers
is solved?
There is no "issue" from my point of view. We know the situation, and we know how to live with it (by manually relocating the pointers).
When I ran into this situation 5 years ago I didn't find a better solution in a reasonable time. Feel free to show me that there is a better approach.
I'm afraid, I currently don't have the knowledge, nor the time (at least not at work) to do it in a better way. But I thought, perhaps you would like to at least discuss the way it's done now and perhaps, combined with your knowledge of how the things are running today, come to see a new/better/more generic way of doing it. But please don't get me wrong again, I certainly don't want to sound like I'm requesting a change in U- Boot or something alike.
Best regards, Andreas Block
In message SNHBXT98B63SQ98BA765YIC51A95Z52.42c3a90c@pc-block you wrote:
Well, I'm sorry. I didn't want to sound rude. I was a bit dissappointed, because it seemed to me like you were ignoring great parts of my last post and sort of retreated to safer grounds.
I accept ypour aplogy. I just have a habit of NOT trying to address the problem the same way and following the same thoughs - if I did this, O probably ended up with the same conclusions like you and no solution at all. Instead, I try to remember that There Is More Than One Way To Do Things.
That's why I ask for information that my seem irrelevant to you, or that I seem to ignore information you provided while I'm trying to go a different way.
Perhaps you could explain to me, how you think I could initialize the declared array at those positions you propose (it's not a problem of finding the referenced functions, but of knowing how to do it). I've sent a small example as answer to Rune Torgersen, which shows quite well, that one can't initialize/locate an "open" array (like fpgadata []) by initializing a pointer of the same name. Seemingly it's me, who's failing to see, but I don't get how your hint helps me with this.
See my previous posting.
Well, at first, you cut away three quarters of my last post. Second, you told me in one of your answers, that the compiler knows no differences between these initializations
Yes, I was wrong there. I stand corrected.
I'm afraid, I currently don't have the knowledge, nor the time (at least not at work) to do it in a better way. But I thought, perhaps you would like to at least discuss the way it's done now and perhaps, combined with your knowledge of how the things are running today, come to see a new/better/more generic way of doing it. But please don't get me wrong again, I certainly don't want to sound like I'm requesting a change in U- Boot or something alike.
I'm not that intimate with the linker or the changes they implement to it - which seem to break existing and seemingly perfectly good code that used to work for a long time. I'm afraid there is little help available - if there was a linker expert here on the list with some clever ideas he would have probably spoken up by now.
Best regards,
Wolfgang Denk
On Tue, 28 Jun 2005, Wolfgang Denk wrote:
Ever try. Ever fail. No matter. Try again. Fail again. Fail better. -- S. Beckett
I think that quote should be:
"Ever tried. Ever failed. No matter. Try again. Fail again. Fail better."
I also found this version, which makes even more sense:
"Ever tried? Ever failed? No matter. Try Again. Fail again. Fail better."
Regards, Marius
participants (4)
-
Andreas Block -
Grant Likely -
Marius Groeger -
Wolfgang Denk