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.

Regards,
BALATON Zoltan