qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 15/15] ppc/ppc405: Update U-Boot board information for hotfoo


From: Thomas Huth
Subject: Re: [PATCH 15/15] ppc/ppc405: Update U-Boot board information for hotfoot
Date: Mon, 6 Dec 2021 14:40:18 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0

On 06/12/2021 14.37, Cédric Le Goater wrote:
On 12/6/21 14:27, Philippe Mathieu-Daudé wrote:
On 12/6/21 11:37, Cédric Le Goater wrote:
When support for the ESTeem 195E (PPC405EP) SBC (hotfoot) board was
added to Linux, a different layout of U-Boot board information was
introduced because the FW of these boards was an ancient U-Boot
without dual ethernet support [1].

Change the QEMU PPC405 board information to match the hotfoot board
and let the ref405ep machine boot from Linux directly. Only the CPU
frequency is required.

This is brutal force. We could possibly add a machine option or a
ref405ep machine class to update the board information accordingly.

A similar change would be required in U-Boot. The alternative is to
change Linux.

[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074487.html

Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
  hw/ppc/ppc405_uc.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 45 insertions(+)

diff --git a/hw/ppc/ppc405_uc.c b/hw/ppc/ppc405_uc.c
index ec97b22bd019..649bb2b0daf5 100644
--- a/hw/ppc/ppc405_uc.c
+++ b/hw/ppc/ppc405_uc.c
@@ -41,6 +41,49 @@
  #include "qapi/error.h"
  #include "trace.h"
+/*
+ * Linux hotfoot board information based on a production bootloader
+ * (u-boot 1.2.0.x) plus changes not upstream.
+ *
+ * https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-July/074487.html
+ */
+struct linux_hotfoot_bd_info {
+    long unsigned int          bi_memstart;          /*     0     4 */
+    long unsigned int          bi_memsize;           /*     4     4 */
+    long unsigned int          bi_flashstart;        /*     8     4 */
+    long unsigned int          bi_flashsize;         /*    12     4 */
+    long unsigned int          bi_flashoffset;       /*    16     4 */
+    long unsigned int          bi_sramstart;         /*    20     4 */
+    long unsigned int          bi_sramsize;          /*    24     4 */
+    long unsigned int          bi_bootflags;         /*    28     4 */
+    long unsigned int          bi_ip_addr;           /*    32     4 */
+    unsigned char              bi_enetaddr[6];       /*    36     6 */
+    unsigned char              bi_enet1addr[6];      /*    42     6 */
+    short unsigned int         bi_ethspeed;          /*    48     2 */
+    long unsigned int          bi_intfreq;           /*    52     4 */
+    long unsigned int          bi_busfreq;           /*    56     4 */
+    long unsigned int          bi_baudrate;          /*    60     4 */
+    unsigned char              bi_s_version[4];      /*    64     4 */
+    unsigned char              bi_r_version[32];     /*    68    32 */
+    unsigned int               bi_procfreq;          /*   100     4 */
+    unsigned int               bi_plb_busfreq;       /*   104     4 */
+    unsigned int               bi_pci_busfreq;       /*   108     4 */
+    unsigned char              bi_pci_enetaddr[6];   /*   112     6 */
+    unsigned int               bi_pllouta_freq;      /*   120     4 */
+    int                        bi_phynum[2];         /*   124     8 */
+    int                        bi_phymode[2];        /*   132     8 */
+    unsigned int               bi_opbfreq;           /*   140     4 */
+    int                        bi_iic_fast[2];       /*   144     8 */
+};

Why not use <stdint.h> types?

sure.

I am waiting for some feedback on this hack updating the in-memory
board information. I have the feeling that a new 405 machine
is required for this kernel :/

Yeah, it feels rather wrong to bend the ref405ep machine to match the hotfoot expectations of the kernel this way ... maybe it would be better to add an abstract qemu405 machine to the kernel?

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]