Re: [PATCH 15/15] ppc/ppc405: Update U-Boot board information for hotfoot

["Cédric Le Goater" <clg@kaod.org>]

On 12/6/21 14:40, Thomas Huth wrote:
> On 06/12/2021 14.37, Cédric Le Goater wrote:
>> On 12/6/21 14:27, Philippe Mathieu-Daudé wrote:
>>> On 12/6/21 11:37, Cédric Le Goater wrote:
>>>> When support for the ESTeem 195E (PPC405EP) SBC (hotfoot) board was
>>>> added to Linux, a different layout of U-Boot board information was
>>>> introduced because the FW of these boards was an ancient U-Boot
>>>> without dual ethernet support [1].
>>>>
>>>> Change the QEMU PPC405 board information to match the hotfoot board
>>>> and let the ref405ep machine boot from Linux directly. Only the CPU
>>>> frequency is required.
>>>>
>>>> This is brutal force. We could possibly add a machine option or a
>>>> ref405ep machine class to update the board information accordingly.
>>>>
>>>> A similar change would be required in U-Boot. The alternative is to
>>>> change Linux.
>>>>
>>>> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074487.html
>>>>
>>>> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
>>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>>> ---
>>>>   hw/ppc/ppc405_uc.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>>>>   1 file changed, 45 insertions(+)
>>>>
>>>> diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
>>>> index ec97b22bd019..649bb2b0daf5 100644
>>>> --- a/hw/ppc/ppc405_uc.c
>>>> +++ b/hw/ppc/ppc405_uc.c
>>>> @@ -41,6 +41,49 @@
>>>>   #include "qapi/error.h"
>>>>   #include "trace.h"
>>>> +/*
>>>> + * Linux hotfoot board information based on a production bootloader
>>>> + * (u-boot 1.2.0.x) plus changes not upstream.
>>>> + *
>>>> + * https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074487.html
>>>> + */
>>>> +struct linux_hotfoot_bd_info {
>>>> +    long unsigned int          bi_memstart;          /*     0     4 */
>>>> +    long unsigned int          bi_memsize;           /*     4     4 */
>>>> +    long unsigned int          bi_flashstart;        /*     8     4 */
>>>> +    long unsigned int          bi_flashsize;         /*    12     4 */
>>>> +    long unsigned int          bi_flashoffset;       /*    16     4 */
>>>> +    long unsigned int          bi_sramstart;         /*    20     4 */
>>>> +    long unsigned int          bi_sramsize;          /*    24     4 */
>>>> +    long unsigned int          bi_bootflags;         /*    28     4 */
>>>> +    long unsigned int          bi_ip_addr;           /*    32     4 */
>>>> +    unsigned char              bi_enetaddr[6];       /*    36     6 */
>>>> +    unsigned char              bi_enet1addr[6];      /*    42     6 */
>>>> +    short unsigned int         bi_ethspeed;          /*    48     2 */
>>>> +    long unsigned int          bi_intfreq;           /*    52     4 */
>>>> +    long unsigned int          bi_busfreq;           /*    56     4 */
>>>> +    long unsigned int          bi_baudrate;          /*    60     4 */
>>>> +    unsigned char              bi_s_version[4];      /*    64     4 */
>>>> +    unsigned char              bi_r_version[32];     /*    68    32 */
>>>> +    unsigned int               bi_procfreq;          /*   100     4 */
>>>> +    unsigned int               bi_plb_busfreq;       /*   104     4 */
>>>> +    unsigned int               bi_pci_busfreq;       /*   108     4 */
>>>> +    unsigned char              bi_pci_enetaddr[6];   /*   112     6 */
>>>> +    unsigned int               bi_pllouta_freq;      /*   120     4 */
>>>> +    int                        bi_phynum[2];         /*   124     8 */
>>>> +    int                        bi_phymode[2];        /*   132     8 */
>>>> +    unsigned int               bi_opbfreq;           /*   140     4 */
>>>> +    int                        bi_iic_fast[2];       /*   144     8 */
>>>> +};
>>>
>>> Why not use <stdint.h> types?
>>
>> sure.
>>
>> I am waiting for some feedback on this hack updating the in-memory
>> board information. I have the feeling that a new 405 machine
>> is required for this kernel :/
> 
> Yeah, it feels rather wrong to bend the ref405ep machine to match the hotfoot expectations of the kernel this way ... maybe it would be better to add an abstract qemu405 machine to the kernel?

Yes. I prepared that but then I realized that the QEMU board information
layout assigned (luckily) the CPU clock to 33 Mhz and not 0 like U-Boot
did. This structure is completely out of sync :/

Anyhow, the ref405ep machine can boot with a hotfoot Linux kernel without
having to patch the board information. We might merge a ref405ep-hotfoot
machine for the sake of clarity since it is a small and well contained
extension and the machine boots faster.

We still have a user space issue when forking processes. But that's
Christophe's turf.

Thanks,

C.