diff mbox series

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

Message ID 20211206103712.1866296-16-clg@kaod.org (mailing list archive)
State New, archived
Headers show
Series ppc/ppc405: decade cleanup | expand

Commit Message

Cédric Le Goater Dec. 6, 2021, 10:37 a.m. UTC
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(+)

Comments

Philippe Mathieu-Daudé Dec. 6, 2021, 1:27 p.m. UTC | #1
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?
Cédric Le Goater Dec. 6, 2021, 1:37 p.m. UTC | #2
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 :/

Thanks,

C.
Thomas Huth Dec. 6, 2021, 1:40 p.m. UTC | #3
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?

  Thomas
Cédric Le Goater Dec. 6, 2021, 3:20 p.m. UTC | #4
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.
diff mbox series

Patch

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 */
+};
+
+static void ppc405_fixup_bootinfo(CPUState *cs, ppc4xx_bd_info_t *bd,
+                                  ram_addr_t bdloc)
+{
+    stl_be_phys(cs->as,
+                bdloc + offsetof(struct linux_hotfoot_bd_info, bi_procfreq),
+                bd->bi_procfreq);
+}
+
 static void ppc405_set_default_bootinfo(ppc4xx_bd_info_t *bd,
                                         ram_addr_t ram_size)
 {
@@ -119,6 +162,8 @@  static ram_addr_t __ppc405_set_bootinfo(CPUPPCState *env, ppc4xx_bd_info_t *bd)
         n += 4;
     }
 
+    ppc405_fixup_bootinfo(cs, bd, bdloc);
+
     return bdloc;
 }