Hi,
On 10-01-15 11:50, Ian Campbell 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.
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.
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).
Correct, bootm_size used to be 0x10000000 to match the 256M RAM minimum
we've to deal with. Recently it changed to 0x0f000000 to deal with the
framebuffer being shaven of the top of RAM, that reserves 16M, but
the framebuffer is only 9M, so we could easily but the pre-console
buffer at 0x0f000000, that will work for all boards, and won't conflict
with the framebuffer.
So I suggest just putting it at 0x0f000000 until the time comes when
someone adds support for making it dynamic as Simon suggested.
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.
See above, there is room after the 0x0f000000 for 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.
Correct.
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 (it's not totally inconceivable that a kernel might be
approaching ~15M in size)
Agreed, as said I think the 7M hole between bootm_size and the framebuffer
is ideal, note the whole is much much bigger on boards with more then 256M
RAM, but less assume the worst case here.
Regards,
Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
