[U-Boot] [PATCH 2/2] sunxi: Enable pre-console buffer

[Siarhei Siamashka]

On Sat, 10 Jan 2015 10:50:05 +0000
Ian Campbell <ijc at hellion.org.uk> wrote:
> On Fri, 2015-01-09 at 13:13 +0200, Siarhei Siamashka wrote:
> > > If yes then I think it is confusing to modify this comment, and the
> > > comment before the pre-console #defines should mention that the buffer
> > > is boottime only/short lived etc.

First of all, I apologise for my earlier misleading comment about the
buffer life time.

In the FEL boot mode, the kernel and other things are uploaded to RAM
even before u-boot starts. So being short lived does not make any
difference. If the pre-console buffer is used, then it unconditionally
needs its own dedicated memory area, which does not overlap with
anything else.

> > Just in case if something goes really wrong (in theory it shouldn't,
> > but in practice you know...) it is still somewhat safer to keep the
> > buffer in its own dedicated area and keep everything else out.
> 
> Nothing in those defines is protecting anything though, if the kernel is
> more than 15M it will still overwrite that area.

If the kernel is more than 16M, then the defines do not protect anyone
either. And the situation is not very much different from 15M kernel
size limit. Both are just arbitrarily chosen numbers, which are
likely expected to be large enough (preferably several times larger
than the largest typical kernel).

This part of sunxi-common.h header only serves as the address space
layout documentation (given that no better documentation exists).
If a user has violated the rules and placed some important data
where he shouldn't, then it is reasonable to expect troubles.

> > > Perhaps a better place for the pre-console buffer would be right before
> > > the framebuffer (or at the top of RAM if no video on the board), with
> > > modifications to bootm_size or not depending on the answer to the
> > > original question above.
> > 
> > If this needs any kind of runtime address calculations instead of
> > compile time constants, then IMHO it becomes unnecessarily complicated.
> 
> One for Hans I think, my understanding was that the framebuffer was at
> the top of RAM, but having bootm_size set to 0xf0000000 unconditionally
> doesn't match that. I suppose the idea is that it corresponds with the
> smallest board because it's not worth making it dynamic (I think I
> recall Hans saying something like that at the time).
> 
> I think you could safely put the early buffer at 0xf000000-DELTA (and
> adjust bootm_size to match), rather than worrying about packing it up
> below the real framebuffer.

Right. It's one of the possible ways to do it.

> > Anyway. The sunxi part of these changes just needs to assign some
> > memory area to the pre-console buffer. In the end it does not really
> > matter which one. The size also does not need to be too large.
> > For example 1920 * 1080 / (8 * 16) = 16200. It means that only ~16K
> > of the log buffer can fully cover the FullHD display using the 8x16
> > font. And this is even assuming no line breaks. I picked 1M only
> > because it was the smallest unit of the address space allocation in
> > sunxi-common.h :-)
> 
> I don't think it needs to be allocated in 1M chunks, it just happens to
> have been arbitrarily chosen that way so far.

Yes, I just followed this arbitrarily chosen convention.

> If you want to keep the early buffer down in that region then I think
> it'd be better to steal a few KB from the end of the fdt, script or pxe
> (all of which will never be anywhere near 1MB) than stealing 1M off the
> end of the kernel

Right. It's one of the possible ways to do it.

> (it's not totally inconceivable that a kernel might be approaching ~15M
> in size)

To me this sounds like the existing 16M kernel reservation area is
insufficient. And may need to be increased in order to provide enough
headroom.

-- 
Best regards,
Siarhei Siamashka