[U-Boot] [PATCH V2] console: Implement pre-console buffer

Graeme Russ graeme.russ at gmail.com
Wed Aug 31 01:00:36 CEST 2011


Hi Simon, Mike, Wolfgang,

On Wed, Aug 31, 2011 at 7:02 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Wolfgang,
>
> On Tue, Aug 30, 2011 at 1:57 PM, Wolfgang Denk <wd at denx.de> wrote:
>> Dear Simon Glass,
>>
>> In message <CAPnjgZ1dQXMVeFk47=Gg5y+TCHG7WTdGk0b1WjSqOBhu2d0xnQ at mail.gmail.com> you wrote:
>>>
>>> In case it is interesting (which may be unlikely) here is the code
>>> generated by my compiler (common code stripped) for your example, and
>>
>> Which architecture / which compiler is this?
>
> It was ARM, gcc version 4.4.3.
>
>>
>>> one I added. It seems that % makes it worry about sign.
>>
>> Indeed!  We should use unsigned numbers here.  MUCH better now:
>>
>
> Yes it is much better. Perhaps an (unsigned) cast in the C code is
> better than hoping that the board author uses 1024U or similar.
>

[snip]

>>
>>
>> So indeed we should use unsigned arithmetics, and try to use
>> power-of-two sizes where possible.

I'll do another spin (probably not tonight - maybe tomorrow) which covers:

 - inline stub functions to reduce #ifdef clutter
 - unsigned casting of buffer size
 - Documentation in README including the fact that setting the buffer size
   to a value which is a power of 2 will provide more optimised code (for
   reasonably sane compilers ;))

Now as for the calculation of the buffer address... It could be calculated
dynamically in board.c but this will require another ulong in gd and the
pre-console buffer will be unusable until the calculation is done (and any
inadvertant printf() before this will likely cause some very bad behaviour)
Also, x86 does not do these calculations dynamically and I also think it
might make the pre-buffer console avaialble in early init_f

Getting back to gd for a sec - This patch (like the flagify patch set I
posted before) impacts the structure of gd. Does this trigger in increment
to the API Version? And as observed before, if the structure of gd is
fixed for any given API version, then we have a problem with all the
#ifdef's that are already in gd. If it _is_ the case that the API version
expects a particular fixed structure for gd, then maybe we need to remove
all the #ifdefs from gd - Yes it will lead to a few dead ulongs for a few
boards, but I don't see any practical alternatives. I did think about
looking at doing some kind of CRC on the gd struct (like the generated
asm-offsets), but I could not think of a way to do it)

Regards,

Graeme


More information about the U-Boot mailing list