Hi, On 10 January 2015 at 03:50, Ian Campbell <i...@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. >> >> 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). > > 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. > >> 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. > > 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)
I don't think it is a good idea to use the 'pre-console buffer' after the console exists. It is a misnomer. Also, the reason that the pre-console buffer has pre-allocated memory is to work around the lack of memory allocation before relocation. Now that we have initf_mallloc() called very early in boot we could consider allocating the space instead. I think this patch is a good feature to implement, but I agree with others that hard-coded memory locations for U-Boot features should not exist except in exceptional circumstances (e.g. very early boot). Re passing the U-Boot console to the kernel, see as an example the cbmem_console.c driver. It only works on x86 at present and only with coreboot. It works as a stdio driver, so skips the first part of U-Boot's output. So I suggest: 1. Remove the pre-console address and just have a size. Allocate the space after initf_malloc(). Store the details (buffer start, size and current pointer) in global_data 2. Add a general mechanism to record the console into a buffer by renaming and adjusting the existing code. It can then be set up pre-console, post-console but pre-stdio, and then post-stdio for recording what is passed to Linux. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot