Hi Vladim On Fri, Sep 30, 2011 at 9:39 AM, Vadim Bendebury <vben...@chromium.org> wrote: > On Thu, Sep 29, 2011 at 4:15 PM, Graeme Russ <graeme.r...@gmail.com> wrote: >> Hi Vadim, >> >> On Wed, Sep 28, 2011 at 12:55 AM, Vadim Bendebury <vben...@chromium.org> >> wrote: >>> On Tue, Sep 27, 2011 at 4:22 AM, Graeme Russ <graeme.r...@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.r...@gmail.com> >>>>> wrote: >>
[snip] >> >> 1) 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) >> 2) 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot