Re: Deprecate the ppc405 boards in QEMU?

[Christophe Leroy <christophe.leroy@csgroup.eu>]

Le 21/10/2021 à 09:25, Thomas Huth a écrit :
> On 21/10/2021 08.48, Christophe Leroy wrote:
>>
>>
>> Le 20/10/2021 à 15:16, Christophe Leroy a écrit :
>>>
>>>
>>> Le 20/10/2021 à 14:43, Cédric Le Goater a écrit :
>>>> On 10/20/21 13:42, BALATON Zoltan wrote:
>>>>> On Wed, 20 Oct 2021, Philippe Mathieu-Daudé wrote:
>>>>>> On 10/5/21 14:29, Thomas Huth wrote:
>>>>>>> On 05/10/2021 14.20, BALATON Zoltan wrote:
>>>>>>>> On Tue, 5 Oct 2021, Cédric Le Goater wrote:
>>>>>>>>> On 10/5/21 08:18, Alexey Kardashevskiy wrote:
>>>>>>>>>> On 05/10/2021 15:44, Christophe Leroy wrote:
>>>>>>>>>>> Le 05/10/2021 à 02:48, David Gibson a écrit :
>>>>>>>>>>>> On Fri, Oct 01, 2021 at 04:18:49PM +0200, Thomas Huth wrote:
>>>>>>>>>>>>> On 01/10/2021 15.04, Christophe Leroy wrote:
>>>>>>>>>>>>>> Le 01/10/2021 à 14:04, Thomas Huth a écrit :
>>>>>>>>>>>>>>> On 01/10/2021 13.12, Peter Maydell wrote:
>>>>>>>>>>>>>>>> On Fri, 1 Oct 2021 at 10:43, Thomas Huth <thuth@redhat.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Nevertheless, as long as nobody has a hint where to 
>>>>>>>>>>>>>>>>> find that
>>>>>>>>>>>>>>>>> ppc405_rom.bin, I think both boards are pretty useless in
>>>>>>>>>>>>>>>>> QEMU (as far as I
>>>>>>>>>>>>>>>>> can see, they do not work without the bios at all, so it's
>>>>>>>>>>>>>>>>> also not possible
>>>>>>>>>>>>>>>>> to use a Linux image with the "-kernel" CLI option 
>>>>>>>>>>>>>>>>> directly).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> It is at least in theory possible to run bare-metal code on
>>>>>>>>>>>>>>>> either board, by passing either a pflash or a bios 
>>>>>>>>>>>>>>>> argument.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> True. I did some more research, and seems like there was 
>>>>>>>>>>>>>>> once
>>>>>>>>>>>>>>> support for those boards in u-boot, but it got removed 
>>>>>>>>>>>>>>> there a
>>>>>>>>>>>>>>> couple of years ago already:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/98f705c9cefdf 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/b147ff2f37d5b 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://gitlab.com/qemu-project/u-boot/-/commit/7514037bcdc37 
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But I agree that there seem to be no signs of anybody 
>>>>>>>>>>>>>>>> actually
>>>>>>>>>>>>>>>> successfully using these boards for anything, so we should
>>>>>>>>>>>>>>>> deprecate-and-delete them.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes, let's mark them as deprecated now ... if someone 
>>>>>>>>>>>>>>> still uses
>>>>>>>>>>>>>>> them and speaks up, we can still revert the deprecation 
>>>>>>>>>>>>>>> again.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I really would like to be able to use them to validate 
>>>>>>>>>>>>>> Linux Kernel
>>>>>>>>>>>>>> changes, hence looking for that missing BIOS.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we remove ppc405 from QEMU, we won't be able to do any
>>>>>>>>>>>>>> regression
>>>>>>>>>>>>>> tests of Linux Kernel on those processors.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you/someone managed to compile an old version of u-boot for
>>>>>>>>>>>>> one of these
>>>>>>>>>>>>> two boards, so that we would finally have something for
>>>>>>>>>>>>> regression testing,
>>>>>>>>>>>>> we can of course also keep the boards in QEMU...
>>>>>>>>>>>>
>>>>>>>>>>>> I can see that it would be usefor for some cases, but unless 
>>>>>>>>>>>> someone
>>>>>>>>>>>> volunteers to track down the necessary firmware and look 
>>>>>>>>>>>> after it, I
>>>>>>>>>>>> think we do need to deprecate it - I certainly don't have the
>>>>>>>>>>>> capacity
>>>>>>>>>>>> to look into this.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I will look at it, please allow me a few weeks though.
>>>>>>>>>>
>>>>>>>>>> Well, building it was not hard but now I'd like to know what 
>>>>>>>>>> board
>>>>>>>>>> QEMU actually emulates, there are way too many codenames and 
>>>>>>>>>> PVRs.
>>>>>>>>>
>>>>>>>>> yes. We should try to reduce the list below. Deprecating embedded
>>>>>>>>> machines
>>>>>>>>> is one way.
>>>>>>>>
>>>>>>>> Why should we reduce that list? It's good to have different cpu
>>>>>>>> options when one wants to test code for different PPC versions 
>>>>>>>> (maybe
>>>>>>>> also in user mode) or just to have a quick list of these at one 
>>>>>>>> place.
>>>>>>>
>>>>>>> I think there are many CPUs in that list which cannot be used 
>>>>>>> with any
>>>>>>> board, some of them might be also in a very incomplete state. So
>>>>>>> presenting such a big list to the users is confusing and might 
>>>>>>> create
>>>>>>> wrong expectations. It would be good to remove at least the CPUs 
>>>>>>> which
>>>>>>> are really completely useless.
>>>>>>
>>>>>> Maybe only remove some from system emulation but keep all of them
>>>>>> in user emulation?
>>>>>
>>>>> Or keep them all but mark those that are not tested/may be 
>>>>> incomplete? So the used can see what is expected to work and what 
>>>>> may need to be fixed. That way somebody may try and fix it whereas 
>>>>> if it's not there they are unlikely to try to add it.
>>>>
>>>>
>>>> The bamboo machine with 440 CPUs is booting with the latest kernel
>>>> and we have an acceptance test for it now, thanks to Thomas. There
>>>> is not much effort in keeping them in a working state until someone
>>>> volunteers. Hopefully, Christophe is making sure that we are not
>>>> breaking anything with Linux support.
>>>>
>>>> The 405 machine are still close to deprecation I think. We are still
>>>> struggling to boot one with mainline Linux, using uboot provided by
>>>> Thomas which skips SDRAM init. It is not clear to me if u-boot is
>>>> strictly necessary. It depends if Linux relies on it to do some
>>>> pre-initialization of HW. I guess once we find a good DTS for it, or
>>>> not, we can take a decision.
>>>>
>>>
>>> I now have a hacked configuration booting linux with the hotfoot DTS 
>>> and the kernel is booting up to starting /init
>>>
>>> Then it is faulting forever taking a DSI for write protection. The 
>>> problem is now likely in Linux and I'm investigating it, but I'm 
>>> having problem with GDB (7.8.1), I'm hitting the bug 
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=17700
>>>
>>> And GDB 11.1 coredumps while reading vmlinux's symbols
>>>
>>> Hopefully I'll find a GDB version between 7.8 and 11 that works.
>>
>> I bisected the issue to 
>> https://github.com/linuxppc/linux/commit/52ae92cc290f0506eef9ad5466bb453ce4a9e80e 
> 
> 
> You could argue that this commit introduced a bug, or at least a bad 
> behavior in the kernel: According to the 405 user's manual that I have:
> 
>   10.2 Reserved Fields
>   For all registers having fields marked as reserved, the reserved
>   fields should be written as zero and read as undefined. That is,
>   when writing to a reseved field, write a 0 to the field. When
>   reading from a reserved field, ignore the field.
> 
> Thus the kernel should not write non-zero bits into the upper bits of 
> this register.

Yes, SHOULD, not SHALL ...


The following changes fixes the issue in the kernel though:

diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index 618d7f3f9c95..bcde7e284bfa 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -317,8 +317,9 @@ _ENTRY(saved_ksp_limit)
  	/* The bailout.  Restore registers to pre-exception conditions
  	 * and call the heavyweights to help us out.
  	 */
-	mtspr	SPRN_PID, r12
  	mtcrf	0x80, r12
+	rlwinm	r12, r12, 0, 0xff
+	mtspr	SPRN_PID, r12
  	mfspr	r9, SPRN_SPRG_SCRATCH4
  	mfspr	r12, SPRN_SPRG_SCRATCH3
  	mfspr	r11, SPRN_SPRG_SCRATCH6
@@ -397,8 +398,9 @@ _ENTRY(saved_ksp_limit)
  	/* The bailout.  Restore registers to pre-exception conditions
  	 * and call the heavyweights to help us out.
  	 */
-	mtspr	SPRN_PID, r12
  	mtcrf	0x80, r12
+	rlwinm	r12, r12, 0, 0xff
+	mtspr	SPRN_PID, r12
  	mfspr	r9, SPRN_SPRG_SCRATCH4
  	mfspr	r12, SPRN_SPRG_SCRATCH3
  	mfspr	r11, SPRN_SPRG_SCRATCH6
@@ -542,8 +544,9 @@ finish_tlb_load:

  	/* Done...restore registers and get out of here.
  	*/
-	mtspr	SPRN_PID, r12
  	mtcrf	0x80, r12
+	rlwinm	r12, r12, 0, 0xff
+	mtspr	SPRN_PID, r12
  	mfspr	r9, SPRN_SPRG_SCRATCH4
  	mfspr	r12, SPRN_SPRG_SCRATCH3
  	mfspr	r11, SPRN_SPRG_SCRATCH6


> 
>> The problem is in QEMU, it should ignore upper bits of PID register.
> 
> Agreed, that's certainly necessary, too.

Yes it seems clear in 405 user's manual chapter 7 Memory Management, 
especially in all drawings, that only bits 24:31 are taken into account 
from PID register.


Christophe