Hi Vladim
On Fri, Sep 30, 2011 at 9:39 AM, Vadim Bendebury vbendeb@chromium.org wrote:
On Thu, Sep 29, 2011 at 4:15 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Vadim,
On Wed, Sep 28, 2011 at 12:55 AM, Vadim Bendebury vbendeb@chromium.org wrote:
On Tue, Sep 27, 2011 at 4:22 AM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Vadim,
On 27/09/11 08:50, Vadim Bendebury wrote:
On Wed, Aug 31, 2011 at 5:58 AM, Graeme Russ graeme.russ@gmail.com wrote:
[snip]
- gd is guaranteed to be cleared - The memory holding the buffer is not
so you would need to initialise it somehow - That could mean splitting the init for each arch
doesn't each console type have an init routine? this would be a place to initialize the header.
The point is that with pre-console buffer, we have a storage location for console output even before any console init routine is run - console is available as soon as gd is cleared (which is _very_ early indeed)
- pre_con_buffer is larger than CONFIG_PRE_CON_BUF_SZ. This will need to
be taken into consideration if the buffer is being crammed into a very tightly crafted memory map - Forgetting to take this into account is going to cause lots of pain. Now you could do:
struct pre_con_buff { u16 idx; char *buffer[CONFIG_PRE_CON_BUF_SZ - 2]; }I actually have just implemented this for coreboot. It has its own idiosyncrasies of course, the console buffer needs to be kept in three different places and the contents copied three times on the way up.
Ouch!
I used this structure for the log buffer:
struct pre_con_buff { u16 size; u16 idx; char buffer[0] };
Then, the initialization code would just get the memory area address and size, overlay this structure on top of it and set the size field to
<area size> - sizeof(struct pre_con_buff)
For U-Boot, that sounds like a lot of stuffing around to save two bytes in gd
yes, this results in a non power of two buffer size, but IMO the convenience of keeping everything in one place and (and not changing multiple .h files) is worth the lost performance of not being able to utilize power of two arithmetic optimization (which I think is negligible in any case).
In an embedded bootloader, every clock counts :) - You desktop junkies are too used to long boot times ;)
but the buffer size should really be a power two (so the compiler optimises the divides into shifts) - So now we have to define CONFIG_PRE_CON_BUF_SZ as say 258. It's starting to get messy
And messier (at least in the context of U-Boot - YMMV)
Regards,
Graeme