aboutsummaryrefslogtreecommitdiff
path: root/include/hw/ppc/ppc4xx.h
AgeCommit message (Collapse)Author
2022-10-28ppc4xx_sdram: Move ppc4xx_sdram_banks() to ppc4xx_sdram.cBALATON Zoltan
This function is only used by the ppc4xx memory controller models so it can be made static. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <b1504a82157a586aa284e8ee3b427b9a07b24169.1666194485.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_uc.c: Move some macros to ppc4xx.hBALATON Zoltan
These are used by both the SDRAM controller model and system DCRs. In preparation to move SDRAM controller in its own file move these macros to the ppc4xx.h header. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <74d9bf4891e2ccceb52bb6ca6b54fd3f37a9fb04.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_sdram: QOM'ifyBALATON Zoltan
Change the ppc440_sdram model to a QOM class derived from the PPC4xx-dcr-device and name it ppc4xx-sdram-ddr2. This is mostly modelling the DDR2 SDRAM controller found in the 460EX (used on the sam460ex board). Newer SoCs (regardless of their PPC core, e.g. 405EX) may have this controller but we only emulate enough of it for the sam460ex u-boot firmware. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <3e82ae575c7c41e464a0082d55ecb4ebcc4d4329.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Rename functions to prevent name clashesBALATON Zoltan
Rename functions to avoid name clashes when moving the DDR2 controller model currently called ppc440_sdram to ppc4xx_devs. This also more clearly shows which function belongs to which model. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <9c09d10fbf36940ebbe30d7038d69cf3f2e58371.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc440_sdram: Get rid of the init RAM hackBALATON Zoltan
Remove the do_init parameter of ppc440_sdram_init and enable SDRAM controller from the board. Firmware does this so it may only be needed when booting with -kernel without firmware but we enable SDRAM unconditionally to preserve previous behaviour. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <c2eda8f83c82f655aa7821a5a8c9310484bd6a1d.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: QOM'ifyBALATON Zoltan
Change the ppc4xx_sdram model to a QOM class derived from the PPC4xx-dcr-device and name it ppc4xx-sdram-ddr. This is mostly modelling the DDR SDRAM controller found in the 440EP (used on the bamboo board) but also backward compatible with the older DDR controllers on some 405 SoCs so we also use it for those now. This likely does not cause problems for guests we run as the new features are just not accessed but to model 405 SoC accurately some features may have to be disabled or the model split between 440 and older. Newer SoCs (regardless of their PPC core, e.g. 405EX) may have an updated DDR2 SDRAM controller implemented by the ppc440_sdram model (only partially, enough for the 460EX on the sam460ex) that is not yet QOM'ified in this patch. That is intended to become ppc4xx-sdram-ddr2 when QOM'ified later. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <8f820487fc9011343032c422ecdf3e8ee74d8c11.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Move size check to ppc4xx_sdram_init()BALATON Zoltan
Instead of checking if memory size is valid in board code move this check to ppc4xx_sdram_init() as this is a restriction imposed by the SDRAM controller. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <39e5129dd095b285676a6267c5753786da1bc30d.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx: Use Ppc4xxSdramBank in ppc4xx_sdram_banks()BALATON Zoltan
Change ppc4xx_sdram_banks() to take one Ppc4xxSdramBank array instead of the separate arrays and adjust ppc4xx_sdram_init() and ppc440_sdram_init() accordingly as well as machines using these. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <e3a1fea51f29779fd6a61be90a29c684f3299544.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx_sdram: Get rid of the init RAM hackBALATON Zoltan
The do_init parameter of ppc4xx_sdram_init() is used to map memory regions that is normally done by the firmware by programming the SDRAM controller. Do this from board code emulating what firmware would do when booting a kernel directly from -kernel without a firmware so we can get rid of this do_init hack. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <d6c44c870befa1a075e21f1a59926dcdaff63f6b.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-10-17ppc4xx: Introduce Ppc4xxSdramBank structBALATON Zoltan
Instead of storing sdram bank parameters in unrelated arrays put them in a struct so it's clear they belong to the same bank and simplify the state struct using this bank type. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <5eb82d0424c584b2b9e6f7bc51560f8189ed21bb.1664021647.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Rename ppc405-ebc to ppc4xx-ebcBALATON Zoltan
This device is shared between different 4xx socs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <63d9b14c8ff5f73e35bffca1036394b5235735ee.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Move EBC model to ppc4xx_devs.cBALATON Zoltan
The EBC is shared between 405 and 440 so move it to shared file. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <10eae70509ca4bd74858fc2c0a0f0e4eb9330199.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Rename ppc405-plb to ppc4xx-plbBALATON Zoltan
This device is shared between different 4xx socs. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <5b13ebfd12a71a28035bed5a915cbeee81cf21d1.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc4xx: Move PLB model to ppc4xx_devs.cBALATON Zoltan
The PLB is shared between 405 and 440 so move it to the shared file. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <2498384bf3e18959ee8cb984d72fb66b8a6ecadc.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc405: QOM'ify MALCédric Le Goater
The Memory Access Layer (MAL) controller is currently modeled as a DCR device with 4 IRQs. Also drop the ppc4xx_mal_init() helper and adapt the sam460ex machine. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: ppc4xx_dcr_register changes, add finalize method] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <d54a243dff94d95ba30dbcc09c27700a90ade932.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc4xx: Introduce a DCR device modelCédric Le Goater
The Device Control Registers (DCR) of on-SoC devices are accessed by software through the use of the mtdcr and mfdcr instructions. These are converted in transactions on a side band bus, the DCR bus, which connects the on-SoC devices to the CPU. Ideally, we should model these accesses with a DCR namespace and DCR memory regions but today the DCR handlers are installed in a DCR table under the CPU. Instead, introduce a little device model wrapper to hold a CPU link and handle registration of DCR handlers. The DCR device inherits from SysBus because most of these devices also have MMIO regions and/or IRQs. Being a SysBusDevice makes things easier to install the device model in the overall SoC. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> [balaton: Explicit opaque parameter for dcr callbacks] Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <9b21bdf55e0a728f093bad299e030d98f302ded0.1660746880.git.balaton@eik.bme.hu> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2022-08-31ppc/ppc405: QOM'ify CPUCédric Le Goater
Drop the use of ppc4xx_init() and duplicate a bit of code related to clocks in the SoC realize routine. We will clean that up in the following patches. ppc_dcr_init() simply allocates default DCR handlers for the CPU. Maybe this could be done in model initializer of the CPU families needing it. Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20220809153904.485018-8-clg@kaod.org> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2021-01-19hw/ppc: Remove unused ppcuic_init()Peter Maydell
Now we've converted all the callsites to directly create the QOM UIC device themselves, the ppcuic_init() function is unused and can be removed. The enum defining PPCUIC symbolic constants can be moved to the ppc-uic.h header where it more naturally belongs. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Message-Id: <20210108171212.16500-5-peter.maydell@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-02-19ppc/{ppc440_bamboo, sam460ex}: use memdev for RAMIgor Mammedov
memory_region_allocate_system_memory() API is going away, so replace it with memdev allocated MemoryRegion. The later is initialized by generic code, so board only needs to opt in to memdev scheme by providing MachineClass::default_ram_id and using MachineState::ram instead of manually initializing RAM memory region. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200219160953.13771-67-imammedo@redhat.com>
2020-02-19ppc/{ppc440_bamboo, sam460ex}: drop RAM size fixupIgor Mammedov
If user provided non-sense RAM size, board will complain and continue running with max RAM size supported or sometimes crash like this: %QEMU -M bamboo -m 1 exec.c:1926: find_ram_offset: Assertion `size != 0' failed. Aborted (core dumped) Also RAM is going to be allocated by generic code, so it won't be possible for board to fix things up for user. Make it error message and exit to force user fix CLI, instead of accepting non-sense CLI values. That also fixes crash issue, since wrongly calculated size isn't used to allocate RAM Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: BALATON Zoltan <balaton@eik.bme.hu> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20200219160953.13771-66-imammedo@redhat.com>
2019-08-16Clean up inclusion of exec/cpu-common.hMarkus Armbruster
migration/qemu-file.h neglects to include it even though it needs ram_addr_t. Fix that. Drop a few superfluous inclusions elsewhere. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-14-armbru@redhat.com>
2019-08-16include: Make headers more self-containedMarkus Armbruster
Back in 2016, we discussed[1] rules for headers, and these were generally liked: 1. Have a carefully curated header that's included everywhere first. We got that already thanks to Peter: osdep.h. 2. Headers should normally include everything they need beyond osdep.h. If exceptions are needed for some reason, they must be documented in the header. If all that's needed from a header is typedefs, put those into qemu/typedefs.h instead of including the header. 3. Cyclic inclusion is forbidden. This patch gets include/ closer to obeying 2. It's actually extracted from my "[RFC] Baby steps towards saner headers" series[2], which demonstrates a possible path towards checking 2 automatically. It passes the RFC test there. [1] Message-ID: <87h9g8j57d.fsf@blackfin.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03345.html [2] Message-Id: <20190711122827.18970-1-armbru@redhat.com> https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg02715.html Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-2-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-02-04ppc4xx: Use ram_addr_t in ppc4xx_sdram_adjust()BALATON Zoltan
To avoid overflow if larger values are added later use ram_addr_t for the sdram_bank_sizes parameter to match ram_size to which it is compared. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2018-05-20trivial: Do not include pci.h if it is not necessaryThomas Huth
There is no need to include pci.h in these files. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-09-08ppc4xx: Make MAL emulation more genericBALATON Zoltan
Allow MAL with more RX and TX channels as found in newer versions. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2017-09-08ppc4xx: Move MAL from ppc405_uc to ppc4xx_devsBALATON Zoltan
This device appears in other SoCs as well not just in 405 ones Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2016-09-15Remove unused function declarationsLadi Prosek
Unused function declarations were found using a simple gcc plugin and manually verified by grepping the sources. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2016-07-12Clean up header guards that don't match their file nameMarkus Armbruster
Header guard symbols should match their file name to make guard collisions less likely. Offenders found with scripts/clean-header-guards.pl -vn. Cleaned up with scripts/clean-header-guards.pl, followed by some renaming of new guard symbols picked by the script to better ones. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
2013-04-08hw: move headers to include/Paolo Bonzini
Many of these should be cleaned up with proper qdev-/QOM-ification. Right now there are many catch-all headers in include/hw/ARCH depending on cpu.h, and this makes it necessary to compile these files per-target. However, fixing this does not belong in these patches. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>