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 <th...@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
