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

[Philippe Mathieu-Daudé]

On 4/13/21 2:40 PM, ckim@etri.re.kr wrote:
> Hi Peter Maydell,
> Thanks again. It's still not clear why increasing the UART address size to 
> 0x2000 makes it stall, 

You might look for memory region overlap in the monitor using
'info mtree' and 'info mtree -f' for the flatview (where overlap
can't exist).

> But at least with the 'earlycon' command, I think I can later figure it out. 
> (this will be helpful for analysis)
> Thank you!
> Chan Kim
> 
>> -----Original Message-----
>> From: Peter Maydell <peter.maydell@linaro.org>
>> Sent: Monday, April 12, 2021 6:39 PM
>> To: Chan Kim <ckim@etri.re.kr>
>> Cc: qemu-discuss <qemu-discuss@nongnu.org>
>> Subject: Re: why doesn't arm virt machine boot linux when uart address
>> size is increased?
>>
>> 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