On 10/19/21 13:11, Thomas Huth wrote: > On 19/10/2021 12.07, BALATON Zoltan wrote: >> On Tue, 19 Oct 2021, Christophe Leroy wrote: >>> Le 19/10/2021 à 11:39, Thomas Huth a écrit : >>>> On 19/10/2021 11.31, Christophe Leroy wrote: >>>>> Le 11/10/2021 à 15:24, Thomas Huth a écrit : >>>>>> On 11/10/2021 11.20, David Gibson wrote: >>>>>>> On Mon, Oct 11, 2021 at 10:10:36AM +0200, Thomas Huth wrote: >>>>>>>> On 06/10/2021 09.25, Thomas Huth wrote: >>>>>>>>> On 05/10/2021 23.53, BALATON Zoltan wrote: >>>>>>>>> [...] >>>>>>>>>> Maybe these 405 boards in QEMU ran with modified firmware >>>>>>>>>> where the >>>>>>>>>> memory detection was patched out but it seems to detect the >>>>>>>>>> RAM so I >>>>>>>>>> wonder where it gets that from. Maybe by reading the SDRAM >>>>>>>>>> controller DCRs ppc4xx_sdram_init() sets up. Then I'm not sure >>>>>>>>>> what >>>>>>>>>> it needs the SPD for, I forgot how this worked on sam460ex. Maybe >>>>>>>>>> for the speed calibration, so could be it detects ram by reading >>>>>>>>>> DCRs then tries to get SPD data and that's where it stops as >>>>>>>>>> i2c is >>>>>>>>>> not emulated on taihu. This could be confirmed by checking >>>>>>>>>> what it >>>>>>>>>> pokes with -d guest_errors that shows accesses to missing devices >>>>>>>>>> but don't know where 405 has the i2c controller and if it's >>>>>>>>>> the same >>>>>>>>>> as newer SoCs. If so that could be reused and an i2c bus could be >>>>>>>>>> added with the SPD data like in sam460ex to make u-boot happy >>>>>>>>>> or you >>>>>>>>>> could skip this in u-boot. >>>>>>>>> >>>>>>>>> FWIW, I've just tried the latter (skipping the sdram init in >>>>>>>>> u-boot), >>>>>>>>> and indeed, I can get to the u-boot prompt now. >>>>>>>> [...]> I've also attached the patch with my modifications to >>>>>>>> u-boot. >>>>>>>> >>>>>>>> FYI, the changes can now be found on this branch here: >>>>>>>> >>>>>>>> https://gitlab.com/huth/u-boot/-/commits/taihu >>>>>>>> >>>>>>>> I also added a gitlab-CI file, so you can now download the >>>>>>>> u-boot.bin as an >>>>>>>> artifact from the corresponding pipeline, e.g.: >>>>>>>> >>>>>>>> https://gitlab.com/huth/u-boot/-/jobs/1667201028 >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Are you going to send a v2 of your proposed deprecation patches? >>>>>> >>>>>> No, since there was interest in keeping the 405 boards for testing >>>>>> the 405 code in the Linux kernel, and since there is now a way to >>>>>> do at least some very basic testing of these boards (with the >>>>>> u-boot firmware), I don't plan to respin the deprecation patch. I >>>>>> just sent a patch for adding the boards to our CI instead: >>>>>> >>>>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg02072.html >>>>>> >>>>> >>>>> I have downloaded your u-boot.bin and tried it with both QEMU 5.2.0 >>>>> and mainline, and I get: >>>>> >>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>> Bail out! >>>>> ERROR:../accel/tcg/tcg-accel-ops.c:79:tcg_handle_interrupt: >>>>> assertion failed: (qemu_mutex_iothread_locked()) >>>>> Abandon (core dumped) >>>>> >>>>> I see in the mail history that you got that problem as well at some >>>>> point. How did you fix it ? >>>> >>>> You need this patch here to fix this issue: >>>> >>>> https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg01019.html >>>> ("hw/ppc: Fix iothread locking in the 405 code") >>>> >>> >>> Thank you. >>> >>> Is there anything special to do then in order to boot a Linux kernel ? >>> >>> I build the uImage for ppc40x_defconfig >>> >>> I use the following command, but it does nothing, it stays in uboot >>> prompt as when I don't get a kernel argument >>> >>> ~/qemu/build/qemu-system-ppc -M taihu -bios >>> ~/Téléchargements/u-boot.bin -serial null -serial mon:stdio -kernel >>> arch/powerpc/boot/uImage >> >> I'm not sure using -bios and -kernel together makes sense, it probably >> starts u-boot in this case and you have to load and start the kernel >> from u-boot as you'd notmally do on a real machine. Alternatively you >> could use -kernel instead of -bios which then loads a kernel and >> starts it directly but not sure if it needs a firmware to work. >> >> Ot I could be completely wrong as I don't know this machine and >> haven't tried it. > > Actually, these 405 machines are quite weird. They refuse to boot > without bios image, so you currently need the firmware image for sure.
When using -kernel/-append, if a BIOS is required by the kernel, then it should be crafted by the machine IMO. Usually OS only access a configuration area in PROM. The PROM must be mapped, and the minimum configuration structure filled. Anyhow I find -bios confusing, I never know if this option parse or expects a full/partial raw flash image, an ELF image, something else...
