| Message ID | 20220808102734.133084-1-clg@kaod.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | ppc: QOM'ify 405 board | expand |
On Mon, 8 Aug 2022, Cédric Le Goater wrote: > Hello, > > Here is large series QOM'ifying the PPC405 board. It introduces a new > generic machine and SoC models, converts the current device models to > QOM and populates the SoC. The process is quite mechanical without too > much issues to handle. The noisy part is the initial patch introducing > the SoC realize routine. > > What's left ? > > * the SDRAM mappings are very baroque and certainly could be simplified. > I think we should QOMify the ppc440 machines before addressing this > part. The issue with SDRAM controller and the likely reason why its model looks so complex is that it can't handle any RAM size because of how the bank sizes are encoded in the registers so it only really supports real RAM modules which are predefined sizes. Also the firmware discovers RAM by looking at SPD data and may only check the slots that the real hardware has which may not be the first one. Previously I had code to round down the memory size specified on the command line to an acceptable size and issue a warning to let the user know but this was dropped because of some changes in code elsewhere which now allocates memory before the machine could check and ajust it so we can only adjust it by wasting some. Take this into account and check the ppc4xx_sdram_banks() function and 440 machines before changing this. Regards, BALATON Zoltan > Thanks, > > C. > > Changes in v3 : > > - New device model Ppc4xxDcrDeviceState > - Removal of ppc4xx_mal_init(), ppc4xx_plb_init() and ppc405_ebc_init() > - Fixes for some reset issues > - Kept 2 RAM banks at the Soc level but only one is initialized. > - Moved SRAM under the machine. It's not part of the SoC according > to the 405 specs > > Changes in v2 : > > - docs/about/removed-features.rst update > - Fix compile breakage (uic) > - Fix CPU reset, which breaking u-boot boot > - Changed prefix of memory regions to "ppc405" > - Reduced the number of RAM banks to 1. Second was a dummy one to > please ppc405ep_init() > > Cédric Le Goater (22): > ppc/ppc405: Remove taihu machine > ppc/ppc405: Introduce a PPC405 generic machine > ppc/ppc405: Move devices under the ref405ep machine > ppc/ppc405: Move SRAM under the ref405ep machine > ppc/ppc405: Introduce a PPC405 SoC > ppc/ppc405: Start QOMification of the SoC > ppc/ppc405: QOM'ify CPU > ppc/ppc4xx: Introduce a DCR device model > ppc/ppc405: QOM'ify CPC > ppc/ppc405: QOM'ify GPT > ppc/ppc405: QOM'ify OCM > ppc/ppc405: QOM'ify GPIO > ppc/ppc405: QOM'ify DMA > ppc/ppc405: QOM'ify EBC > ppc/ppc405: QOM'ify OPBA > ppc/ppc405: QOM'ify POB > ppc/ppc405: QOM'ify PLB > ppc/ppc405: QOM'ify MAL > ppc/ppc405: QOM'ify FPGA > ppc/ppc405: Use an explicit PPCUIC object > ppc/ppc405: Use an explicit I2C object > ppc/ppc4xx: Fix sdram trace events > > docs/about/deprecated.rst | 9 - > docs/about/removed-features.rst | 6 + > docs/system/ppc/embedded.rst | 1 - > hw/ppc/ppc405.h | 198 +++++++- > include/hw/ppc/ppc4xx.h | 48 +- > hw/ppc/ppc405_boards.c | 375 ++++----------- > hw/ppc/ppc405_uc.c | 828 +++++++++++++++++--------------- > hw/ppc/ppc4xx_devs.c | 184 ++++--- > hw/ppc/sam460ex.c | 24 +- > MAINTAINERS | 2 +- > 10 files changed, 903 insertions(+), 772 deletions(-) > >
On 8/8/22 14:16, BALATON Zoltan wrote: > On Mon, 8 Aug 2022, Cédric Le Goater wrote: >> Hello, >> >> Here is large series QOM'ifying the PPC405 board. It introduces a new >> generic machine and SoC models, converts the current device models to >> QOM and populates the SoC. The process is quite mechanical without too >> much issues to handle. The noisy part is the initial patch introducing >> the SoC realize routine. >> >> What's left ? >> >> * the SDRAM mappings are very baroque and certainly could be simplified. >> I think we should QOMify the ppc440 machines before addressing this >> part. > > The issue with SDRAM controller and the likely reason why its model looks so complex is that it can't handle any RAM size because of how the bank sizes are encoded in the registers so it only really supports real RAM modules which are predefined sizes. Also the firmware discovers RAM by looking at SPD data and may only check the slots that the real hardware has which may not be the first one. > > Previously I had code to round down the memory size specified on the command line to an acceptable size and issue a warning to let the user know but this was dropped because of some changes in code elsewhere which now allocates memory before the machine could check and ajust it so we can only adjust it by wasting some. I don't think we should care adjusting the values. the machine init routine should check that the RAM size is valid or fail. The machine should also have a sane RAM size value by default. See how the aspeed machine deals with similar constraints of its SDRAM controller in aspeed_machine_init(). If the sdram controller does not validate the RAM size, aspeed_sdmc_set_ram_size() fails with an error. C. > Take this into account and check the ppc4xx_sdram_banks() function and 440 machines before changing this. > > Regards, > BALATON Zoltan > > >> Thanks, >> >> C. >> >> Changes in v3 : >> >> - New device model Ppc4xxDcrDeviceState >> - Removal of ppc4xx_mal_init(), ppc4xx_plb_init() and ppc405_ebc_init() >> - Fixes for some reset issues >> - Kept 2 RAM banks at the Soc level but only one is initialized. >> - Moved SRAM under the machine. It's not part of the SoC according >> to the 405 specs >> >> Changes in v2 : >> >> - docs/about/removed-features.rst update >> - Fix compile breakage (uic) >> - Fix CPU reset, which breaking u-boot boot >> - Changed prefix of memory regions to "ppc405" >> - Reduced the number of RAM banks to 1. Second was a dummy one to >> please ppc405ep_init() >> >> Cédric Le Goater (22): >> ppc/ppc405: Remove taihu machine >> ppc/ppc405: Introduce a PPC405 generic machine >> ppc/ppc405: Move devices under the ref405ep machine >> ppc/ppc405: Move SRAM under the ref405ep machine >> ppc/ppc405: Introduce a PPC405 SoC >> ppc/ppc405: Start QOMification of the SoC >> ppc/ppc405: QOM'ify CPU >> ppc/ppc4xx: Introduce a DCR device model >> ppc/ppc405: QOM'ify CPC >> ppc/ppc405: QOM'ify GPT >> ppc/ppc405: QOM'ify OCM >> ppc/ppc405: QOM'ify GPIO >> ppc/ppc405: QOM'ify DMA >> ppc/ppc405: QOM'ify EBC >> ppc/ppc405: QOM'ify OPBA >> ppc/ppc405: QOM'ify POB >> ppc/ppc405: QOM'ify PLB >> ppc/ppc405: QOM'ify MAL >> ppc/ppc405: QOM'ify FPGA >> ppc/ppc405: Use an explicit PPCUIC object >> ppc/ppc405: Use an explicit I2C object >> ppc/ppc4xx: Fix sdram trace events >> >> docs/about/deprecated.rst | 9 - >> docs/about/removed-features.rst | 6 + >> docs/system/ppc/embedded.rst | 1 - >> hw/ppc/ppc405.h | 198 +++++++- >> include/hw/ppc/ppc4xx.h | 48 +- >> hw/ppc/ppc405_boards.c | 375 ++++----------- >> hw/ppc/ppc405_uc.c | 828 +++++++++++++++++--------------- >> hw/ppc/ppc4xx_devs.c | 184 ++++--- >> hw/ppc/sam460ex.c | 24 +- >> MAINTAINERS | 2 +- >> 10 files changed, 903 insertions(+), 772 deletions(-) >> >>
On Mon, 8 Aug 2022, Cédric Le Goater wrote: > On 8/8/22 14:16, BALATON Zoltan wrote: >> On Mon, 8 Aug 2022, Cédric Le Goater wrote: >>> Hello, >>> >>> Here is large series QOM'ifying the PPC405 board. It introduces a new >>> generic machine and SoC models, converts the current device models to >>> QOM and populates the SoC. The process is quite mechanical without too >>> much issues to handle. The noisy part is the initial patch introducing >>> the SoC realize routine. >>> >>> What's left ? >>> >>> * the SDRAM mappings are very baroque and certainly could be simplified. >>> I think we should QOMify the ppc440 machines before addressing this >>> part. >> >> The issue with SDRAM controller and the likely reason why its model looks >> so complex is that it can't handle any RAM size because of how the bank >> sizes are encoded in the registers so it only really supports real RAM >> modules which are predefined sizes. Also the firmware discovers RAM by >> looking at SPD data and may only check the slots that the real hardware has >> which may not be the first one. >> Previously I had code to round down the memory size specified on the >> command line to an acceptable size and issue a warning to let the user know >> but this was dropped because of some changes in code elsewhere which now >> allocates memory before the machine could check and ajust it so we can only >> adjust it by wasting some. > > I don't think we should care adjusting the values. the machine init > routine should check that the RAM size is valid or fail. The machine > should also have a sane RAM size value by default. > > See how the aspeed machine deals with similar constraints of its SDRAM > controller in aspeed_machine_init(). If the sdram controller does not > validate the RAM size, aspeed_sdmc_set_ram_size() fails with an error. Even then we need to check if the specified memory matches one of the allowed sized and distribute it to the allowed banks by the soc. This code is more complex than the 405ep has currently and should not be reprated in each board. That's why we have the ppc4xx_memory_banks and sdram_init functions so while it may be possible to simmplify it a bit maybe not much. I've spent quite some time with it so if you change it check that at least sam360ex -m 2G still works. Regards, BALATON Zoltan