Am 7. Februar 2025 01:12:38 UTC schrieb BALATON Zoltan <bala...@eik.bme.hu>:
>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?
Well, it's not needed with the patch applied. The patch ensures that all data
gets loaded:
<https://lore.kernel.org/qemu-devel/d62f06c8-5247-4fbc-82a9-9127352b3...@gmail.com/>
>(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.html
>There's also a technical manual there that has info on the content of the SD
>card image.
I got both from there as well.
>
>> 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.
Yeah, that's the SPL and U-Boot proper. The first one sets up RAM based on DDR3
data, copies U-Boot proper there (currently broken in QEMU, see above), and
passes control to it.
>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.
Considering the technical manual it may be possible to compile U-Boot oneself
and replace components of the firmware image. That way, one could track down
why no bootable devices are found, i.e. check whether and which bootmenu_x
variables are populated. That's not on my todo list though.
>
>>>>> 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.
The challenge is that different variants of the SoC have the same IP cores
mapped at different offsets with possibly (haven't checked) IRQs. These need to
be considered when generating the DTB. To avoid dealing with this question --
and at the same time explore data-driven machine creation -- I reversed the
process and generated the machine from the DTB. But this question needs to be
answered when implementing a P1022.
>I would not go into more elaborate solutions if your fdt based machine
>creation replaces this eventually.
As said before, I'd send an RFC for discussion on how to proceed.
>
>> 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.
I haven't tried running on KVM since I don't have access to a PPC machine.
Judging from the code both methods should work alike.
Buildroot still works because it builds an old toolchain, kernel, etc.
>
>> 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.
The stack location is specific to U-Boot, not the chip. It resides in cache
(used as RAM) rather than in SRAM. Modeling a cache with cache lines etc. was a
rabbit hole I didn't want to get into. Hence I extended sparse-mem for this
stack region to be user-creatable. When implementing a Tabor machine this stack
region could be hardcoded there.
Best regards,
Bernhard
>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
