Re: why doesn't arm virt machine boot linux when uart address size is increased?

[Peter Maydell]

On Mon, 12 Apr 2021 at 10:02, <ckim@etri.re.kr> wrote:
> Earlier, I have copied the arm/virt machine and named it ab21q.
>
> I changed the memory map of ab21q to match our system (under development).
>
> Among others the original UART address/size was changed from {0x09000000, 
> 0x1000} to {0x10210000, 0xf000}. (the numbers were given to me)
>
> I checked a couple of baremetal programs run ok on the new machine.
>
> But when I tried running linux on ab21q this morning, the linux kernel didn’t 
> to the shell prompt.

I have no idea what other changes you've made on this
frankenstein board, but at least for the upstream 'virt' board
this address is already in use (it's in the middle of the PCI controller).

> I am curious about what mechanism is preventing it from booting when the UART 
> address space size is bigger than necessary and also what the kernel is doing 
> during the 3~4 seconds after the end of start_kernel function and printing 
> “Booting from ..” message.

If the kernel crashes or panics in early bootup then it doesn't always
get the chance to print the logging it does. In a normally configured
kernel, log messages are stored to a buffer, and then when the console
device is initialised (which happens fairly late on) the contents of
the buffer are all printed out at once. This is probably what your
delay is: the kernel is booting, but hasn't yet got to a point of
being able to output to the console.

You can tell the kernel to make special efforts to print early log
messages, which will allow you to read what it's doing before it
crashes. To do this you add "earlycon" to the kernel command line
(the kernel needs SERIAL_AMBA_PL011_CONSOLE enabled for a PL011 UART
which the virt board has; other UART types have different config
option names).

Of course, if the reason the kernel is failing to boot is because
the UART itself is not where the kernel expects then you won't get
any console output and you'll have to debug the kernel boot by hand
the same way you would for hardware kernel bring-up.

thanks
-- PMM