Re: [PATCH v2 2/3] hw/mips/malta: Set PIIX4 IRQ routes in embedded bootloader

[Jiaxun Yang]

> 2022年11月22日 12:37，BALATON Zoltan <balaton@eik.bme.hu> 写道：
> 
> Hello,
> 
> On Mon, 21 Nov 2022, Bernhard Beschow wrote:
>> Am 21. November 2022 22:43:50 UTC schrieb "Philippe Mathieu-Daudé" 
>> <philmd@linaro.org>:
>>> On 21/11/22 16:34, Bernhard Beschow wrote:
>>>> Am 27. Oktober 2022 20:47:19 UTC schrieb "Philippe Mathieu-Daudé" 
>>>> <philmd@linaro.org>:
>>>>> Linux kernel expects the northbridge & southbridge chipsets
>>>>> configured by the BIOS firmware. We emulate that by writing
>>>>> a tiny bootloader code in write_bootloader().
>>>>> 
>>>>> Upon introduction in commit 5c2b87e34d ("PIIX4 support"),
>>>>> the PIIX4 configuration space included values specific to
>>>>> the Malta board.
>>>>> 
>>>>> Set the Malta-specific IRQ routing values in the embedded
>>>>> bootloader, so the next commit can remove the Malta specific
>>>>> bits from the PIIX4 PCI-ISA bridge and make it generic
>>>>> (matching the real hardware).
>>>>> 
>>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>>>> ---
>>>>> FIXME: Missing the nanoMIPS counter-part!
>>>> 
>>>> Who will be taking care of this? I have absolutely no clue how the 
>>>> write_bootloader functions work, so I don't see how to fix it.
>>> 
>>> Oh actually I wrote that and tested it but context switched and forgot
>>> about it... I'll look back when I get some time, probably around the
>>> release.

I can try to adopt existing boot loader helper functions, just a matter of 
opcodes I think.

> 
> Unrelated to this but found it while looking at malta.c now: another possible 
> clean up is to replace the local generate_eeprom_spd() func with 
> spd_data_generate() from hw/i2c/smbus_eeprom.c that other boards use already 
> but I did not change malta because I could not test it. If you can test malta 
> then it should be an easy change and simplify malta.c a bit.
> 
>>>> Couldn't we just do it like in pegasos2_init() where the registers are 
>>>> initialized by QEMU directly if there is no bootloader binary configured? 
>>>> I could do that.
>>> I rather mimic bootloaders... maybe a matter of taste?
> 
> Is that a bootloader or a replacement firmware? To me bootloader is some OS 
> specific binary that is loaded by firware to boot an OS. But there are OS 
> independent bootloaders like grub so maybe you could emulate something like 
> that, I don't know what malta does.

YAMON is a OS-dependent and HW-dependent firmware like u-boot.

> 
> If there's no firmware binary QEMU should provide something to replace it to 
> give the expected environment for the binary loaded by -kernel. In case of 
> pegasos2 the init method sets up regs to init devices as done by the firmware 
> and the rest is implemented by VOF (loaded from pc-bios) that provices the 
> OpenFirmware client interface. The device setup in init is needed because VOF 
> does not do that.
> 
>> I don't mind either way. I meant that I could help with the second approach 
>> but not with the current one since I have no clue whatsoever how it works. 
>> There are just too many magic constants that don't make any sense to me, and 
>> too many layers of indirection, for example.
> 
> If malta has a replacement firmware for this case maybe it could be stored in 
> a binary in pc-bios and loaded from there instead of writing it in hex to 
> guest memory. That binary could even be assembled from source which should 
> make it simpler to write and change. Or is YAMON open source? According to 
> this page it is: https://www.mips.com/develop/tools/boot-loaders/ so maybe it 
> could be included as a firmware binary instead of being emulated?

Hmm, YAMON was a open source software but I’m unable to find a copy of source 
for Malta board comes with GT chipset that QEMU emulated.
So nowadays we mainly use -kernel feature to do direct kernel boot.

Direct kernel boot is really a brilliant function that I don’t want to lose :-)

Thanks
- Jiaxun


> 
> Regards,
> BALATON Zoltan
> 
>> Anyway, I'm asking for the current state because I'm pretty much ready for 
>> posting a v3 of my PIIX consolidation series which now depends on this 
>> series.
>> 
>> Best regards,
>> Bernhard
>> 
>>> 
>>> Regards,
>>> 
>>> Phil.
>>