On Thu, 6 Feb 2025, Bernhard Beschow wrote:
Am 2. Februar 2025 01:25:22 UTC schrieb BALATON Zoltan <bala...@eik.bme.hu>:On Sat, 1 Feb 2025, Bernhard Beschow wrote:Am 1. Februar 2025 14:55:15 UTC schrieb Bernhard Beschow <shen...@gmail.com>:Am 30. Januar 2025 12:45:58 UTC schrieb BALATON Zoltan <bala...@eik.bme.hu>:On Wed, 15 Jan 2025, BALATON Zoltan wrote:This allows guests to set the CCSR base address. Also store and return values of the local access window registers but their functionality isn't implemented.Ping?I guess you're trying to boot a real firmware image from SD card?I'm not trying, I've done it. I only needed these patches and commenting out the page_aligned = true in hw/sd/sdhci.c as I noted in the previous patch.I had to apply <https://github.com/shentok/qemu/commit/56550cbb2805be2913ad9c12d6d9c6a9a3bf6f2c> to have the SPL load the whole U-Boot proper.
Is that an alternative to commenting out page_aligned = true? (Previously it also needed some tweak on when to set DMA bit but after your fix in commit 5df50b8e973 in master resolved it that's no longer needed. Now only the interrupt control reset values and commenting page_aligned = true was needed to get it work.)
U-Boot works and I can run commands in the firmware prompt but I did not try to boot an OS yet. The amigaos boot loader which U-Boot for Tabor loads by default crashes somewhere but this may be a bug in the patched U-Boot. I think I've seen similar with sam460ex U-Boot before, maybe it's because of not finding some expected devices and not handling the returned NULL value well but I did not debug it.Do you use the Tabor U-Boot or something else?
I've tested the firmware image available from this page: http://eliyahu.org/tabor/setup.htmlThere's also a technical manual there that has info on the content of the SD card image.
How do you get to the command prompt? For me, the bootloader application started by Tabor U-Boot doesn't crash but then doesn't find bootable devices, not even with an emulated USB stick. Instead of dropping to the command prompt it only offers a restart to the firmware which then starts the bootloader application again...
There are two U-Boot binaries on the card for some reason (I think maybe the first one runs from cache as RAM and sets up the memory controller), then the first one loads some env variables and then the second U-Boot which then loads the bootloader. If you change one byte in the environment on the SD card it breaks the checksum and then it does not load the bootloader but gives a prompt. You can then look around in U-Boot. Alternatively you can extract the U-Boot binaries and convert to elf to load it with -bios then you can skip the SD card. Maybe depending on some env settings I haven't identified yet, the bootloader either says no bootable devices found or crashes when calling back into U-Boot which may be something similar that I had to fix for sam460ex here: https://gitlab.com/qemu-project/u-boot-sam460ex/-/commit/f6402c160f781145206b2dc0eb4d50738d0531d4/ but I don't have the Tabor U-Boot sources yet to check. Presumably it works on real machine so maybe it checks for SATA or other devices which aren't emulated so it may get an unexpected NULL value. I've tried adding dummy SATA emulation that shows an empty bus but it did not fix that. It could also be something completely different. With the USB patch, it at least finds USB storage devices after usb start in U-Boot but that's all I could test. I should find some Linux boot media known to work on real machine to test further but haven't had time for it.
I've implemented that in my e500-fdt branch which I want to send as an RFC. I still need to clean it up. Once it's on the list we could make a plan how to turn it into a p10xx. Would that work for you?Sure, I can try to test your patches once they are submitted to the list and rebase my changes on top if they still needed. I've just submitted these so you can incorporate them in your tree so I have less to rebase but I see you already have most of these. I'm OK to wait until your tree is cleaned and submitted but it seems there are a lot of patches so it might take a while. I don't expect that you can get it merged before the next release. Some of the patches may need several versions or alternative approaches until they can be merged. For example I expect problems with allowing ',' in device names as this is something that was removed before to avoid the need of quoting or something like that. But I'm not in a hurry as I don't have much free time for it anyway so only come back to this time to time and it's far from anything useful yet.My branch is not a maintainer tree. I neither expect it to be mergeable like this, nor is it my goal. Instead, it's just an experiment to investigate data-driven machine creation which I'd like to share as an RFC with the community.That said, one could probably turn that branch into a p10xx SoC implemented in the classic way. For this, one would need to decide on how to proceed with the mpc8544ds and e500plat machines. There are
These existing machines set up values in PPCE500MachineClass in their init methods that the e500.c uses to change its behaviour to match the machine so to continue adding another board in the classic way I'd continue like that. I've added another similar board file like those machines setting the values matching P1022. For the additional devices in e500.c I've just patched them in for experimenting but these could be optionally created based on new values in the MachineClass, like has_2nd_i2c or similar to not change existing machines. I would not go into more elaborate solutions if your fdt based machine creation replaces this eventually.
Buildroot recipes for the machines, both 32 and 64 bit, which might be nice to keep working -- ideas welcome. Once the p10xx SoC is
I think the e500 machine was originally made for running with KVM and not for TCG emulation but it fell out of maintenance for a while and maybe Linux dropped some of the support by now so don't know if that still works. But it seems to still work for booting Linux in emulation so that should definitely be kept working.
implemented, a tabor machine could be added which uses it.Best regards, Bernhard P.S. The last commit teaches you how to start a firmware from SD card.I did not try your version but looking at the patch looks like you have some sparse-mem region. (I've added similar one from board code, I did not know about this device.) Isn't that the l2cache as RAM or on-chip SRAM or whatever it's called? You seem to have some emulation of that l2cache in a previous patch so can't that be mapped there? Maybe we'll eventually need to implement reading the BOOT data from the beginning of the SD card or flash ROM which may have some initial register values that set things up that are currently hard coded.This is implemented on my branch. It pokes the L2 cache registers to configure some (but not all) SRAM to load the SPL to. This SPL uses cache as RAM which I'm emulating with a modified sparse-mem region device.
This is new addition from today. I still don't get why you need sparse-mem when you also have a separate patch for l2cache regs which could have a memory region itself for this but for now I'm OK with adding this region from the tabor board code on my branch for experimenting. I'm a long way from this to work or being mergeable so your RFC might be ready and merged before that and then I don't need most of my changes, so I try to keep them minimal and have no intent trying to clean up the existing machines or SoC emulation.
Meanwhile I can cherry pick some patches from your tree and test them. Looks like you have some DDR3 support added, I haven't got to that yet.For USB I had this for now: diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c index ee17acdb69..54890d25f3 100644 --- a/hw/ppc/e500.c +++ b/hw/ppc/e500.c @@ -900,6 +900,29 @@ static void ppce500_power_off(void *opaque, int line, int on) } } +static uint64_t usb_read(void *opaque, hwaddr addr, unsigned size) +{ + switch (addr) { + case 0: + return BIT(2) | BIT(17); + } + return 0; +} + +static void usb_write(void *opaque, hwaddr addr, uint64_t val, unsigned size) +{ +} + +static const MemoryRegionOps usb_ops = { + .read = usb_read, + .write = usb_write, + .endianness = DEVICE_BIG_ENDIAN, + .valid = { + .min_access_size = 4, + .max_access_size = 4, + }, +}; + void ppce500_init(MachineState *machine) { MemoryRegion *address_space_mem = get_system_memory(); @@ -1118,6 +1141,19 @@ void ppce500_init(MachineState *machine) sysbus_mmio_get_region(s, 0)); } + /* USB */ + dev = qdev_new("tegra2-ehci-usb"); + s = SYS_BUS_DEVICE(dev); + sysbus_realize_and_unref(s, &error_fatal); + sysbus_connect_irq(s, 0, qdev_get_gpio_in(mpicdev, 12)); + memory_region_add_subregion(ccsr_addr_space, 0x22000, + sysbus_mmio_get_region(s, 0)); + { + MemoryRegion *mr = g_new(MemoryRegion, 1); + memory_region_init_io(mr, OBJECT(dev), &usb_ops, s, "fsl-ehci", 4); + memory_region_add_subregion(ccsr_addr_space, 0x22500, mr); + } + /* General Utility device */ dev = qdev_new("mpc8544-guts"); s = SYS_BUS_DEVICE(dev);which is reusing a sufficiently similar existing device just to have minimal changes. This isn't the right way but since most of these just differ in the reg offsets I wonder if we could turn these offsets into properties so we don't need to add a new subclass for every device. I think subclasses came from the pci version where the PCI IDs are different and maybe sysbus was modelled after that but we only need subclasses where additional registers are needed (which may be the case for this fsl device so this property idea is just unrelated clean up).My implementation has similar usb_ops but is based on TYPE_CHIPIDEA which also has the "endpoints" registers covered. It is used by some i.MX machines and given that these and p1022 are NXP SoCs I wouldn't be surprised if they shared a relation in the real world.
Yes, the CHIPIDEA maybe is a better idea. I've only picked one that had the regs at the right place for a start and it seemed to work enough. But you likely have a more complete implementation so if you submit that eventually this will also be resolved for me so I can drop the above change and use yours instead. I just added it above because you seem to not have BIT(2) but I don't remember what that was and if it's really needed. Otherwise it looked you have the same.
Regards, BALATON Zoltan
