qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: BALATON Zoltan <balaton@eik.bme.hu>
To: Bernhard Beschow <shentey@gmail.com>
Cc: qemu-devel@nongnu.org, qemu-ppc@nongnu.org
Subject: Re: [PATCH] hw/ppc/e500: Partial implementation of local access window registers
Date: Mon, 24 Feb 2025 22:03:18 +0100 (CET)	[thread overview]
Message-ID: <29c166d7-9232-e1db-32f5-efb517bccae3@eik.bme.hu> (raw)
In-Reply-To: <F5E0CFB5-ABE9-448E-B76B-4D08D541A092@gmail.com>

On Thu, 20 Feb 2025, Bernhard Beschow wrote:
> Am 13. Februar 2025 00:13:24 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
>> 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.
>
> The existing machines can already be created from a DTB, see the pc-bios 
> folder which contains the two respective .dts files.

That's why I said that once this is merged we could deprecate the existing 
machines in favour of ppc500 with the dts for these machines replacing 
them so we can get rid of board codes and can add new machines like p1022 
by adding the needed devices and the dts also under ppce500 which can 
become a generic machine supporting all of these. One could then use -M 
ppce500 -dtb mpc85xx.dtb or p1022.dtb or similar. This would work for all 
dtbs that we have devices for and maybe by adding unimplemented device for 
unknown ones would allow somewhat booting other machines as long as those 
devices are not use. Or if keeping a machine for the -M option for all of 
these is desired then we can think of adding some other kind of alias that 
can set the dtb for the ppce500 and call that. But in any case this would 
reduce the mpc85xx to a trivial wrapper of ppce500 that just sets the dtb 
for the machine.

> Thanks for your input, I'll look into it closer after my RFC. Right now 
> I'm quite busy driving the i.MX 8M Plus machine forward, hence my 
> delayed responses.
>
>> 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.
>
> Your additions sound promising! And thanks for testing the devices.

I also got distracted with other machines so I've postponed this for now 
but want to get back to it eventually.

Regards,
BALATON Zoltan


  reply	other threads:[~2025-02-24 21:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-15 21:15 [PATCH] hw/ppc/e500: Partial implementation of local access window registers BALATON Zoltan
2025-01-30 12:45 ` BALATON Zoltan
2025-02-01 14:55   ` Bernhard Beschow
2025-02-01 15:17     ` Bernhard Beschow
2025-02-02  1:25       ` BALATON Zoltan
2025-02-06 23:41         ` Bernhard Beschow
2025-02-07  1:12           ` BALATON Zoltan
2025-02-12 19:40             ` Bernhard Beschow
2025-02-13  0:13               ` BALATON Zoltan
2025-02-20 19:11                 ` Bernhard Beschow
2025-02-24 21:03                   ` BALATON Zoltan [this message]
2025-02-10 17:00         ` BALATON Zoltan
2025-03-01 16:10 ` BALATON Zoltan
2025-03-02 22:30   ` Bernhard Beschow
2025-03-03  0:33     ` BALATON Zoltan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29c166d7-9232-e1db-32f5-efb517bccae3@eik.bme.hu \
    --to=balaton@eik.bme.hu \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=shentey@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).