Le 15/12/2021 à 17:49, Cédric Le Goater a écrit :
> On 12/6/21 11:36, Cédric Le Goater wrote:
>> Hello,
>>
>> The goal of these changes is to refresh the QEMU ref405ep machine and
>> enable boot from a Linux kernel without relying on a U-Boot firmware.
>> The reason for doing so is that we are unable to find a "ppc405_rom.bin"
>> firmware image or a flash image for the 405EP machines.
>>
>> Thomas fought is way through on a v2015.10 U-Boot and taihu defconfig
>> and provided a compatible image available here :
>>
>> https://gitlab.com/huth/u-boot/-/tree/taihu/
>>
>> With this image, QEMU reaches the U-Boot prompt (with a simple
>> workaround in the SDRAM).
>>
>> On the Linux side, the only available 405EP CPU board is the one for
>> the ESTeem 195E (PPC405EP) SBC (hotfoot). It was added in 2009. The
>> board information structure in Linux, in U-Boot and in QEMU are not in
>> sync and the hotfoot board also adds its own flavor because the FW was
>> an ancient U-Boot without dual ethernet support [1].
>>
>> For this kernel to be loaded by the U-Boot image provided by Thomas,
>> we either need to modify U-Boot or Linux. The same question arise for
>> QEMU, see the last patch of this series which is controversial. Please
>> advise !
>
> Applied patch 1-14 to ppc-next.
>
> I kept the hotfoot hack for later. We need to fix user space first.
>
Don't know if this is the reason of our problems but I think there is
something to investigate around timer interrupts:
/ # cat /proc/interrupts
CPU0
16: 68 UIC 1 Level serial
LOC: 0 Local timer interrupts for timer event device
LOC: 0 Local timer interrupts for others
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
MCE: 0 Machine check exceptions
Any idea what the problem can be ? How does QEMU generates timer
interrupts ?
Christophe
