Re: [Qemu-riscv] [Qemu-devel] [PATCH] hw/riscv/virt: re-add machine-specific compatible string to /soc/ node

[Auer, Lukas]

Hi Bin,

On Sun, 2019-03-10 at 22:57 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Sun, Mar 10, 2019 at 9:44 PM Auer, Lukas
> <address@hidden> wrote:
> > Hi Bin,
> > 
> > On Sun, 2019-03-10 at 09:07 +0800, Bin Meng wrote:
> > > Hi Lukas,
> > > 
> > > On Mon, Feb 11, 2019 at 6:13 AM Lukas Auer
> > > <address@hidden> wrote:
> > > > Re-add the previous compatible string "riscv-virtio-soc" to the
> > > > soc
> > > > device tree node to allow U-Boot and Linux to bind machine-
> > > > specific
> > > > drivers to it. The current compatible string "simple-bus" is
> > > > retained.
> > > > 
> > > > This is required by U-Boot to bind devices early, as part of
> > > > the
> > > > pre-relocation driver model.
> > > > 
> > > 
> > > I see no problem with U-Boot working with current compatible
> > > string
> > > "simple-bus". In fact I had planned to remove the compatible
> > > string
> > > "riscv-virtio-soc" in U-Boot but did not get time to work on it.
> > > 
> > 
> > It is only required if U-Boot is running in machine-mode. For
> > relocation it needs to use the CLINT driver to send appropriate
> > IPIs to
> > the other harts. To be able to probe the driver, the device and its
> > parent device tree node (soc) must therefore be available in the
> > pre-
> > relocation device model.
> > This patch was the easiest way I could think of for achieving this.
> > It
> > could be that there is a better way of solving this.
> > 
> 
> I tested your SMP U-Boot series in both M-mode and S-mode, using a 4
> core 'virt' target. Works fine. I am using QEMU 3.1.0 so it is
> "simple-bus".
> 

That is actually my fault, it should not work.
What is happening is that U-Boot fails to relocate the secondary harts,
because the CLINT driver cannot get the memory address of the CLINT
device. This error is currently silently ignored.
The secondary harts are still waiting to receive IPIs, so booting Linux
works fine, because U-Boot can now send IPIs. This will however break
if U-Boot overwrites the code the secondary harts are running, which
could happen when loading an image.

I will update my SMP U-Boot series to print a warning if sending an IPI
fails.

Thanks,
Lukas