Re: Deprecate the ppc405 boards in QEMU?

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 10/19/21 13:11, Thomas Huth wrote:
> On 19/10/2021 12.07, BALATON Zoltan wrote:
>> On Tue, 19 Oct 2021, Christophe Leroy wrote:
>>> Le 19/10/2021 à 11:39, Thomas Huth a écrit :
>>>> On 19/10/2021 11.31, Christophe Leroy wrote:
>>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit :
>>>>>> On 11/10/2021 11.20, David Gibson wrote:
>>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote:
>>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote:
>>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote:
>>>>>>>>> [...]
>>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware
>>>>>>>>>> where the
>>>>>>>>>> memory detection was patched out but it seems to detect the
>>>>>>>>>> RAM so I
>>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM
>>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure
>>>>>>>>>> what
>>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe
>>>>>>>>>> for the speed calibration, so could be it detects ram by reading
>>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as
>>>>>>>>>> i2c is
>>>>>>>>>> not emulated on taihu. This could be confirmed by checking
>>>>>>>>>> what it
>>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices
>>>>>>>>>> but don't know where 405 has the i2c controller and if it's
>>>>>>>>>> the same
>>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be
>>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy
>>>>>>>>>> or you
>>>>>>>>>> could skip this in u-boot.
>>>>>>>>>
>>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in
>>>>>>>>> u-boot),
>>>>>>>>> and indeed, I can get to the u-boot prompt now.
>>>>>>>> [...]> I've also attached the patch with my modifications to
>>>>>>>> u-boot.
>>>>>>>>
>>>>>>>> FYI, the changes can now be found on this branch here:
>>>>>>>>
>>>>>>>>   https://gitlab.com/huth/u-boot/-/commits/taihu
>>>>>>>>
>>>>>>>> I also added a gitlab-CI file, so you can now download the
>>>>>>>> u-boot.bin as an
>>>>>>>> artifact from the corresponding pipeline, e.g.:
>>>>>>>>
>>>>>>>>   https://gitlab.com/huth/u-boot/-/jobs/1667201028
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> Are you going to send a v2 of your proposed deprecation patches?
>>>>>>
>>>>>> No, since there was interest in keeping the 405 boards for testing
>>>>>> the 405 code in the Linux kernel, and since there is now a way to
>>>>>> do at least some very basic testing of these boards (with the
>>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I
>>>>>> just sent a patch for adding the boards to our CI instead:
>>>>>>
>>>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html
>>>>>>
>>>>>
>>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0
>>>>> and mainline, and I get:
>>>>>
>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt:
>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>> Bail out!
>>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt:
>>>>> assertion failed: (qemu_mutex_iothread_locked())
>>>>> Abandon (core dumped)
>>>>>
>>>>> I see in the mail history that you got that problem as well at some
>>>>> point. How did you fix it ?
>>>>
>>>> You need this patch here to fix this issue:
>>>>
>>>>   https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html
>>>>   ("hw/ppc: Fix iothread locking in the 405 code")
>>>>
>>>
>>> Thank you.
>>>
>>> Is there anything special to do then in order to boot a Linux kernel ?
>>>
>>> I build the uImage for ppc40x_defconfig
>>>
>>> I use the following command, but it does nothing, it stays in uboot
>>> prompt as when I don't get a kernel argument
>>>
>>>     ~/qemu/build/qemu-system-ppc -M taihu -bios
>>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel
>>> arch/powerpc/boot/uImage
>>
>> I'm not sure using -bios and -kernel together makes sense, it probably
>> starts u-boot in this case and you have to load and start the kernel
>> from u-boot as you'd notmally do on a real machine. Alternatively you
>> could use -kernel instead of -bios which then loads a kernel and
>> starts it directly but not sure if it needs a firmware to work.
>>
>> Ot I could be completely wrong as I don't know this machine and
>> haven't tried it.
> 
> Actually, these 405 machines are quite weird. They refuse to boot
> without bios image, so you currently need the firmware image for sure.

When using -kernel/-append, if a BIOS is required by the kernel,
then it should be crafted by the machine IMO. Usually OS only
access a configuration area in PROM. The PROM must be mapped,
and the minimum configuration structure filled.

Anyhow I find -bios confusing, I never know if this option parse
or expects a full/partial raw flash image, an ELF image, something
else...