Dear Anders,
in message fc.004c4e48001cc2803b9aca007685644e.1cc321@rea.de you wrote:
are you saying that the patch doesn't go far enough? (I feared that the patch might have gone too far :-)
No, I didn't want to say that.I think the patch is pretty good as is, separating one step can can be done indeoend of the other things. I just wanted to point out that this is only part of the tasks which are ahead of us.
It looks like a substantial amount of work to implement your wishes (but its doable, I believe).
Yes, it's some work; the most difficult thing is to verify that such changes don;t break any of the existing ports - and some of these are pretty complex and feature-rich. Complete re-testing just one board may well take a man-week or more...
Would you accept the patch as is as a first step in that direction (in order not to change too much in one step) provided the other ARM board maintainers don't object?
Yes, I will.
Furthermore, the startup code (cpu/<arm>/start.S) internally uses another variable (_TEXT_BASE) with the same content as _armboot_start. I agree that this mess should be cleaned up.
Fine. Let's remember this for the next step, then.
_armboot_end is the end address of the BSS and is used to determine the address of the VFD buffer.
This not optimal. Ideally, the display buffer would be located at the very end of memory (BTW: the same is true for the log buffer if configured), and U-Boot below it.
Again, my available HW doesn't have a display, so I can't test it. I'll take a look at it anyway, though.
Well, you probably can test with the log buffer enabled and check if the log buffer information can be passed to the Linux kernel (umm... I think this hasn't been tried ever on an ARM system)
Best regards,
Wolfgang Denk