| Message ID | 20211206103712.1866296-16-clg@kaod.org |
|---|---|
| State | New |
| Headers | show |
| Series | ppc/ppc405: decade cleanup | expand |
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?
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.
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
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 --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; }
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(+)