On Wed, 20 Oct 2021, LEROY Christophe wrote:
Le 20/10/2021 à 12:10, Cédric Le Goater a écrit :
I dont understand how
static bd_t bd;
can be updated in the kernel.
It's not updated in the kernel.
It is supposed to be provided by UBoot to Linux Kernel. But modern
kernels don't take that anymore, they take a device tree. For this
reason cuboot takes the content of bd to build/update the device tree.
Looks like QEMU also provides the bd, see ref405ep_init()
I managed to get a kernel booting with the following change (and with
CONFIG_ETHERNET removed)
diff --git a/arch/powerpc/boot/cuboot-hotfoot.c
b/arch/powerpc/boot/cuboot-hotfoot.c
index 888a6b9bfead..63a9545ff55d 100644
--- a/arch/powerpc/boot/cuboot-hotfoot.c
+++ b/arch/powerpc/boot/cuboot-hotfoot.c
@@ -132,6 +132,12 @@ void platform_init(unsigned long r3, unsigned long
r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
CUBOOT_INIT();
+ bd.bi_intfreq = 133333333;
+ bd.bi_busfreq = 33333333;
+ bd.bi_procfreq = 133333333;
+ bd.bi_plb_busfreq = 33333333;
+ bd.bi_pci_busfreq = 33333333;
+ bd.bi_opbfreq = 33333333;
platform_ops.fixups = hotfoot_fixups;
platform_ops.exit = ibm40x_dbcr_reset;
fdt_init(_dtb_start);
So maybe taihu should also provide this boot info when linux_boot is true
(i.e. using -kernel) like the ref405ep does? Usually when using -kernel
without -bios then QEMU has to also emulate enough of what the firmware
would otherwise do like setting up devices and setting boot environment.
Or if we have both -bios and -kernel then maybe -kernel should tell the
firmware to boot a kernel but that may need a way to do that like setting
variables in nvram but we don't have models of that in taihu. This taihu
machine seems to be an early skeleton that wasn't finished, the ref405ep
seems to be more advanced.
Regards,
BALATON Zoltan
