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.
