On Wed, 12 Feb 2025, Bernhard Beschow wrote:
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>:
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/>
I think the block layer has a solution for such long running operations
and uses coroutines for that but I don't know how that works and I could
not find useful documentation on it. But I don't understand the problem
either so if you've solved it and submit a patch that can be merged that's
good enough for me.
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.
U-Boot proper runs for me too but it may have a bug in the Tabor specific
patch (maybe revealed by missing emulation) that prevents the bootloader
to find a device but I can run until U-Boot and enter commands to it, it
only stops in the bootloader when that calls back to U-Boot. If you
extract U-Boot proper from the SD card image, convert it to elf and run it
with -bios you'd get a prompt so it works. That's what I do now for
experimenting but I'd like it to boot from the SD card the same way as
real machine does eventually.
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.
First of all one would need the source for that which should be available
because of GPL but it's not, at least I could not find it yet. Eventually
I'll get it and may look at this but I'd also like to run binary known to
work on real machine to make sure emulation is correct.
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.
Yes, your DTB based board code is a nice way to create different machines
as the DTB already describes these offsets and irq connections and your
code seems to be quite simple so I think it's a good idea that's worth
pursuing, that could enhance the ppce500 machine and make it more generic.
It could then also drop the separate mpc85xx machine and put all of these
under one ppce500 machine with passing the right dtb to create the
different machines. As long as these are similar enough and only differ in
the devices they have, this could emulate a lot of these SoCs with the
same code.
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.
As I wrote before I think one issue to solve as a next step would be avoid
needing subclasses with comma in names for all compatible devices. I think
allowing alternative names for the same type in the types hash table could
be enough but to hide these from users and -device which can't take comma
names, these might need to go in a separate hash table instead. This could
work the same as register_type but would be something like
register_compatible_name_for_type that adds only a name for an existing
type so it does not need a subclass and duplicate class or type struct
when all we need is a different name for the existing type. I don't know
if it's best put in a new hash table or the same one that holds type
names. E.g. machine names already have aliases for versioned machines for
example. This could be similar for devices that could have alias names for
compatible property in the DTB. Putting these in a separate hash table
might be needed if adding them to the same type name would list them in
-device help or having names with ',' there would cause a problem but it
might even work without that.
These are only high level ideas and I don't know how to implement these
but maybe you can do something with it. In any case, I'm looking forward
for your RFC and try to help reviewing it but I don't have free time to
contribute so I'll continue experimenting with the current code upstream
that's good enough for what I do and it's faw away to try to upstream it
so by then your changes could be merged. What I may contribute is new
device emulation for missing parts. I have some dummy sata that does
nothing but allows the Linux driver to pass detecting no devices, a half
working DIU I made in the last few days that needs more work but I got
some image from U-Boot on it and may look at the DMA controller in the
future. Let me know if you're interested in these or have something for
these or other parts I could use instead. I've tested your SPI flash
implementation but it wasn't working with U-Boot for me and may look at
your USB eventually.
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.
I'm not sure I follow what you say but also not sure if you meant cache
when writing stack in some places. Sure, the whole cache with all its
details does not need to be modelled but what I meant is that if you
emulate l2cache controller registers you could emulate the one that maps
the cache at some address as sram then the BOOT table at the beginning of
the SD card should write that to map it at the right place so if you also
have code to parse that then no sparse-mem should be needed on the command
line. Or is that some other register not part of l2cache? But this is
something that can be sorted later so not a big deal, until then adding s
memory region there either from board code or from command line will do. I
think I get now that maybe you mean that command line is better because
different boards have this at different location so you need to specify
the address and that's easier with -device.
Regards,
BALATON Zoltan
