hw/riscv/sifive_u.c | 137 +++++++++++++++++++++--------------- include/hw/riscv/sifive_u.h | 3 + 2 files changed, 85 insertions(+), 55 deletions(-)
At present the board serial number is hard-coded to 1, and passed to OTP model during initialization. Firmware (FSBL, U-Boot) uses the serial number to generate a unique MAC address for the on-chip ethernet controller. When multiple QEMU 'sifive_u' instances are created and connected to the same subnet, they all have the same MAC address hence it creates a unusable network. A new "serial" property is introduced to specify the board serial number. When not given, the default serial number 1 is used. v3: - Improve machine function names v2: - Fix the serial setting so it correctly sets Alistair Francis (2): riscv/sifive_u: Fix up file ordering riscv/sifive_u: Add a serial property to the sifive_u SoC Bin Meng (1): riscv/sifive_u: Add a serial property to the sifive_u machine hw/riscv/sifive_u.c | 137 +++++++++++++++++++++--------------- include/hw/riscv/sifive_u.h | 3 + 2 files changed, 85 insertions(+), 55 deletions(-) -- 2.25.1
Hi Palmer, On Sat, Mar 7, 2020 at 5:45 AM Alistair Francis <alistair.francis@wdc.com> wrote: > > At present the board serial number is hard-coded to 1, and passed > to OTP model during initialization. Firmware (FSBL, U-Boot) uses > the serial number to generate a unique MAC address for the on-chip > ethernet controller. When multiple QEMU 'sifive_u' instances are > created and connected to the same subnet, they all have the same > MAC address hence it creates a unusable network. > > A new "serial" property is introduced to specify the board serial > number. When not given, the default serial number 1 is used. > Could you please take this for v5.0.0? Regards, Bin
On Mon, 23 Mar 2020 19:08:19 PDT (-0700), bmeng.cn@gmail.com wrote: > Hi Palmer, > > On Sat, Mar 7, 2020 at 5:45 AM Alistair Francis > <alistair.francis@wdc.com> wrote: >> >> At present the board serial number is hard-coded to 1, and passed >> to OTP model during initialization. Firmware (FSBL, U-Boot) uses >> the serial number to generate a unique MAC address for the on-chip >> ethernet controller. When multiple QEMU 'sifive_u' instances are >> created and connected to the same subnet, they all have the same >> MAC address hence it creates a unusable network. >> >> A new "serial" property is introduced to specify the board serial >> number. When not given, the default serial number 1 is used. >> > > Could you please take this for v5.0.0? It's in the queue, sorry I missed them.
On Tue, Mar 24, 2020 at 10:08 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > Hi Palmer, > > On Sat, Mar 7, 2020 at 5:45 AM Alistair Francis > <alistair.francis@wdc.com> wrote: > > > > At present the board serial number is hard-coded to 1, and passed > > to OTP model during initialization. Firmware (FSBL, U-Boot) uses > > the serial number to generate a unique MAC address for the on-chip > > ethernet controller. When multiple QEMU 'sifive_u' instances are > > created and connected to the same subnet, they all have the same > > MAC address hence it creates a unusable network. > > > > A new "serial" property is introduced to specify the board serial > > number. When not given, the default serial number 1 is used. > > > > Could you please take this for v5.0.0? Ping?
On Wed, Apr 1, 2020 at 10:39 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Tue, Mar 24, 2020 at 10:08 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > Hi Palmer, > > > > On Sat, Mar 7, 2020 at 5:45 AM Alistair Francis > > <alistair.francis@wdc.com> wrote: > > > > > > At present the board serial number is hard-coded to 1, and passed > > > to OTP model during initialization. Firmware (FSBL, U-Boot) uses > > > the serial number to generate a unique MAC address for the on-chip > > > ethernet controller. When multiple QEMU 'sifive_u' instances are > > > created and connected to the same subnet, they all have the same > > > MAC address hence it creates a unusable network. > > > > > > A new "serial" property is introduced to specify the board serial > > > number. When not given, the default serial number 1 is used. > > > > > > > Could you please take this for v5.0.0? Applied to the RISC-V tree for 5.1 Alistair > > Ping?
On Tue, Apr 21, 2020 at 3:26 AM Alistair Francis <alistair23@gmail.com> wrote: > > On Wed, Apr 1, 2020 at 10:39 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > On Tue, Mar 24, 2020 at 10:08 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > Hi Palmer, > > > > > > On Sat, Mar 7, 2020 at 5:45 AM Alistair Francis > > > <alistair.francis@wdc.com> wrote: > > > > > > > > At present the board serial number is hard-coded to 1, and passed > > > > to OTP model during initialization. Firmware (FSBL, U-Boot) uses > > > > the serial number to generate a unique MAC address for the on-chip > > > > ethernet controller. When multiple QEMU 'sifive_u' instances are > > > > created and connected to the same subnet, they all have the same > > > > MAC address hence it creates a unusable network. > > > > > > > > A new "serial" property is introduced to specify the board serial > > > > number. When not given, the default serial number 1 is used. > > > > > > > > > > Could you please take this for v5.0.0? > > Applied to the RISC-V tree for 5.1 > Sigh, this patch was submitted on Mar 7 and that is before soft freeze ... Any chance to get this in 5.0? Regards, Bin
On Mon, Apr 20, 2020 at 7:17 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > On Tue, Apr 21, 2020 at 3:26 AM Alistair Francis <alistair23@gmail.com> wrote: > > > > On Wed, Apr 1, 2020 at 10:39 PM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > On Tue, Mar 24, 2020 at 10:08 AM Bin Meng <bmeng.cn@gmail.com> wrote: > > > > > > > > Hi Palmer, > > > > > > > > On Sat, Mar 7, 2020 at 5:45 AM Alistair Francis > > > > <alistair.francis@wdc.com> wrote: > > > > > > > > > > At present the board serial number is hard-coded to 1, and passed > > > > > to OTP model during initialization. Firmware (FSBL, U-Boot) uses > > > > > the serial number to generate a unique MAC address for the on-chip > > > > > ethernet controller. When multiple QEMU 'sifive_u' instances are > > > > > created and connected to the same subnet, they all have the same > > > > > MAC address hence it creates a unusable network. > > > > > > > > > > A new "serial" property is introduced to specify the board serial > > > > > number. When not given, the default serial number 1 is used. > > > > > > > > > > > > > Could you please take this for v5.0.0? > > > > Applied to the RISC-V tree for 5.1 > > > > Sigh, this patch was submitted on Mar 7 and that is before soft freeze ... > > Any chance to get this in 5.0? That is up to Palmer. I'm only taking over PRs after the 5.0 release. Alistair > > Regards, > Bin
On Tue, 21 Apr 2020 10:40:05 PDT (-0700), alistair23@gmail.com wrote: > On Mon, Apr 20, 2020 at 7:17 PM Bin Meng <bmeng.cn@gmail.com> wrote: >> >> On Tue, Apr 21, 2020 at 3:26 AM Alistair Francis <alistair23@gmail.com> wrote: >> > >> > On Wed, Apr 1, 2020 at 10:39 PM Bin Meng <bmeng.cn@gmail.com> wrote: >> > > >> > > On Tue, Mar 24, 2020 at 10:08 AM Bin Meng <bmeng.cn@gmail.com> wrote: >> > > > >> > > > Hi Palmer, >> > > > >> > > > On Sat, Mar 7, 2020 at 5:45 AM Alistair Francis >> > > > <alistair.francis@wdc.com> wrote: >> > > > > >> > > > > At present the board serial number is hard-coded to 1, and passed >> > > > > to OTP model during initialization. Firmware (FSBL, U-Boot) uses >> > > > > the serial number to generate a unique MAC address for the on-chip >> > > > > ethernet controller. When multiple QEMU 'sifive_u' instances are >> > > > > created and connected to the same subnet, they all have the same >> > > > > MAC address hence it creates a unusable network. >> > > > > >> > > > > A new "serial" property is introduced to specify the board serial >> > > > > number. When not given, the default serial number 1 is used. >> > > > > >> > > > >> > > > Could you please take this for v5.0.0? >> > >> > Applied to the RISC-V tree for 5.1 >> > >> >> Sigh, this patch was submitted on Mar 7 and that is before soft freeze ... >> >> Any chance to get this in 5.0? > > That is up to Palmer. I'm only taking over PRs after the 5.0 release. Oh, sorry, I just saw this. I though I'd sent out this in a PR weeks ago, but it looks like I didn't actually send it out. I'm not sure if 5.0 is still open, but I'll send a PR out now... > > Alistair > >> >> Regards, >> Bin
© 2016 - 2025 Red Hat, Inc.