* [PATCH v2 00/38] ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support
@ 2021-02-18 15:57 ` Bin Meng
0 siblings, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
At present when building qemu-ppce500 the following warnings are seen:
===================== WARNING ======================
This board does not use CONFIG_DM. CONFIG_DM will be
compulsory starting with the v2020.01 release.
Failure to update may result in board removal.
UPD include/generated/timestamp_autogenerated.h
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_PCI Please update
the board to use CONFIG_DM_PCI before the v2019.07 release.
Failure to update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
===================== WARNING ======================
This board does not use CONFIG_DM_ETH (Driver Model
for Ethernet drivers). Please update the board to use
CONFIG_DM_ETH before the v2020.07 release. Failure to
update by the deadline may result in board removal.
See doc/driver-model/migration.rst for more info.
====================================================
The conversion of qemu-ppce500 board to driver model is long overdue.
When testing the exisitng qemu-ppce500 support, PCI was found broken.
This is caused by 2 separate issues:
- One issue was caused by U-Boot:
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
Patch #1 updated the non-DM fsl_pci_init driver to dynamically allocate the
PCI regions, to keep in sync with the pci uclass driver
- One issue was caused by QEMU:
commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
Patch #3-4 fixed this issue to keep in sync with latest QEMU upstream
Patch #5-8, #34-36 are minor fixes and clean-ups.
Starting from patch#9, these are driver model conversion patches.
Patch #11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets
that have non-identity virtual-physical address mappings. A new command 'addrmap'
is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
relocation phase. Also the initialization of this library is moved a bit earlier
in the post-relocation phase otherwise device drivers won't work.
Patch #19-21 are 85xx PCI driver fixes. It adds support to controller register
physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
as current upstream QEMU uses 64-bit cpu address.
Starting from patch#24, these are additional driver support patches.
Patch #24, #26 are minor fix to the 'virtio' command and BLK driver dependency.
Patch #25 enables the VirtIO NET support as by default a VirtIO standard PCI
networking device is connected as an ethernet interface at PCI address 0.1.0.
Patch #27 enables the VirtIO BLK driver support.
Patch #28-30 enables the GPIO support.
Patch #31-32 enables poweroff via GPIO.
Patch #33 enables RTC over the I2C bus.
Patch #37 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.
Patch #38 adds a reST document to describe how to build and run U-Boot for the
QEMU ppce500 machine.
I hope we can make this series to U-Boot v2021.04 release.
This series is available at u-boot-x86/qemu-ppc for testing.
This cover letter is cc'ed to QEMU mailing list for a heads-up.
A future patch will be sent to QEMU mailing list to bring its in-tree
U-Boot source codes up-to-date.
Changes in v2:
- drop the revert patch of commit e002474158d1
- new patch: pci: fsl_pci_init: Dynamically allocate the PCI regions
- add more details in the commit message, and put some comments
in the codes to explain why
- add doc/usage/addrmap.rst
- new patch: test: cmd: Add a basic test for 'addrmap' command
- new patch: virtio: Fix VirtIO BLK driver dependency
- new patch: ppc: qemu: Enable VirtIO BLK support
- new patch: ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
- new patch: gpio: mpc8xxx: Support controller register physical address beyond 32-bit
- new patch: ppc: qemu: Enable GPIO support
- new patch: dm: sysreset: Add a Kconfig option for the 'reset' command
- new patch: ppc: qemu: Enable support for power off via GPIO
- new patch: ppc: qemu: Enable RTC support via I2C
- new patch: ppc: qemu: Delete the temporary FDT virtual-physical mapping after U-Boot is relocated
- new patch: ppc: qemu: Drop a custom env variable 'fdt_addr_r'
- new patch: ppc: qemu: Drop fixed_sdram()
- add descriptions for VirtIO BLK, RTC and power off
Bin Meng (38):
pci: fsl_pci_init: Dynamically allocate the PCI regions
ppc: qemu: Update MAINTAINERS for correct email address
common: fdt_support: Support special case of PCI address in
fdt_read_prop()
ppc: qemu: Support non-identity PCI bus address
ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END
ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW
ppc: qemu: Drop init_laws() and print_laws()
ppc: qemu: Drop board_early_init_f()
ppc: qemu: Enable OF_CONTROL
ppc: qemu: Enable driver model
include: Remove extern from addr_map.h
lib: addr_map: Move address_map[] type to the header file
cmd: Add a command to display the address map
test: cmd: Add a basic test for 'addrmap' command
lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help
ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase
common: Move initr_addr_map() to a bit earlier
ppc: qemu: Switch over to use DM serial
pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
pci: mpc85xx: Support controller register physical address beyond
32-bit
pci: mpc85xx: Support 64-bit bus and cpu address
ppc: qemu: Switch over to use DM ETH and PCI
ppc: qemu: Drop CONFIG_OF_BOARD_SETUP
cmd: Fix virtio command dependency
ppc: qemu: Enable VirtIO NET support
virtio: Fix VirtIO BLK driver dependency
ppc: qemu: Enable VirtIO BLK support
ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
gpio: mpc8xxx: Support controller register physical address beyond
32-bit
ppc: qemu: Enable GPIO support
dm: sysreset: Add a Kconfig option for the 'reset' command
ppc: qemu: Enable support for power off via GPIO
ppc: qemu: Enable RTC support via I2C
ppc: qemu: Delete the temporary FDT virtual-physical mapping after
U-Boot is relocated
ppc: qemu: Drop a custom env variable 'fdt_addr_r'
ppc: qemu: Drop fixed_sdram()
ppc: qemu: Move board directory from board/freescale to
board/emulation
doc: Add a reST document for qemu-ppce500
arch/powerpc/cpu/mpc85xx/Kconfig | 2 +-
arch/powerpc/cpu/mpc85xx/cpu.c | 2 +
arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 +
arch/powerpc/include/asm/arch-mpc85xx/gpio.h | 2 +-
arch/powerpc/include/asm/immap_85xx.h | 1 +
arch/powerpc/include/asm/io.h | 15 +-
.../{freescale => emulation}/qemu-ppce500/Kconfig | 2 +-
board/emulation/qemu-ppce500/MAINTAINERS | 7 +
.../{freescale => emulation}/qemu-ppce500/Makefile | 0
.../qemu-ppce500/qemu-ppce500.c | 178 +++++++--------------
board/freescale/qemu-ppce500/MAINTAINERS | 6 -
cmd/Kconfig | 8 +
cmd/Makefile | 1 +
cmd/addrmap.c | 35 ++++
common/board_r.c | 6 +-
common/fdt_support.c | 20 ++-
configs/qemu-ppce500_defconfig | 27 +++-
doc/board/emulation/index.rst | 1 +
doc/board/emulation/qemu-ppce500.rst | 88 ++++++++++
doc/usage/addrmap.rst | 41 +++++
doc/usage/index.rst | 1 +
drivers/gpio/mpc8xxx_gpio.c | 7 +-
drivers/pci/fsl_pci_init.c | 5 +
drivers/pci/pci_mpc85xx.c | 25 +--
drivers/sysreset/Kconfig | 6 +
drivers/sysreset/sysreset-uclass.c | 2 +
drivers/virtio/Kconfig | 1 +
include/addr_map.h | 16 +-
include/configs/qemu-ppce500.h | 30 +---
include/test/suites.h | 2 +
lib/Kconfig | 2 +
lib/addr_map.c | 6 +-
test/cmd/Makefile | 1 +
test/cmd/addrmap.c | 38 +++++
test/cmd_ut.c | 6 +
35 files changed, 397 insertions(+), 195 deletions(-)
rename board/{freescale => emulation}/qemu-ppce500/Kconfig (86%)
create mode 100644 board/emulation/qemu-ppce500/MAINTAINERS
rename board/{freescale => emulation}/qemu-ppce500/Makefile (100%)
rename board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c (65%)
delete mode 100644 board/freescale/qemu-ppce500/MAINTAINERS
create mode 100644 cmd/addrmap.c
create mode 100644 doc/board/emulation/qemu-ppce500.rst
create mode 100644 doc/usage/addrmap.rst
create mode 100644 test/cmd/addrmap.c
--
2.7.4
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 01/38] pci: fsl_pci_init: Dynamically allocate the PCI regions
2021-02-18 15:57 ` Bin Meng
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-20 11:54 ` Simon Glass
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
changes 'struct pci_controller'.regions from pre-allocated array of
regions to dynamically allocated, which unfortunately broken lots of
boards that still use the non-DM PCI driver.
This patch changes the non-DM fsl_pci_init driver to dynamically
allocate the regions, just like what's done in the pci uclass driver.
Fixes: e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- drop the revert patch of commit e002474158d1
- new patch: pci: fsl_pci_init: Dynamically allocate the PCI regions
drivers/pci/fsl_pci_init.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index e72a60c..fc3327e 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -32,6 +32,8 @@ DECLARE_GLOBAL_DATA_PTR;
#include <asm/io.h>
#include <asm/fsl_pci.h>
+#define MAX_PCI_REGIONS 7
+
#ifndef CONFIG_SYS_PCI_MEMORY_BUS
#define CONFIG_SYS_PCI_MEMORY_BUS 0
#endif
@@ -80,6 +82,9 @@ int fsl_setup_hose(struct pci_controller *hose, unsigned long addr)
/* Reset hose to make sure its in a clean state */
memset(hose, 0, sizeof(struct pci_controller));
+ hose->regions = (struct pci_region *)
+ calloc(1, MAX_PCI_REGIONS * sizeof(struct pci_region));
+
pci_setup_indirect(hose, (u32)&pci->cfg_addr, (u32)&pci->cfg_data);
return fsl_is_pci_agent(hose);
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 01/38] pci: fsl_pci_init: Dynamically allocate the PCI regions
2021-02-18 15:57 ` [PATCH v2 01/38] pci: fsl_pci_init: Dynamically allocate the PCI regions Bin Meng
@ 2021-02-20 11:54 ` Simon Glass
2021-02-20 13:57 ` Tom Rini
0 siblings, 1 reply; 96+ messages in thread
From: Simon Glass @ 2021-02-20 11:54 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Thu, 18 Feb 2021 at 08:58, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> changes 'struct pci_controller'.regions from pre-allocated array of
> regions to dynamically allocated, which unfortunately broken lots of
> boards that still use the non-DM PCI driver.
>
> This patch changes the non-DM fsl_pci_init driver to dynamically
> allocate the regions, just like what's done in the pci uclass driver.
>
> Fixes: e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - drop the revert patch of commit e002474158d1
> - new patch: pci: fsl_pci_init: Dynamically allocate the PCI regions
>
> drivers/pci/fsl_pci_init.c | 5 +++++
> 1 file changed, 5 insertions(+)
Reviewed-by: Simon Glass <sjg@chromium.org>
But I think it would be better to disable PCI on these devices
(Kconfig depends on BROKEN) until the maintainer converts it to DM.
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 01/38] pci: fsl_pci_init: Dynamically allocate the PCI regions
2021-02-20 11:54 ` Simon Glass
@ 2021-02-20 13:57 ` Tom Rini
0 siblings, 0 replies; 96+ messages in thread
From: Tom Rini @ 2021-02-20 13:57 UTC (permalink / raw)
To: u-boot
On Sat, Feb 20, 2021 at 04:54:50AM -0700, Simon Glass wrote:
> Hi Bin,
>
> On Thu, 18 Feb 2021 at 08:58, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > changes 'struct pci_controller'.regions from pre-allocated array of
> > regions to dynamically allocated, which unfortunately broken lots of
> > boards that still use the non-DM PCI driver.
> >
> > This patch changes the non-DM fsl_pci_init driver to dynamically
> > allocate the regions, just like what's done in the pci uclass driver.
> >
> > Fixes: e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >
> > ---
> >
> > Changes in v2:
> > - drop the revert patch of commit e002474158d1
> > - new patch: pci: fsl_pci_init: Dynamically allocate the PCI regions
> >
> > drivers/pci/fsl_pci_init.c | 5 +++++
> > 1 file changed, 5 insertions(+)
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> But I think it would be better to disable PCI on these devices
> (Kconfig depends on BROKEN) until the maintainer converts it to DM.
I don't think that will work here and I suspect disabling PCI will lead
to a ton of other build problems. I'm going to try and finish up a
branch that removes all of the DM_MMC fail to convert boards (which has
a lot of overlap with other fail to converts) and then we can see what's
missing still for DM_PCI and some others.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210220/98f5144b/attachment.sig>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 02/38] ppc: qemu: Update MAINTAINERS for correct email address
2021-02-18 15:57 ` Bin Meng
(?)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 7:39 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
Alex's previous email address is no longer reachable.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
board/freescale/qemu-ppce500/MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/qemu-ppce500/MAINTAINERS b/board/freescale/qemu-ppce500/MAINTAINERS
index 77d0a4a..e70c095 100644
--- a/board/freescale/qemu-ppce500/MAINTAINERS
+++ b/board/freescale/qemu-ppce500/MAINTAINERS
@@ -1,5 +1,5 @@
QEMU-PPCE500 BOARD
-M: Alexander Graf <agraf@suse.de>
+M: Alexander Graf <agraf@csgraf.de>
S: Maintained
F: board/freescale/qemu-ppce500/
F: include/configs/qemu-ppce500.h
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread
* [PATCH v2 02/38] ppc: qemu: Update MAINTAINERS for correct email address
2021-02-18 15:57 ` [PATCH v2 02/38] ppc: qemu: Update MAINTAINERS for correct email address Bin Meng
@ 2021-02-22 7:39 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 7:39 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 02/38] ppc: qemu: Update MAINTAINERS for correct email
>address
>
>Alex's previous email address is no longer reachable.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> board/freescale/qemu-ppce500/MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/board/freescale/qemu-ppce500/MAINTAINERS
>b/board/freescale/qemu-ppce500/MAINTAINERS
>index 77d0a4a..e70c095 100644
>--- a/board/freescale/qemu-ppce500/MAINTAINERS
>+++ b/board/freescale/qemu-ppce500/MAINTAINERS
>@@ -1,5 +1,5 @@
> QEMU-PPCE500 BOARD
>-M: Alexander Graf <agraf@suse.de>
>+M: Alexander Graf <agraf@csgraf.de>
> S: Maintained
> F: board/freescale/qemu-ppce500/
> F: include/configs/qemu-ppce500.h
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 03/38] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-18 15:57 ` Bin Meng
` (2 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-20 11:54 ` Simon Glass
2021-02-22 7:42 ` Priyanka Jain
-1 siblings, 2 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
At present fdt_read_prop() can only handle 1 or 2 cells. It is
called by fdt_read_range() which may be used to read PCI address
from <ranges> for a PCI bus node where the number of PCI address
cell is 3. The <ranges> property is an array of:
{ <child address> <parent address> <size in child address space> }
When trying to read <child address> from a PCI bus node using
fdt_read_prop(), as the codes below:
/* Read <child address> */
if (child_addr) {
r = fdt_read_prop(ranges, ranges_len, cell, child_addr,
acells);
if (r)
return r;
}
it will fail, because the PCI child address is made up of 3 cells
but fdt_read_prop() cannot handle it. We advance the cell offset
by 1 so that the <child address> can be correctly read.
This adds the special handling of such case.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- add more details in the commit message, and put some comments
in the codes to explain why
common/fdt_support.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 638eca9..17c54a3 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1602,22 +1602,36 @@ u64 fdt_get_base_address(const void *fdt, int node)
}
/*
- * Read a property of size <prop_len>. Currently only supports 1 or 2 cells.
+ * Read a property of size <prop_len>. Currently only supports 1 or 2 cells,
+ * or 3 cells specially for a PCI address.
*/
static int fdt_read_prop(const fdt32_t *prop, int prop_len, int cell_off,
uint64_t *val, int cells)
{
- const fdt32_t *prop32 = &prop[cell_off];
- const unaligned_fdt64_t *prop64 = (const fdt64_t *)&prop[cell_off];
+ const fdt32_t *prop32;
+ const unaligned_fdt64_t *prop64;
if ((cell_off + cells) > prop_len)
return -FDT_ERR_NOSPACE;
+ prop32 = &prop[cell_off];
+
+ /*
+ * Special handling for PCI address in PCI bus <ranges>
+ *
+ * PCI child address is made up of 3 cells. Advance the cell offset
+ * by 1 so that the PCI child address can be correctly read.
+ */
+ if (cells == 3)
+ cell_off += 1;
+ prop64 = (const fdt64_t *)&prop[cell_off];
+
switch (cells) {
case 1:
*val = fdt32_to_cpu(*prop32);
break;
case 2:
+ case 3:
*val = fdt64_to_cpu(*prop64);
break;
default:
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 03/38] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-18 15:57 ` [PATCH v2 03/38] common: fdt_support: Support special case of PCI address in fdt_read_prop() Bin Meng
@ 2021-02-20 11:54 ` Simon Glass
2021-02-20 13:03 ` Bin Meng
2021-02-22 7:42 ` Priyanka Jain
1 sibling, 1 reply; 96+ messages in thread
From: Simon Glass @ 2021-02-20 11:54 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Thu, 18 Feb 2021 at 08:58, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> At present fdt_read_prop() can only handle 1 or 2 cells. It is
> called by fdt_read_range() which may be used to read PCI address
> from <ranges> for a PCI bus node where the number of PCI address
> cell is 3. The <ranges> property is an array of:
>
> { <child address> <parent address> <size in child address space> }
>
> When trying to read <child address> from a PCI bus node using
> fdt_read_prop(), as the codes below:
>
> /* Read <child address> */
> if (child_addr) {
> r = fdt_read_prop(ranges, ranges_len, cell, child_addr,
> acells);
> if (r)
> return r;
> }
>
> it will fail, because the PCI child address is made up of 3 cells
> but fdt_read_prop() cannot handle it. We advance the cell offset
> by 1 so that the <child address> can be correctly read.
>
> This adds the special handling of such case.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - add more details in the commit message, and put some comments
> in the codes to explain why
>
> common/fdt_support.c | 20 +++++++++++++++++---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/common/fdt_support.c b/common/fdt_support.c
> index 638eca9..17c54a3 100644
> --- a/common/fdt_support.c
> +++ b/common/fdt_support.c
> @@ -1602,22 +1602,36 @@ u64 fdt_get_base_address(const void *fdt, int node)
> }
>
> /*
> - * Read a property of size <prop_len>. Currently only supports 1 or 2 cells.
> + * Read a property of size <prop_len>. Currently only supports 1 or 2 cells,
> + * or 3 cells specially for a PCI address.
> */
> static int fdt_read_prop(const fdt32_t *prop, int prop_len, int cell_off,
> uint64_t *val, int cells)
> {
> - const fdt32_t *prop32 = &prop[cell_off];
> - const unaligned_fdt64_t *prop64 = (const fdt64_t *)&prop[cell_off];
> + const fdt32_t *prop32;
> + const unaligned_fdt64_t *prop64;
>
> if ((cell_off + cells) > prop_len)
> return -FDT_ERR_NOSPACE;
>
> + prop32 = &prop[cell_off];
> +
> + /*
> + * Special handling for PCI address in PCI bus <ranges>
> + *
> + * PCI child address is made up of 3 cells. Advance the cell offset
> + * by 1 so that the PCI child address can be correctly read.
> + */
> + if (cells == 3)
> + cell_off += 1;
> + prop64 = (const fdt64_t *)&prop[cell_off];
> +
> switch (cells) {
> case 1:
> *val = fdt32_to_cpu(*prop32);
> break;
> case 2:
> + case 3:
> *val = fdt64_to_cpu(*prop64);
> break;
> default:
> --
> 2.7.4
>
I'm not sure whether this is needed once PPC PCI is converted to DM.
If not, then perhaps we can revert it later. If it is then it would be
nice to have a test.
Reviewed-by: Simon Glass <sjg@chromium.org>
Regards,
Simon
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 03/38] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-20 11:54 ` Simon Glass
@ 2021-02-20 13:03 ` Bin Meng
0 siblings, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-20 13:03 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Sat, Feb 20, 2021 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Thu, 18 Feb 2021 at 08:58, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > At present fdt_read_prop() can only handle 1 or 2 cells. It is
> > called by fdt_read_range() which may be used to read PCI address
> > from <ranges> for a PCI bus node where the number of PCI address
> > cell is 3. The <ranges> property is an array of:
> >
> > { <child address> <parent address> <size in child address space> }
> >
> > When trying to read <child address> from a PCI bus node using
> > fdt_read_prop(), as the codes below:
> >
> > /* Read <child address> */
> > if (child_addr) {
> > r = fdt_read_prop(ranges, ranges_len, cell, child_addr,
> > acells);
> > if (r)
> > return r;
> > }
> >
> > it will fail, because the PCI child address is made up of 3 cells
> > but fdt_read_prop() cannot handle it. We advance the cell offset
> > by 1 so that the <child address> can be correctly read.
> >
> > This adds the special handling of such case.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >
> > ---
> >
> > Changes in v2:
> > - add more details in the commit message, and put some comments
> > in the codes to explain why
> >
> > common/fdt_support.c | 20 +++++++++++++++++---
> > 1 file changed, 17 insertions(+), 3 deletions(-)
> >
> > diff --git a/common/fdt_support.c b/common/fdt_support.c
> > index 638eca9..17c54a3 100644
> > --- a/common/fdt_support.c
> > +++ b/common/fdt_support.c
> > @@ -1602,22 +1602,36 @@ u64 fdt_get_base_address(const void *fdt, int node)
> > }
> >
> > /*
> > - * Read a property of size <prop_len>. Currently only supports 1 or 2 cells.
> > + * Read a property of size <prop_len>. Currently only supports 1 or 2 cells,
> > + * or 3 cells specially for a PCI address.
> > */
> > static int fdt_read_prop(const fdt32_t *prop, int prop_len, int cell_off,
> > uint64_t *val, int cells)
> > {
> > - const fdt32_t *prop32 = &prop[cell_off];
> > - const unaligned_fdt64_t *prop64 = (const fdt64_t *)&prop[cell_off];
> > + const fdt32_t *prop32;
> > + const unaligned_fdt64_t *prop64;
> >
> > if ((cell_off + cells) > prop_len)
> > return -FDT_ERR_NOSPACE;
> >
> > + prop32 = &prop[cell_off];
> > +
> > + /*
> > + * Special handling for PCI address in PCI bus <ranges>
> > + *
> > + * PCI child address is made up of 3 cells. Advance the cell offset
> > + * by 1 so that the PCI child address can be correctly read.
> > + */
> > + if (cells == 3)
> > + cell_off += 1;
> > + prop64 = (const fdt64_t *)&prop[cell_off];
> > +
> > switch (cells) {
> > case 1:
> > *val = fdt32_to_cpu(*prop32);
> > break;
> > case 2:
> > + case 3:
> > *val = fdt64_to_cpu(*prop64);
> > break;
> > default:
> > --
> > 2.7.4
> >
>
> I'm not sure whether this is needed once PPC PCI is converted to DM.
> If not, then perhaps we can revert it later. If it is then it would be
I think we can completely remove these APIs once PPC PCI is converted
to DM. We can revisit this later.
> nice to have a test.
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 03/38] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-18 15:57 ` [PATCH v2 03/38] common: fdt_support: Support special case of PCI address in fdt_read_prop() Bin Meng
2021-02-20 11:54 ` Simon Glass
@ 2021-02-22 7:42 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 7:42 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 03/38] common: fdt_support: Support special case of PCI
>address in fdt_read_prop()
>
>At present fdt_read_prop() can only handle 1 or 2 cells. It is called by
>fdt_read_range() which may be used to read PCI address from <ranges> for a
>PCI bus node where the number of PCI address cell is 3. The <ranges>
>property is an array of:
>
> { <child address> <parent address> <size in child address space> }
>
>When trying to read <child address> from a PCI bus node using
>fdt_read_prop(), as the codes below:
>
> /* Read <child address> */
> if (child_addr) {
> r = fdt_read_prop(ranges, ranges_len, cell, child_addr,
> acells);
> if (r)
> return r;
> }
>
>it will fail, because the PCI child address is made up of 3 cells but
>fdt_read_prop() cannot handle it. We advance the cell offset by 1 so that the
><child address> can be correctly read.
>
>This adds the special handling of such case.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 04/38] ppc: qemu: Support non-identity PCI bus address
2021-02-18 15:57 ` Bin Meng
` (3 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
-1 siblings, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
When QEMU originally supported the ppce500 machine back in Jan 2014,
it was created with a 1:1 mapping of PCI bus address. Things seemed
to change rapidly that in Nov 2014 with the following QEMU commits:
commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
and
commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
the PCI memory and IO physical address were moved to beyond 4 GiB,
but PCI bus address remained below 4 GiB, hence a non-identity
mapping was created. Unfortunately corresponding U-Boot updates
were missed along with the QEMU changes and the U-Boot QEMU ppce500
PCI support has been broken since then.
This commit makes the PCI (non-DM version) work again.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 29 ++++++++++++++---------------
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index aa5774f..1d68d30 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -85,20 +85,24 @@ int checkboard(void)
}
static int pci_map_region(void *fdt, int pci_node, int range_id,
- phys_size_t *ppaddr, pci_addr_t *pvaddr,
- pci_size_t *psize, ulong *pmap_addr)
+ phys_addr_t *pbaddr, phys_size_t *ppaddr,
+ pci_addr_t *pvaddr, pci_size_t *psize,
+ ulong *pmap_addr)
{
- uint64_t addr;
+ uint64_t baddr;
+ uint64_t paddr;
uint64_t size;
ulong map_addr;
int r;
- r = fdt_read_range(fdt, pci_node, range_id, NULL, &addr, &size);
+ r = fdt_read_range(fdt, pci_node, range_id, &baddr, &paddr, &size);
if (r)
return r;
+ if (pbaddr)
+ *pbaddr = baddr;
if (ppaddr)
- *ppaddr = addr;
+ *ppaddr = paddr;
if (psize)
*psize = size;
@@ -115,7 +119,7 @@ static int pci_map_region(void *fdt, int pci_node, int range_id,
return -1;
/* Map virtual memory for range */
- assert(!tlb_map_range(map_addr, addr, size, TLB_MAP_IO));
+ assert(!tlb_map_range(map_addr, paddr, size, TLB_MAP_IO));
*pmap_addr = map_addr + size;
if (pvaddr)
@@ -166,24 +170,19 @@ void pci_init_board(void)
pci_info.regs = fdt_translate_address(fdt, pci_node, reg);
/* Map MMIO range */
- r = pci_map_region(fdt, pci_node, 0, &pci_info.mem_phys, NULL,
+ r = pci_map_region(fdt, pci_node, 0, &pci_info.mem_bus,
+ &pci_info.mem_phys, NULL,
&pci_info.mem_size, &map_addr);
if (r)
break;
/* Map PIO range */
- r = pci_map_region(fdt, pci_node, 1, &pci_info.io_phys, NULL,
+ r = pci_map_region(fdt, pci_node, 1, &pci_info.io_bus,
+ &pci_info.io_phys, NULL,
&pci_info.io_size, &map_addr);
if (r)
break;
- /*
- * The PCI framework finds virtual addresses for the buses
- * through our address map, so tell it the physical addresses.
- */
- pci_info.mem_bus = pci_info.mem_phys;
- pci_info.io_bus = pci_info.io_phys;
-
/* Instantiate */
pci_info.pci_num = pci_num + 1;
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 05/38] ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END
2021-02-18 15:57 ` Bin Meng
` (4 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 7:47 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
CONFIG_SYS_PCI_MAP_END currently points to 0xe8000000, which means
the upper end of the virtual address mapped to PCI bus address ends
at 0xe8000000. But this is wrong as the CCSBAR was already mapped
at 0xe0000000 with a 1 MiB size.
Fixes: fa08d3951777 ("PPC 85xx: Add qemu-ppce500 machine")
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
include/configs/qemu-ppce500.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h
index ee6ef18..f13e4ea 100644
--- a/include/configs/qemu-ppce500.h
+++ b/include/configs/qemu-ppce500.h
@@ -35,7 +35,7 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void);
/* Virtual address range for PCI region maps */
#define CONFIG_SYS_PCI_MAP_START 0x80000000
-#define CONFIG_SYS_PCI_MAP_END 0xe8000000
+#define CONFIG_SYS_PCI_MAP_END 0xe0000000
/* Virtual address to a temporary map if we need it (max 128MB) */
#define CONFIG_SYS_TMPVIRT 0xe8000000
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 05/38] ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END
2021-02-18 15:57 ` [PATCH v2 05/38] ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END Bin Meng
@ 2021-02-22 7:47 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 7:47 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 05/38] ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END
>
>CONFIG_SYS_PCI_MAP_END currently points to 0xe8000000, which means
>the upper end of the virtual address mapped to PCI bus address ends at
>0xe8000000. But this is wrong as the CCSBAR was already mapped at
>0xe0000000 with a 1 MiB size.
>
>Fixes: fa08d3951777 ("PPC 85xx: Add qemu-ppce500 machine")
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> include/configs/qemu-ppce500.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-
>ppce500.h index ee6ef18..f13e4ea 100644
>--- a/include/configs/qemu-ppce500.h
>+++ b/include/configs/qemu-ppce500.h
>@@ -35,7 +35,7 @@ extern unsigned long long
>get_phys_ccsrbar_addr_early(void);
>
> /* Virtual address range for PCI region maps */
> #define CONFIG_SYS_PCI_MAP_START 0x80000000
>-#define CONFIG_SYS_PCI_MAP_END 0xe8000000
>+#define CONFIG_SYS_PCI_MAP_END 0xe0000000
>
> /* Virtual address to a temporary map if we need it (max 128MB) */
> #define CONFIG_SYS_TMPVIRT 0xe8000000
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW
2021-02-18 15:57 ` Bin Meng
` (5 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:12 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
LAW related codes should be wrapped with CONFIG_FSL_LAW.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/powerpc/cpu/mpc85xx/cpu.c | 2 ++
arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 5170610..fc25bb2 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -395,7 +395,9 @@ int cpu_mmc_init(struct bd_info *bis)
void print_reginfo(void)
{
print_tlbcam();
+#ifdef CONFIG_FSL_LAW
print_laws();
+#endif
#if defined(CONFIG_FSL_LBC)
print_lbc_regs();
#endif
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
index 4195ecc..5a0d33b 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -123,7 +123,9 @@ void cpu_init_early_f(void *fdt)
setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_LCLK_IFC_CS3);
#endif
+#ifdef CONFIG_FSL_LAW
init_laws();
+#endif
/*
* Work Around for IFC Erratum A003399, issue will hit only when execution
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW
2021-02-18 15:57 ` [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW Bin Meng
@ 2021-02-22 8:12 ` Priyanka Jain
2021-02-22 8:53 ` Bin Meng
0 siblings, 1 reply; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:12 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini <trini@konsulko.com>
>Subject: [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with
>CONFIG_FSL_LAW
>
>LAW related codes should be wrapped with CONFIG_FSL_LAW.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> arch/powerpc/cpu/mpc85xx/cpu.c | 2 ++
> arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 ++
> 2 files changed, 4 insertions(+)
>
>diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c
>b/arch/powerpc/cpu/mpc85xx/cpu.c index 5170610..fc25bb2 100644
>--- a/arch/powerpc/cpu/mpc85xx/cpu.c
>+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
>@@ -395,7 +395,9 @@ int cpu_mmc_init(struct bd_info *bis) void
>print_reginfo(void) {
> print_tlbcam();
>+#ifdef CONFIG_FSL_LAW
> print_laws();
>+#endif
> #if defined(CONFIG_FSL_LBC)
> print_lbc_regs();
> #endif
>diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>index 4195ecc..5a0d33b 100644
>--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>@@ -123,7 +123,9 @@ void cpu_init_early_f(void *fdt)
> setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_LCLK_IFC_CS3); #endif
>
>+#ifdef CONFIG_FSL_LAW
> init_laws();
>+#endif
LAWs are required to be initialized while running on actual boards.
For QEMU, may be you can create config like CONFIG_FSL_BYPASS_LAW
Priyanka
<snip>
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW
2021-02-22 8:12 ` Priyanka Jain
@ 2021-02-22 8:53 ` Bin Meng
2021-02-23 10:43 ` Priyanka Jain
0 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-22 8:53 UTC (permalink / raw)
To: u-boot
Hi Priyanka,
On Mon, Feb 22, 2021 at 4:12 PM Priyanka Jain <priyanka.jain@nxp.com> wrote:
>
>
>
> >-----Original Message-----
> >From: Bin Meng <bmeng.cn@gmail.com>
> >Sent: Thursday, February 18, 2021 9:28 PM
> >To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
> >Priyanka Jain <priyanka.jain@nxp.com>
> >Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini <trini@konsulko.com>
> >Subject: [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with
> >CONFIG_FSL_LAW
> >
> >LAW related codes should be wrapped with CONFIG_FSL_LAW.
> >
> >Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >---
> >
> >(no changes since v1)
> >
> > arch/powerpc/cpu/mpc85xx/cpu.c | 2 ++
> > arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 ++
> > 2 files changed, 4 insertions(+)
> >
> >diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c
> >b/arch/powerpc/cpu/mpc85xx/cpu.c index 5170610..fc25bb2 100644
> >--- a/arch/powerpc/cpu/mpc85xx/cpu.c
> >+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
> >@@ -395,7 +395,9 @@ int cpu_mmc_init(struct bd_info *bis) void
> >print_reginfo(void) {
> > print_tlbcam();
> >+#ifdef CONFIG_FSL_LAW
> > print_laws();
> >+#endif
> > #if defined(CONFIG_FSL_LBC)
> > print_lbc_regs();
> > #endif
> >diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> >b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> >index 4195ecc..5a0d33b 100644
> >--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> >+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
> >@@ -123,7 +123,9 @@ void cpu_init_early_f(void *fdt)
> > setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_LCLK_IFC_CS3); #endif
> >
> >+#ifdef CONFIG_FSL_LAW
> > init_laws();
> >+#endif
>
> LAWs are required to be initialized while running on actual boards.
Yes, CONFIG_FSL_LAW is selected by all 85xx SoCs in
arch/powerpc/cpu/mpc85xx/Kconfig
> For QEMU, may be you can create config like CONFIG_FSL_BYPASS_LAW
Only QEMU does not select CONFIG_FSL_LAW and hence it's a Kconfig
option all codes that call into functions in FSL_LAW should be wrapped
by CONFIG_FSL_LAW.
I don't think we should introduce another CONFIG_FSL_BYPASS_LAW for this.
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW
2021-02-22 8:53 ` Bin Meng
@ 2021-02-23 10:43 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-23 10:43 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Bin Meng
>Sent: Monday, February 22, 2021 2:24 PM
>To: Priyanka Jain <priyanka.jain@nxp.com>
>Cc: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>; U-
>Boot Mailing List <u-boot@lists.denx.de>; Tom Rini <trini@konsulko.com>
>Subject: Re: [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with
>CONFIG_FSL_LAW
>
>Hi Priyanka,
>
>On Mon, Feb 22, 2021 at 4:12 PM Priyanka Jain <priyanka.jain@nxp.com> wrote:
>>
>>
>>
>> >-----Original Message-----
>> >From: Bin Meng <bmeng.cn@gmail.com>
>> >Sent: Thursday, February 18, 2021 9:28 PM
>> >To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>> >Priyanka Jain <priyanka.jain@nxp.com>
>> >Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
>> ><trini@konsulko.com>
>> >Subject: [PATCH v2 06/38] ppc: mpc85xx: Wrap LAW related codes with
>> >CONFIG_FSL_LAW
>> >
>> >LAW related codes should be wrapped with CONFIG_FSL_LAW.
>> >
>> >Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> >---
>> >
>> >(no changes since v1)
>> >
>> > arch/powerpc/cpu/mpc85xx/cpu.c | 2 ++
>> > arch/powerpc/cpu/mpc85xx/cpu_init_early.c | 2 ++
>> > 2 files changed, 4 insertions(+)
>> >
>> >diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c
>> >b/arch/powerpc/cpu/mpc85xx/cpu.c index 5170610..fc25bb2 100644
>> >--- a/arch/powerpc/cpu/mpc85xx/cpu.c
>> >+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
>> >@@ -395,7 +395,9 @@ int cpu_mmc_init(struct bd_info *bis) void
>> >print_reginfo(void) {
>> > print_tlbcam();
>> >+#ifdef CONFIG_FSL_LAW
>> > print_laws();
>> >+#endif
>> > #if defined(CONFIG_FSL_LBC)
>> > print_lbc_regs();
>> > #endif
>> >diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>> >b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>> >index 4195ecc..5a0d33b 100644
>> >--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>> >+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
>> >@@ -123,7 +123,9 @@ void cpu_init_early_f(void *fdt)
>> > setbits_be32(&gur->pmuxcr, MPC85xx_PMUXCR_LCLK_IFC_CS3);
>> >#endif
>> >
>> >+#ifdef CONFIG_FSL_LAW
>> > init_laws();
>> >+#endif
>>
>> LAWs are required to be initialized while running on actual boards.
>
>Yes, CONFIG_FSL_LAW is selected by all 85xx SoCs in
>arch/powerpc/cpu/mpc85xx/Kconfig
>
>> For QEMU, may be you can create config like CONFIG_FSL_BYPASS_LAW
>
>Only QEMU does not select CONFIG_FSL_LAW and hence it's a Kconfig option all
>codes that call into functions in FSL_LAW should be wrapped by
>CONFIG_FSL_LAW.
>
>I don't think we should introduce another CONFIG_FSL_BYPASS_LAW for this.
>
>Regards,
>Bin
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 07/38] ppc: qemu: Drop init_laws() and print_laws()
2021-02-18 15:57 ` Bin Meng
` (6 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
-1 siblings, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
These are no longer needed. Drop them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 1d68d30..dba5e0f 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -254,11 +254,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
}
#endif
-void print_laws(void)
-{
- /* We don't emulate LAWs yet */
-}
-
phys_size_t fixed_sdram(void)
{
return get_linear_ram_size();
@@ -302,11 +297,6 @@ void init_tlbs(void)
1024 * 1024, TLB_MAP_RAM));
}
-void init_laws(void)
-{
- /* We don't emulate LAWs yet */
-}
-
static uint32_t get_cpu_freq(void)
{
void *fdt = get_fdt_virt();
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 08/38] ppc: qemu: Drop board_early_init_f()
2021-02-18 15:57 ` Bin Meng
` (7 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:14 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
This function does nothing. Drop it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 5 -----
configs/qemu-ppce500_defconfig | 1 -
2 files changed, 6 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index dba5e0f..4719d98 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -74,11 +74,6 @@ uint64_t get_phys_ccsrbar_addr_early(void)
return r;
}
-int board_early_init_f(void)
-{
- return 0;
-}
-
int checkboard(void)
{
return 0;
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index d17c556..25fcd41 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -10,7 +10,6 @@ CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_BOOTDELAY=1
# CONFIG_DISPLAY_BOARDINFO is not set
-CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_LAST_STAGE_INIT=y
# CONFIG_MISC_INIT_R is not set
CONFIG_HUSH_PARSER=y
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 08/38] ppc: qemu: Drop board_early_init_f()
2021-02-18 15:57 ` [PATCH v2 08/38] ppc: qemu: Drop board_early_init_f() Bin Meng
@ 2021-02-22 8:14 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:14 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 08/38] ppc: qemu: Drop board_early_init_f()
>
>This function does nothing. Drop it.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 5 -----
> configs/qemu-ppce500_defconfig | 1 -
> 2 files changed, 6 deletions(-)
>
>diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c
>b/board/freescale/qemu-ppce500/qemu-ppce500.c
>index dba5e0f..4719d98 100644
>--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
>+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
>@@ -74,11 +74,6 @@ uint64_t get_phys_ccsrbar_addr_early(void)
> return r;
> }
>
>-int board_early_init_f(void)
>-{
>- return 0;
>-}
>-
> int checkboard(void)
> {
> return 0;
>diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-
>ppce500_defconfig index d17c556..25fcd41 100644
>--- a/configs/qemu-ppce500_defconfig
>+++ b/configs/qemu-ppce500_defconfig
>@@ -10,7 +10,6 @@ CONFIG_OF_BOARD_SETUP=y
>CONFIG_OF_STDOUT_VIA_ALIAS=y
> CONFIG_BOOTDELAY=1
> # CONFIG_DISPLAY_BOARDINFO is not set
>-CONFIG_BOARD_EARLY_INIT_F=y
> CONFIG_LAST_STAGE_INIT=y
> # CONFIG_MISC_INIT_R is not set
> CONFIG_HUSH_PARSER=y
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 09/38] ppc: qemu: Enable OF_CONTROL
2021-02-18 15:57 ` Bin Meng
` (8 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:14 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
The QEMU ppce500 machine generates a device tree blob and passes
it to U-Boot during boot. Let's enable OF_CONTROL with OF_BOARD
and provide board_fdt_blob_setup() in the board codes.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 10 ++++++++++
configs/qemu-ppce500_defconfig | 3 ++-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 4719d98..50167d5 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -364,3 +364,13 @@ u32 cpu_mask(void)
{
return (1 << cpu_numcores()) - 1;
}
+
+/**
+ * Return the virtual address of FDT that was passed by QEMU
+ *
+ * @return virtual address of FDT received from QEMU in r3 register
+ */
+void *board_fdt_blob_setup(void)
+{
+ return get_fdt_virt();
+}
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 25fcd41..4522e18 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -22,6 +22,8 @@ CONFIG_CMD_PING=y
# CONFIG_CMD_HASH is not set
CONFIG_CMD_EXT2=y
CONFIG_DOS_PARTITION=y
+CONFIG_OF_CONTROL=y
+CONFIG_OF_BOARD=y
CONFIG_ENV_OVERWRITE=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
# CONFIG_MMC is not set
@@ -29,4 +31,3 @@ CONFIG_E1000=y
CONFIG_SYS_NS16550=y
CONFIG_ADDR_MAP=y
CONFIG_PANIC_HANG=y
-CONFIG_OF_LIBFDT=y
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 09/38] ppc: qemu: Enable OF_CONTROL
2021-02-18 15:57 ` [PATCH v2 09/38] ppc: qemu: Enable OF_CONTROL Bin Meng
@ 2021-02-22 8:14 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:14 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 09/38] ppc: qemu: Enable OF_CONTROL
>
>The QEMU ppce500 machine generates a device tree blob and passes it to U-
>Boot during boot. Let's enable OF_CONTROL with OF_BOARD and provide
>board_fdt_blob_setup() in the board codes.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 10 ++++++++++
> configs/qemu-ppce500_defconfig | 3 ++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
>diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c
>b/board/freescale/qemu-ppce500/qemu-ppce500.c
>index 4719d98..50167d5 100644
>--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
>+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
>@@ -364,3 +364,13 @@ u32 cpu_mask(void)
> {
> return (1 << cpu_numcores()) - 1;
> }
>+
>+/**
>+ * Return the virtual address of FDT that was passed by QEMU
>+ *
>+ * @return virtual address of FDT received from QEMU in r3 register */
>+void *board_fdt_blob_setup(void) {
>+ return get_fdt_virt();
>+}
>diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-
>ppce500_defconfig index 25fcd41..4522e18 100644
>--- a/configs/qemu-ppce500_defconfig
>+++ b/configs/qemu-ppce500_defconfig
>@@ -22,6 +22,8 @@ CONFIG_CMD_PING=y
> # CONFIG_CMD_HASH is not set
> CONFIG_CMD_EXT2=y
> CONFIG_DOS_PARTITION=y
>+CONFIG_OF_CONTROL=y
>+CONFIG_OF_BOARD=y
> CONFIG_ENV_OVERWRITE=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> # CONFIG_MMC is not set
>@@ -29,4 +31,3 @@ CONFIG_E1000=y
> CONFIG_SYS_NS16550=y
> CONFIG_ADDR_MAP=y
> CONFIG_PANIC_HANG=y
>-CONFIG_OF_LIBFDT=y
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 10/38] ppc: qemu: Enable driver model
2021-02-18 15:57 ` Bin Meng
` (9 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:14 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
At present QEMU ppce500 target has not been migrated to driver model
yet. As a start, let's enable driver model and the 'dm' command.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
configs/qemu-ppce500_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 4522e18..f2a8b83 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -16,6 +16,7 @@ CONFIG_HUSH_PARSER=y
CONFIG_CMD_REGINFO=y
CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GREPENV=y
+CONFIG_CMD_DM=y
CONFIG_CMD_PCI=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
@@ -26,6 +27,7 @@ CONFIG_OF_CONTROL=y
CONFIG_OF_BOARD=y
CONFIG_ENV_OVERWRITE=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM=y
# CONFIG_MMC is not set
CONFIG_E1000=y
CONFIG_SYS_NS16550=y
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 10/38] ppc: qemu: Enable driver model
2021-02-18 15:57 ` [PATCH v2 10/38] ppc: qemu: Enable driver model Bin Meng
@ 2021-02-22 8:14 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:14 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 10/38] ppc: qemu: Enable driver model
>
>At present QEMU ppce500 target has not been migrated to driver model yet.
>As a start, let's enable driver model and the 'dm' command.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> configs/qemu-ppce500_defconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-
>ppce500_defconfig index 4522e18..f2a8b83 100644
>--- a/configs/qemu-ppce500_defconfig
>+++ b/configs/qemu-ppce500_defconfig
>@@ -16,6 +16,7 @@ CONFIG_HUSH_PARSER=y
> CONFIG_CMD_REGINFO=y
> CONFIG_CMD_BOOTZ=y
> CONFIG_CMD_GREPENV=y
>+CONFIG_CMD_DM=y
> CONFIG_CMD_PCI=y
> CONFIG_CMD_DHCP=y
> CONFIG_CMD_PING=y
>@@ -26,6 +27,7 @@ CONFIG_OF_CONTROL=y
> CONFIG_OF_BOARD=y
> CONFIG_ENV_OVERWRITE=y
> CONFIG_SYS_RELOC_GD_ENV_ADDR=y
>+CONFIG_DM=y
> # CONFIG_MMC is not set
> CONFIG_E1000=y
> CONFIG_SYS_NS16550=y
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 11/38] include: Remove extern from addr_map.h
2021-02-18 15:57 ` Bin Meng
` (10 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:16 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
Remove the extern of the header because they are useless.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/addr_map.h | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/addr_map.h b/include/addr_map.h
index d322dd2..85e737d 100644
--- a/include/addr_map.h
+++ b/include/addr_map.h
@@ -8,9 +8,9 @@
#include <asm/types.h>
-extern phys_addr_t addrmap_virt_to_phys(void *vaddr);
-extern void *addrmap_phys_to_virt(phys_addr_t paddr);
-extern void addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr,
- phys_size_t size, int idx);
+phys_addr_t addrmap_virt_to_phys(void *vaddr);
+void *addrmap_phys_to_virt(phys_addr_t paddr);
+void addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr,
+ phys_size_t size, int idx);
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 11/38] include: Remove extern from addr_map.h
2021-02-18 15:57 ` [PATCH v2 11/38] include: Remove extern from addr_map.h Bin Meng
@ 2021-02-22 8:16 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:16 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 11/38] include: Remove extern from addr_map.h
>
>Remove the extern of the header because they are useless.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> include/addr_map.h | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/include/addr_map.h b/include/addr_map.h index
>d322dd2..85e737d 100644
>--- a/include/addr_map.h
>+++ b/include/addr_map.h
>@@ -8,9 +8,9 @@
>
> #include <asm/types.h>
>
>-extern phys_addr_t addrmap_virt_to_phys(void *vaddr); -extern void
>*addrmap_phys_to_virt(phys_addr_t paddr); -extern void
>addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr,
>- phys_size_t size, int idx);
>+phys_addr_t addrmap_virt_to_phys(void *vaddr); void
>+*addrmap_phys_to_virt(phys_addr_t paddr); void
>+addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr,
>+ phys_size_t size, int idx);
>
> #endif
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 12/38] lib: addr_map: Move address_map[] type to the header file
2021-02-18 15:57 ` Bin Meng
` (11 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:17 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
At present address_map[] is static and its type is unknown to external
modules. In preparation to create a command to list its contents, this
patch moves its type definition and declaration to the header file.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
include/addr_map.h | 8 ++++++++
lib/addr_map.c | 6 +-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/addr_map.h b/include/addr_map.h
index 85e737d..55d3a6a 100644
--- a/include/addr_map.h
+++ b/include/addr_map.h
@@ -8,6 +8,14 @@
#include <asm/types.h>
+struct addrmap {
+ phys_addr_t paddr;
+ phys_size_t size;
+ unsigned long vaddr;
+};
+
+extern struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
+
phys_addr_t addrmap_virt_to_phys(void *vaddr);
void *addrmap_phys_to_virt(phys_addr_t paddr);
void addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr,
diff --git a/lib/addr_map.c b/lib/addr_map.c
index 09771f3..fb2ef40 100644
--- a/lib/addr_map.c
+++ b/lib/addr_map.c
@@ -6,11 +6,7 @@
#include <common.h>
#include <addr_map.h>
-static struct {
- phys_addr_t paddr;
- phys_size_t size;
- unsigned long vaddr;
-} address_map[CONFIG_SYS_NUM_ADDR_MAP];
+struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
phys_addr_t addrmap_virt_to_phys(void * vaddr)
{
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 12/38] lib: addr_map: Move address_map[] type to the header file
2021-02-18 15:57 ` [PATCH v2 12/38] lib: addr_map: Move address_map[] type to the header file Bin Meng
@ 2021-02-22 8:17 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:17 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 12/38] lib: addr_map: Move address_map[] type to the
>header file
>
>At present address_map[] is static and its type is unknown to external
>modules. In preparation to create a command to list its contents, this patch
>moves its type definition and declaration to the header file.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> include/addr_map.h | 8 ++++++++
> lib/addr_map.c | 6 +-----
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
>diff --git a/include/addr_map.h b/include/addr_map.h index
>85e737d..55d3a6a 100644
>--- a/include/addr_map.h
>+++ b/include/addr_map.h
>@@ -8,6 +8,14 @@
>
> #include <asm/types.h>
>
>+struct addrmap {
>+ phys_addr_t paddr;
>+ phys_size_t size;
>+ unsigned long vaddr;
>+};
>+
>+extern struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
>+
> phys_addr_t addrmap_virt_to_phys(void *vaddr); void
>*addrmap_phys_to_virt(phys_addr_t paddr); void
>addrmap_set_entry(unsigned long vaddr, phys_addr_t paddr, diff --git
>a/lib/addr_map.c b/lib/addr_map.c index 09771f3..fb2ef40 100644
>--- a/lib/addr_map.c
>+++ b/lib/addr_map.c
>@@ -6,11 +6,7 @@
> #include <common.h>
> #include <addr_map.h>
>
>-static struct {
>- phys_addr_t paddr;
>- phys_size_t size;
>- unsigned long vaddr;
>-} address_map[CONFIG_SYS_NUM_ADDR_MAP];
>+struct addrmap address_map[CONFIG_SYS_NUM_ADDR_MAP];
>
> phys_addr_t addrmap_virt_to_phys(void * vaddr) {
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 13/38] cmd: Add a command to display the address map
2021-02-18 15:57 ` Bin Meng
` (12 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-20 11:54 ` Simon Glass
2021-02-22 8:18 ` Priyanka Jain
-1 siblings, 2 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
This adds a new command 'addrmap' to display the address map for
non-identity virtual-physical memory mappings.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- add doc/usage/addrmap.rst
cmd/Kconfig | 7 +++++++
cmd/Makefile | 1 +
cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++
doc/usage/addrmap.rst | 41 +++++++++++++++++++++++++++++++++++++++++
doc/usage/index.rst | 1 +
5 files changed, 85 insertions(+)
create mode 100644 cmd/addrmap.c
create mode 100644 doc/usage/addrmap.rst
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 928a2a0..2021939 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -97,6 +97,13 @@ config CMD_ACPI
between the firmware and OS, and is particularly useful when you
want to make hardware changes without the OS needing to be adjusted.
+config CMD_ADDRMAP
+ bool "addrmap"
+ depends on ADDR_MAP
+ default y
+ help
+ List non-identity virtual-physical memory mappings for 32-bit CPUs.
+
config CMD_BDI
bool "bdinfo"
default y
diff --git a/cmd/Makefile b/cmd/Makefile
index 176bf92..567e2b7 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -13,6 +13,7 @@ obj-y += version.o
# command
obj-$(CONFIG_CMD_ACPI) += acpi.o
+obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
obj-$(CONFIG_CMD_AES) += aes.o
obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
obj-$(CONFIG_CMD_ADC) += adc.o
diff --git a/cmd/addrmap.c b/cmd/addrmap.c
new file mode 100644
index 0000000..bd23549
--- /dev/null
+++ b/cmd/addrmap.c
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <command.h>
+#include <addr_map.h>
+
+static int do_addrmap(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ int i;
+
+ printf(" vaddr paddr size\n");
+ printf("================ ================ ================\n");
+
+ for (i = 0; i < CONFIG_SYS_NUM_ADDR_MAP; i++) {
+ if (address_map[i].size == 0)
+ continue;
+
+ printf("%16.8lx %16.8llx %16.8llx\n",
+ address_map[i].vaddr,
+ (unsigned long long)address_map[i].paddr,
+ (unsigned long long)address_map[i].size);
+ }
+
+ return 0;
+}
+
+U_BOOT_CMD(
+ addrmap, 1, 1, do_addrmap,
+ "List non-identity virtual-physical memory mappings for 32-bit CPUs",
+ ""
+);
diff --git a/doc/usage/addrmap.rst b/doc/usage/addrmap.rst
new file mode 100644
index 0000000..472fd54
--- /dev/null
+++ b/doc/usage/addrmap.rst
@@ -0,0 +1,41 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+addrmap command
+===============
+
+Synopsis
+--------
+
+::
+
+ addrmap
+
+Description
+-----------
+
+The addrmap command is used to display non-identity virtual-physical memory
+mappings for 32-bit CPUs.
+
+The output may look like:
+
+::
+
+ => addrmap
+ vaddr paddr size
+ ================ ================ ================
+ e0000000 fe0000000 00100000
+ 00000000 00000000 04000000
+ 04000000 04000000 04000000
+ 80000000 c00000000 10000000
+ 90000000 c10000000 10000000
+ a0000000 fe1000000 00010000
+
+The first column indicates the virtual address.
+The second column indicates the physical address.
+The third column indicates the mapped size.
+
+Configuration
+-------------
+
+To use the addrmap command you must specify CONFIG_CMD_ADDRMAP=y.
+It is automatically turned on when CONFIG_ADDR_MAP is set.
diff --git a/doc/usage/index.rst b/doc/usage/index.rst
index 5754958..fe752cc 100644
--- a/doc/usage/index.rst
+++ b/doc/usage/index.rst
@@ -13,6 +13,7 @@ Shell commands
.. toctree::
:maxdepth: 1
+ addrmap
base
bootefi
bootmenu
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 13/38] cmd: Add a command to display the address map
2021-02-18 15:57 ` [PATCH v2 13/38] cmd: Add a command to display the address map Bin Meng
@ 2021-02-20 11:54 ` Simon Glass
2021-02-22 8:18 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Simon Glass @ 2021-02-20 11:54 UTC (permalink / raw)
To: u-boot
On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> This adds a new command 'addrmap' to display the address map for
> non-identity virtual-physical memory mappings.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - add doc/usage/addrmap.rst
>
> cmd/Kconfig | 7 +++++++
> cmd/Makefile | 1 +
> cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++
> doc/usage/addrmap.rst | 41 +++++++++++++++++++++++++++++++++++++++++
> doc/usage/index.rst | 1 +
> 5 files changed, 85 insertions(+)
> create mode 100644 cmd/addrmap.c
> create mode 100644 doc/usage/addrmap.rst
>
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 13/38] cmd: Add a command to display the address map
2021-02-18 15:57 ` [PATCH v2 13/38] cmd: Add a command to display the address map Bin Meng
2021-02-20 11:54 ` Simon Glass
@ 2021-02-22 8:18 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:18 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>; Marek Szyprowski <m.szyprowski@samsung.com>;
>Matthias Brugger <mbrugger@suse.com>
>Subject: [PATCH v2 13/38] cmd: Add a command to display the address map
>
>This adds a new command 'addrmap' to display the address map for non-
>identity virtual-physical memory mappings.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- add doc/usage/addrmap.rst
>
> cmd/Kconfig | 7 +++++++
> cmd/Makefile | 1 +
> cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++
> doc/usage/addrmap.rst | 41
>+++++++++++++++++++++++++++++++++++++++++
> doc/usage/index.rst | 1 +
> 5 files changed, 85 insertions(+)
> create mode 100644 cmd/addrmap.c
> create mode 100644 doc/usage/addrmap.rst
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-18 15:57 ` Bin Meng
` (13 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-20 11:54 ` Simon Glass
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
This adds a basic test for the newly introduced 'addrmap' command.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: test: cmd: Add a basic test for 'addrmap' command
include/test/suites.h | 2 ++
test/cmd/Makefile | 1 +
test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
test/cmd_ut.c | 6 ++++++
4 files changed, 47 insertions(+)
create mode 100644 test/cmd/addrmap.c
diff --git a/include/test/suites.h b/include/test/suites.h
index 52e8fc8..f5d8e13 100644
--- a/include/test/suites.h
+++ b/include/test/suites.h
@@ -26,6 +26,8 @@ int cmd_ut_category(const char *name, const char *prefix,
struct unit_test *tests, int n_ents,
int argc, char *const argv[]);
+int do_ut_addrmap(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[]);
int do_ut_bootm(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[]);
int do_ut_bloblist(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[]);
diff --git a/test/cmd/Makefile b/test/cmd/Makefile
index 5451e9e..8699976 100644
--- a/test/cmd/Makefile
+++ b/test/cmd/Makefile
@@ -6,6 +6,7 @@ ifdef CONFIG_HUSH_PARSER
obj-$(CONFIG_CONSOLE_RECORD) += test_echo.o
endif
obj-y += mem.o
+obj-$(CONFIG_CMD_ADDRMAP) += addrmap.o
obj-$(CONFIG_CMD_MEM_SEARCH) += mem_search.o
obj-$(CONFIG_CMD_PWM) += pwm.o
obj-y += setexpr.o
diff --git a/test/cmd/addrmap.c b/test/cmd/addrmap.c
new file mode 100644
index 0000000..fb74448
--- /dev/null
+++ b/test/cmd/addrmap.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Tests for addrmap command
+ *
+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+#include <common.h>
+#include <console.h>
+#include <test/suites.h>
+#include <test/ut.h>
+
+/* Declare a new addrmap test */
+#define ADDRMAP_TEST(_name, _flags) UNIT_TEST(_name, _flags, addrmap_test)
+
+/* Test 'addrmap' command output */
+static int addrmap_test_basic(struct unit_test_state *uts)
+{
+ ut_assertok(console_record_reset_enable());
+ ut_assertok(run_command("addrmap", 0));
+ ut_assert_nextline(" vaddr paddr size");
+ ut_assert_nextline("================ ================ ================");
+ /* There should be at least one entry */
+ ut_assertok(!ut_check_console_end(uts));
+
+ return 0;
+}
+ADDRMAP_TEST(addrmap_test_basic, UT_TESTF_CONSOLE_REC);
+
+int do_ut_addrmap(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
+{
+ struct unit_test *tests = ll_entry_start(struct unit_test,
+ addrmap_test);
+ const int n_ents = ll_entry_count(struct unit_test, addrmap_test);
+
+ return cmd_ut_category("cmd_addrmap", "cmd_addrmap_", tests, n_ents,
+ argc, argv);
+}
diff --git a/test/cmd_ut.c b/test/cmd_ut.c
index 90674d5..8404309 100644
--- a/test/cmd_ut.c
+++ b/test/cmd_ut.c
@@ -91,6 +91,9 @@ static struct cmd_tbl cmd_ut_sub[] = {
U_BOOT_CMD_MKENT(bootm, CONFIG_SYS_MAXARGS, 1, do_ut_bootm, "", ""),
#endif
U_BOOT_CMD_MKENT(str, CONFIG_SYS_MAXARGS, 1, do_ut_str, "", ""),
+#ifdef CONFIG_CMD_ADDRMAP
+ U_BOOT_CMD_MKENT(addrmap, CONFIG_SYS_MAXARGS, 1, do_ut_addrmap, "", ""),
+#endif
};
static int do_ut_all(struct cmd_tbl *cmdtp, int flag, int argc,
@@ -166,6 +169,9 @@ static char ut_help_text[] =
!defined(CONFIG_SPL_BUILD) && !defined(API_BUILD)
"ut unicode [test-name] - test Unicode functions\n"
#endif
+#ifdef CONFIG_CMD_ADDRMAP
+ "ut addrmap - Very basic test of addrmap command\n"
+#endif
;
#endif /* CONFIG_SYS_LONGHELP */
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-18 15:57 ` [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command Bin Meng
@ 2021-02-20 11:54 ` Simon Glass
2021-02-20 13:01 ` Bin Meng
0 siblings, 1 reply; 96+ messages in thread
From: Simon Glass @ 2021-02-20 11:54 UTC (permalink / raw)
To: u-boot
On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> This adds a basic test for the newly introduced 'addrmap' command.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - new patch: test: cmd: Add a basic test for 'addrmap' command
>
> include/test/suites.h | 2 ++
> test/cmd/Makefile | 1 +
> test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> test/cmd_ut.c | 6 ++++++
> 4 files changed, 47 insertions(+)
> create mode 100644 test/cmd/addrmap.c
Reviewed-by: Simon Glass <sjg@chromium.org>
Just checking this test is enabled for sandbox?
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-20 11:54 ` Simon Glass
@ 2021-02-20 13:01 ` Bin Meng
2021-02-21 16:24 ` Simon Glass
0 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-20 13:01 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Sat, Feb 20, 2021 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
>
> On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > This adds a basic test for the newly introduced 'addrmap' command.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >
> > ---
> >
> > Changes in v2:
> > - new patch: test: cmd: Add a basic test for 'addrmap' command
> >
> > include/test/suites.h | 2 ++
> > test/cmd/Makefile | 1 +
> > test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> > test/cmd_ut.c | 6 ++++++
> > 4 files changed, 47 insertions(+)
> > create mode 100644 test/cmd/addrmap.c
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> Just checking this test is enabled for sandbox?
Not yet. I don't think sandbox has enabled CONFIG_ADDR_MAP.
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-20 13:01 ` Bin Meng
@ 2021-02-21 16:24 ` Simon Glass
2021-02-22 1:55 ` Bin Meng
0 siblings, 1 reply; 96+ messages in thread
From: Simon Glass @ 2021-02-21 16:24 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Sat, 20 Feb 2021 at 06:01, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Sat, Feb 20, 2021 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > This adds a basic test for the newly introduced 'addrmap' command.
> > >
> > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > >
> > > ---
> > >
> > > Changes in v2:
> > > - new patch: test: cmd: Add a basic test for 'addrmap' command
> > >
> > > include/test/suites.h | 2 ++
> > > test/cmd/Makefile | 1 +
> > > test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > test/cmd_ut.c | 6 ++++++
> > > 4 files changed, 47 insertions(+)
> > > create mode 100644 test/cmd/addrmap.c
> >
> > Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > Just checking this test is enabled for sandbox?
>
> Not yet. I don't think sandbox has enabled CONFIG_ADDR_MAP.
OK then can you please enable it so we have test coverage?
Regards,
Simon
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-21 16:24 ` Simon Glass
@ 2021-02-22 1:55 ` Bin Meng
2021-02-22 9:20 ` Simon Glass
0 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-22 1:55 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Feb 22, 2021 at 12:24 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Sat, 20 Feb 2021 at 06:01, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Sat, Feb 20, 2021 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > This adds a basic test for the newly introduced 'addrmap' command.
> > > >
> > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > >
> > > > ---
> > > >
> > > > Changes in v2:
> > > > - new patch: test: cmd: Add a basic test for 'addrmap' command
> > > >
> > > > include/test/suites.h | 2 ++
> > > > test/cmd/Makefile | 1 +
> > > > test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > > test/cmd_ut.c | 6 ++++++
> > > > 4 files changed, 47 insertions(+)
> > > > create mode 100644 test/cmd/addrmap.c
> > >
> > > Reviewed-by: Simon Glass <sjg@chromium.org>
> > >
> > > Just checking this test is enabled for sandbox?
> >
> > Not yet. I don't think sandbox has enabled CONFIG_ADDR_MAP.
>
> OK then can you please enable it so we have test coverage?
I am not sure if Sandbox can support CONFIG_ADDR_MAP (non-identity
virtual-physical mapping)?
As Tom mentioned here [1], enabling unit tests on QEMU targets makes more sense?
[1] https://lists.denx.de/pipermail/u-boot/2021-February/441779.html
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-22 1:55 ` Bin Meng
@ 2021-02-22 9:20 ` Simon Glass
2021-02-22 12:13 ` Bin Meng
2021-02-22 14:00 ` Tom Rini
0 siblings, 2 replies; 96+ messages in thread
From: Simon Glass @ 2021-02-22 9:20 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Sun, 21 Feb 2021 at 18:55, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Mon, Feb 22, 2021 at 12:24 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sat, 20 Feb 2021 at 06:01, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sat, Feb 20, 2021 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > This adds a basic test for the newly introduced 'addrmap' command.
> > > > >
> > > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > > >
> > > > > ---
> > > > >
> > > > > Changes in v2:
> > > > > - new patch: test: cmd: Add a basic test for 'addrmap' command
> > > > >
> > > > > include/test/suites.h | 2 ++
> > > > > test/cmd/Makefile | 1 +
> > > > > test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > > > test/cmd_ut.c | 6 ++++++
> > > > > 4 files changed, 47 insertions(+)
> > > > > create mode 100644 test/cmd/addrmap.c
> > > >
> > > > Reviewed-by: Simon Glass <sjg@chromium.org>
> > > >
> > > > Just checking this test is enabled for sandbox?
> > >
> > > Not yet. I don't think sandbox has enabled CONFIG_ADDR_MAP.
> >
> > OK then can you please enable it so we have test coverage?
>
> I am not sure if Sandbox can support CONFIG_ADDR_MAP (non-identity
> virtual-physical mapping)?
Well it doesn't even really need to support it fully. Just adding the
config and writing a test that sets a few entries and checks the
functions in addrmap.h do the right thing should be enough. It should
be 10 lines of code.
>
> As Tom mentioned here [1], enabling unit tests on QEMU targets makes more sense?
>
> [1] https://lists.denx.de/pipermail/u-boot/2021-February/441779.html
That was referring to a qemu-specific feature (called into qemu,
actually). But in this case, if there is a failure, how will someone
diagnose it? Run a huge functional test with qemu to see that it fails
somewhere...? I think unit tests are far more useful for little
features.
Regards,
SImon
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-22 9:20 ` Simon Glass
@ 2021-02-22 12:13 ` Bin Meng
2021-02-22 14:00 ` Tom Rini
1 sibling, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-22 12:13 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Feb 22, 2021 at 5:20 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Sun, 21 Feb 2021 at 18:55, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Mon, Feb 22, 2021 at 12:24 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Sat, 20 Feb 2021 at 06:01, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sat, Feb 20, 2021 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > This adds a basic test for the newly introduced 'addrmap' command.
> > > > > >
> > > > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > Changes in v2:
> > > > > > - new patch: test: cmd: Add a basic test for 'addrmap' command
> > > > > >
> > > > > > include/test/suites.h | 2 ++
> > > > > > test/cmd/Makefile | 1 +
> > > > > > test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > > > > test/cmd_ut.c | 6 ++++++
> > > > > > 4 files changed, 47 insertions(+)
> > > > > > create mode 100644 test/cmd/addrmap.c
> > > > >
> > > > > Reviewed-by: Simon Glass <sjg@chromium.org>
> > > > >
> > > > > Just checking this test is enabled for sandbox?
> > > >
> > > > Not yet. I don't think sandbox has enabled CONFIG_ADDR_MAP.
> > >
> > > OK then can you please enable it so we have test coverage?
> >
> > I am not sure if Sandbox can support CONFIG_ADDR_MAP (non-identity
> > virtual-physical mapping)?
>
> Well it doesn't even really need to support it fully. Just adding the
> config and writing a test that sets a few entries and checks the
> functions in addrmap.h do the right thing should be enough. It should
> be 10 lines of code.
>
This sounds like another patch to test the library itself instead of
the command only. I think we can add the library testing in future
patches given Priyanka has reviewed almost all patches in this series.
> >
> > As Tom mentioned here [1], enabling unit tests on QEMU targets makes more sense?
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2021-February/441779.html
>
> That was referring to a qemu-specific feature (called into qemu,
> actually). But in this case, if there is a failure, how will someone
> diagnose it? Run a huge functional test with qemu to see that it fails
> somewhere...? I think unit tests are far more useful for little
> features.
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 14/38] test: cmd: Add a basic test for 'addrmap' command
2021-02-22 9:20 ` Simon Glass
2021-02-22 12:13 ` Bin Meng
@ 2021-02-22 14:00 ` Tom Rini
1 sibling, 0 replies; 96+ messages in thread
From: Tom Rini @ 2021-02-22 14:00 UTC (permalink / raw)
To: u-boot
On Mon, Feb 22, 2021 at 02:20:35AM -0700, Simon Glass wrote:
> Hi Bin,
>
> On Sun, 21 Feb 2021 at 18:55, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Simon,
> >
> > On Mon, Feb 22, 2021 at 12:24 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Sat, 20 Feb 2021 at 06:01, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Sat, Feb 20, 2021 at 7:55 PM Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > On Thu, 18 Feb 2021 at 08:59, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > >
> > > > > > This adds a basic test for the newly introduced 'addrmap' command.
> > > > > >
> > > > > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > > > >
> > > > > > ---
> > > > > >
> > > > > > Changes in v2:
> > > > > > - new patch: test: cmd: Add a basic test for 'addrmap' command
> > > > > >
> > > > > > include/test/suites.h | 2 ++
> > > > > > test/cmd/Makefile | 1 +
> > > > > > test/cmd/addrmap.c | 38 ++++++++++++++++++++++++++++++++++++++
> > > > > > test/cmd_ut.c | 6 ++++++
> > > > > > 4 files changed, 47 insertions(+)
> > > > > > create mode 100644 test/cmd/addrmap.c
> > > > >
> > > > > Reviewed-by: Simon Glass <sjg@chromium.org>
> > > > >
> > > > > Just checking this test is enabled for sandbox?
> > > >
> > > > Not yet. I don't think sandbox has enabled CONFIG_ADDR_MAP.
> > >
> > > OK then can you please enable it so we have test coverage?
> >
> > I am not sure if Sandbox can support CONFIG_ADDR_MAP (non-identity
> > virtual-physical mapping)?
>
> Well it doesn't even really need to support it fully. Just adding the
> config and writing a test that sets a few entries and checks the
> functions in addrmap.h do the right thing should be enough. It should
> be 10 lines of code.
>
> >
> > As Tom mentioned here [1], enabling unit tests on QEMU targets makes more sense?
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2021-February/441779.html
>
> That was referring to a qemu-specific feature (called into qemu,
> actually). But in this case, if there is a failure, how will someone
> diagnose it? Run a huge functional test with qemu to see that it fails
> somewhere...? I think unit tests are far more useful for little
> features.
So, we have a few different forms of checking. We have "make check",
"make qcheck" and make "tcheck", which are handy for running pytest on
sandbox and some of the test suites to our tools. We also have CI
running (I believe) all of the same tests as "make check", and then also
running pytest on a number of emulated platforms. We also have
infrequent static code analysis via Coverity scan, based on sandbox
builds. So it's good that anything that can be built on sandbox is
built on sandbox. But when it comes to pytests, the line of where to
run what is a lot fuzzier. addrmap should have a test, and it should be
run on whatever qemu platforms it can be tested on, and it will be
tested frequently in CI.
In the end, looking at the test we have here now too, I suppose yes, if
it's only 10 lines of code so that addrmap compiles for sandbox (for
static testing) and then this test runs/passes, we should do that, it's
fine and good to, yes.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210222/28c1252d/attachment.sig>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 15/38] lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help
2021-02-18 15:57 ` Bin Meng
` (14 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:19 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
Mention that CONFIG_ADDR_MAP only works in the post-relocation phase.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
lib/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/Kconfig b/lib/Kconfig
index 7f4c30e..7288340 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -6,6 +6,8 @@ config ADDR_MAP
Enables helper code for implementing non-identity virtual-physical
memory mappings for 32bit CPUs.
+ This library only works in the post-relocation phase.
+
config SYS_NUM_ADDR_MAP
int "Size of the address-map table"
depends on ADDR_MAP
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 15/38] lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help
2021-02-18 15:57 ` [PATCH v2 15/38] lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help Bin Meng
@ 2021-02-22 8:19 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:19 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 15/38] lib: kconfig: Mention CONFIG_ADDR_MAP
>limitation in the help
>
>Mention that CONFIG_ADDR_MAP only works in the post-relocation phase.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> lib/Kconfig | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/lib/Kconfig b/lib/Kconfig
>index 7f4c30e..7288340 100644
>--- a/lib/Kconfig
>+++ b/lib/Kconfig
>@@ -6,6 +6,8 @@ config ADDR_MAP
> Enables helper code for implementing non-identity virtual-physical
> memory mappings for 32bit CPUs.
>
>+ This library only works in the post-relocation phase.
>+
> config SYS_NUM_ADDR_MAP
> int "Size of the address-map table"
> depends on ADDR_MAP
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 16/38] ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase
2021-02-18 15:57 ` Bin Meng
` (15 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 8:55 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
In phys_to_virt() and virt_to_phys(), if CONFIG_ADDR_MAP is defined,
they use addrmap_ translation APIs to do the address translation.
However these APIs only work in post-relocation phase.
Update the code logic to fall back to use the default one when in
pre-relocation phase.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/powerpc/include/asm/io.h | 15 +++++++++------
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 6d76e3e..998a82a 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -10,7 +10,10 @@
#include <asm/byteorder.h>
#ifdef CONFIG_ADDR_MAP
+#include <asm/global_data.h>
#include <addr_map.h>
+
+DECLARE_GLOBAL_DATA_PTR;
#endif
#define SIO_CONFIG_RA 0x398
@@ -303,20 +306,20 @@ static inline void out_be32(volatile unsigned __iomem *addr, u32 val)
static inline void *phys_to_virt(phys_addr_t paddr)
{
#ifdef CONFIG_ADDR_MAP
- return addrmap_phys_to_virt(paddr);
-#else
- return (void *)((unsigned long)paddr);
+ if (gd->flags & GD_FLG_RELOC)
+ return addrmap_phys_to_virt(paddr);
#endif
+ return (void *)((unsigned long)paddr);
}
#define phys_to_virt phys_to_virt
static inline phys_addr_t virt_to_phys(void * vaddr)
{
#ifdef CONFIG_ADDR_MAP
- return addrmap_virt_to_phys(vaddr);
-#else
- return (phys_addr_t)((unsigned long)vaddr);
+ if (gd->flags & GD_FLG_RELOC)
+ return addrmap_virt_to_phys(vaddr);
#endif
+ return (phys_addr_t)((unsigned long)vaddr);
}
#define virt_to_phys virt_to_phys
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 16/38] ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase
2021-02-18 15:57 ` [PATCH v2 16/38] ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase Bin Meng
@ 2021-02-22 8:55 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 8:55 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 16/38] ppc: io.h: Use addrmap_ translation APIs only in
>post-relocation phase
>
>In phys_to_virt() and virt_to_phys(), if CONFIG_ADDR_MAP is defined, they
>use addrmap_ translation APIs to do the address translation.
>However these APIs only work in post-relocation phase.
>
>Update the code logic to fall back to use the default one when in pre-
>relocation phase.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> arch/powerpc/include/asm/io.h | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 17/38] common: Move initr_addr_map() to a bit earlier
2021-02-18 15:57 ` Bin Meng
` (16 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:05 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
At present initr_addr_map() is put at a late stage in the
init_sequence_r[] calls. This won't work because lot of
device driver initialization (e.g.: serial port) happens
before it but is lack of the address translation support.
This moves the call to a bit earlier, right after the DM
initialization.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
common/board_r.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/common/board_r.c b/common/board_r.c
index 9793439..c835ff8 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -626,6 +626,9 @@ static init_fnc_t init_sequence_r[] = {
#ifdef CONFIG_DM
initr_dm,
#endif
+#ifdef CONFIG_ADDR_MAP
+ initr_addr_map,
+#endif
#if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \
defined(CONFIG_SANDBOX)
board_init, /* Setup chipselects */
@@ -661,9 +664,6 @@ static init_fnc_t init_sequence_r[] = {
initr_manual_reloc_cmdtable,
#endif
arch_initr_trap,
-#ifdef CONFIG_ADDR_MAP
- initr_addr_map,
-#endif
#if defined(CONFIG_BOARD_EARLY_INIT_R)
board_early_init_r,
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 17/38] common: Move initr_addr_map() to a bit earlier
2021-02-18 15:57 ` [PATCH v2 17/38] common: Move initr_addr_map() to a bit earlier Bin Meng
@ 2021-02-22 9:05 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:05 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>; Marek Szyprowski <m.szyprowski@samsung.com>;
>Matthias Brugger <mbrugger@suse.com>
>Subject: [PATCH v2 17/38] common: Move initr_addr_map() to a bit earlier
>
>At present initr_addr_map() is put at a late stage in the init_sequence_r[] calls.
>This won't work because lot of device driver initialization (e.g.: serial port)
>happens before it but is lack of the address translation support.
>
>This moves the call to a bit earlier, right after the DM initialization.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> common/board_r.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 18/38] ppc: qemu: Switch over to use DM serial
2021-02-18 15:57 ` Bin Meng
` (17 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:05 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
The QEMU ppce500 target integrates 2 NS16550 serial ports. Switch
over to use the DM version of the driver by:
- drop unnecessary ad-hoc config macros
- add get_serial_clock() in the board codes
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 6 ++++++
configs/qemu-ppce500_defconfig | 1 +
include/configs/qemu-ppce500.h | 10 ----------
3 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 50167d5..db13582 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -374,3 +374,9 @@ void *board_fdt_blob_setup(void)
{
return get_fdt_virt();
}
+
+/* See CONFIG_SYS_NS16550_CLK in arch/powerpc/include/asm/config.h */
+int get_serial_clock(void)
+{
+ return get_bus_freq(0);
+}
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index f2a8b83..c528a68 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -30,6 +30,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
# CONFIG_MMC is not set
CONFIG_E1000=y
+CONFIG_DM_SERIAL=y
CONFIG_SYS_NS16550=y
CONFIG_ADDR_MAP=y
CONFIG_PANIC_HANG=y
diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h
index f13e4ea..feac6ef 100644
--- a/include/configs/qemu-ppce500.h
+++ b/include/configs/qemu-ppce500.h
@@ -73,16 +73,6 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void);
#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
#define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024)
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE 1
-#define CONFIG_SYS_NS16550_CLK (get_bus_freq(0))
-
-#define CONFIG_SYS_BAUDRATE_TABLE \
- {300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200}
-
-#define CONFIG_SYS_NS16550_COM1 (CONFIG_SYS_CCSRBAR+0x4500)
-#define CONFIG_SYS_NS16550_COM2 (CONFIG_SYS_CCSRBAR+0x4600)
-
/*
* General PCI
* Memory space is mapped 1-1, but I/O space must start from 0.
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 18/38] ppc: qemu: Switch over to use DM serial
2021-02-18 15:57 ` [PATCH v2 18/38] ppc: qemu: Switch over to use DM serial Bin Meng
@ 2021-02-22 9:05 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:05 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 18/38] ppc: qemu: Switch over to use DM serial
>
>The QEMU ppce500 target integrates 2 NS16550 serial ports. Switch over to
>use the DM version of the driver by:
>
>- drop unnecessary ad-hoc config macros
>- add get_serial_clock() in the board codes
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 6 ++++++
> configs/qemu-ppce500_defconfig | 1 +
> include/configs/qemu-ppce500.h | 10 ----------
> 3 files changed, 7 insertions(+), 10 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
2021-02-18 15:57 ` Bin Meng
` (18 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-21 7:06 ` Heiko Schocher
2021-02-22 9:06 ` Priyanka Jain
-1 siblings, 2 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
For the QEMU ppce500 machine, LAW registers are not implemented
hence CONFIG_FSL_LAW is not turned on and all LAW APIs are not
available. We should wrap all LAW registers programming in the
mpc85xx PCI driver with CONFIG_FSL_LAW.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
drivers/pci/pci_mpc85xx.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c
index ab6ff45..7387a1e 100644
--- a/drivers/pci/pci_mpc85xx.c
+++ b/drivers/pci/pci_mpc85xx.c
@@ -46,6 +46,7 @@ static int mpc85xx_pci_dm_write_config(struct udevice *dev, pci_dev_t bdf,
return 0;
}
+#ifdef CONFIG_FSL_LAW
static int
mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem,
struct pci_region *pre)
@@ -68,6 +69,7 @@ mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem,
return 0;
}
+#endif
static int mpc85xx_pci_dm_probe(struct udevice *dev)
{
@@ -85,7 +87,9 @@ static int mpc85xx_pci_dm_probe(struct udevice *dev)
return -EINVAL;
}
+#ifdef CONFIG_FSL_LAW
mpc85xx_pci_dm_setup_laws(io, mem, pre);
+#endif
pcix = priv->cfg_addr;
/* BAR 1: memory */
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
2021-02-18 15:57 ` [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW Bin Meng
@ 2021-02-21 7:06 ` Heiko Schocher
2021-02-22 9:06 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Heiko Schocher @ 2021-02-21 7:06 UTC (permalink / raw)
To: u-boot
Hello Bin,
On 18.02.21 16:57, Bin Meng wrote:
> For the QEMU ppce500 machine, LAW registers are not implemented
> hence CONFIG_FSL_LAW is not turned on and all LAW APIs are not
> available. We should wrap all LAW registers programming in the
> mpc85xx PCI driver with CONFIG_FSL_LAW.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> (no changes since v1)
>
> drivers/pci/pci_mpc85xx.c | 4 ++++
> 1 file changed, 4 insertions(+)
Reviewed-by: Heiko Schocher <hs@denx.de>
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
2021-02-18 15:57 ` [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW Bin Meng
2021-02-21 7:06 ` Heiko Schocher
@ 2021-02-22 9:06 ` Priyanka Jain
2021-02-22 12:10 ` Bin Meng
1 sibling, 1 reply; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:06 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>; Heiko Schocher <hs@denx.de>
>Subject: [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with
>CONFIG_FSL_LAW
>
>For the QEMU ppce500 machine, LAW registers are not implemented hence
>CONFIG_FSL_LAW is not turned on and all LAW APIs are not available. We
>should wrap all LAW registers programming in the mpc85xx PCI driver with
>CONFIG_FSL_LAW.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> drivers/pci/pci_mpc85xx.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
>diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c index
>ab6ff45..7387a1e 100644
>--- a/drivers/pci/pci_mpc85xx.c
>+++ b/drivers/pci/pci_mpc85xx.c
>@@ -46,6 +46,7 @@ static int mpc85xx_pci_dm_write_config(struct udevice
>*dev, pci_dev_t bdf,
> return 0;
> }
>
>+#ifdef CONFIG_FSL_LAW
> static int
> mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem,
> struct pci_region *pre)
>@@ -68,6 +69,7 @@ mpc85xx_pci_dm_setup_laws(struct pci_region *io,
>struct pci_region *mem,
>
> return 0;
> }
>+#endif
>
> static int mpc85xx_pci_dm_probe(struct udevice *dev) { @@ -85,7 +87,9
>@@ static int mpc85xx_pci_dm_probe(struct udevice *dev)
> return -EINVAL;
> }
>
>+#ifdef CONFIG_FSL_LAW
> mpc85xx_pci_dm_setup_laws(io, mem, pre);
>+#endif
>
> pcix = priv->cfg_addr;
> /* BAR 1: memory */
>--
>2.7.4
LAWs are required to be initialized while running on actual boards.
For QEMU, may be you can create config like CONFIG_FSL_BYPASS_LAW
Priyanka
<snip>
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
2021-02-22 9:06 ` Priyanka Jain
@ 2021-02-22 12:10 ` Bin Meng
2021-02-23 10:43 ` Priyanka Jain
0 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-22 12:10 UTC (permalink / raw)
To: u-boot
Hi Priyanka,
On Mon, Feb 22, 2021 at 5:06 PM Priyanka Jain <priyanka.jain@nxp.com> wrote:
>
>
>
> >-----Original Message-----
> >From: Bin Meng <bmeng.cn@gmail.com>
> >Sent: Thursday, February 18, 2021 9:28 PM
> >To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
> >Priyanka Jain <priyanka.jain@nxp.com>
> >Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
> ><trini@konsulko.com>; Heiko Schocher <hs@denx.de>
> >Subject: [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with
> >CONFIG_FSL_LAW
> >
> >For the QEMU ppce500 machine, LAW registers are not implemented hence
> >CONFIG_FSL_LAW is not turned on and all LAW APIs are not available. We
> >should wrap all LAW registers programming in the mpc85xx PCI driver with
> >CONFIG_FSL_LAW.
> >
> >Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> >---
> >
> >(no changes since v1)
> >
> > drivers/pci/pci_mpc85xx.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> >diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c index
> >ab6ff45..7387a1e 100644
> >--- a/drivers/pci/pci_mpc85xx.c
> >+++ b/drivers/pci/pci_mpc85xx.c
> >@@ -46,6 +46,7 @@ static int mpc85xx_pci_dm_write_config(struct udevice
> >*dev, pci_dev_t bdf,
> > return 0;
> > }
> >
> >+#ifdef CONFIG_FSL_LAW
> > static int
> > mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem,
> > struct pci_region *pre)
> >@@ -68,6 +69,7 @@ mpc85xx_pci_dm_setup_laws(struct pci_region *io,
> >struct pci_region *mem,
> >
> > return 0;
> > }
> >+#endif
> >
> > static int mpc85xx_pci_dm_probe(struct udevice *dev) { @@ -85,7 +87,9
> >@@ static int mpc85xx_pci_dm_probe(struct udevice *dev)
> > return -EINVAL;
> > }
> >
> >+#ifdef CONFIG_FSL_LAW
> > mpc85xx_pci_dm_setup_laws(io, mem, pre);
> >+#endif
> >
> > pcix = priv->cfg_addr;
> > /* BAR 1: memory */
> >--
> >2.7.4
>
> LAWs are required to be initialized while running on actual boards.
> For QEMU, may be you can create config like CONFIG_FSL_BYPASS_LAW
>
As I mentioned in [1], CONFIG_FSL_LAW is already a Kconfig option and
all 85xx SoCs have selected this config except QEMU, hence I don't
think we need to create another config like CONFIG_FSL_BYPASS_LAW.
[1] https://lists.denx.de/pipermail/u-boot/2021-February/441907.html
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
2021-02-22 12:10 ` Bin Meng
@ 2021-02-23 10:43 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-23 10:43 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: U-Boot <u-boot-bounces@lists.denx.de> On Behalf Of Bin Meng
>Sent: Monday, February 22, 2021 5:41 PM
>To: Priyanka Jain <priyanka.jain@nxp.com>
>Cc: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>; U-
>Boot Mailing List <u-boot@lists.denx.de>; Tom Rini <trini@konsulko.com>; Heiko
>Schocher <hs@denx.de>
>Subject: Re: [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with
>CONFIG_FSL_LAW
>
>Hi Priyanka,
>
>On Mon, Feb 22, 2021 at 5:06 PM Priyanka Jain <priyanka.jain@nxp.com> wrote:
>>
>>
>>
>> >-----Original Message-----
>> >From: Bin Meng <bmeng.cn@gmail.com>
>> >Sent: Thursday, February 18, 2021 9:28 PM
>> >To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>> >Priyanka Jain <priyanka.jain@nxp.com>
>> >Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
>> ><trini@konsulko.com>; Heiko Schocher <hs@denx.de>
>> >Subject: [PATCH v2 19/38] pci: mpc85xx: Wrap LAW programming with
>> >CONFIG_FSL_LAW
>> >
>> >For the QEMU ppce500 machine, LAW registers are not implemented hence
>> >CONFIG_FSL_LAW is not turned on and all LAW APIs are not available.
>> >We should wrap all LAW registers programming in the mpc85xx PCI
>> >driver with CONFIG_FSL_LAW.
>> >
>> >Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> >---
>> >
>> >(no changes since v1)
>> >
>> > drivers/pci/pci_mpc85xx.c | 4 ++++
>> > 1 file changed, 4 insertions(+)
>> >
>> >diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c
>> >index ab6ff45..7387a1e 100644
>> >--- a/drivers/pci/pci_mpc85xx.c
>> >+++ b/drivers/pci/pci_mpc85xx.c
>> >@@ -46,6 +46,7 @@ static int mpc85xx_pci_dm_write_config(struct
>> >udevice *dev, pci_dev_t bdf,
>> > return 0;
>> > }
>> >
>> >+#ifdef CONFIG_FSL_LAW
>> > static int
>> > mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region *mem,
>> > struct pci_region *pre) @@ -68,6 +69,7 @@
>> >mpc85xx_pci_dm_setup_laws(struct pci_region *io, struct pci_region
>> >*mem,
>> >
>> > return 0;
>> > }
>> >+#endif
>> >
>> > static int mpc85xx_pci_dm_probe(struct udevice *dev) { @@ -85,7
>> >+87,9 @@ static int mpc85xx_pci_dm_probe(struct udevice *dev)
>> > return -EINVAL;
>> > }
>> >
>> >+#ifdef CONFIG_FSL_LAW
>> > mpc85xx_pci_dm_setup_laws(io, mem, pre);
>> >+#endif
>> >
>> > pcix = priv->cfg_addr;
>> > /* BAR 1: memory */
>> >--
>> >2.7.4
>>
>> LAWs are required to be initialized while running on actual boards.
>> For QEMU, may be you can create config like CONFIG_FSL_BYPASS_LAW
>>
>
>As I mentioned in [1], CONFIG_FSL_LAW is already a Kconfig option and all 85xx
>SoCs have selected this config except QEMU, hence I don't think we need to
>create another config like CONFIG_FSL_BYPASS_LAW.
>
>[1] https://lists.denx.de/pipermail/u-boot/2021-February/441907.html
>
>Regards,
>Bin
Thanks for clarifying
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 20/38] pci: mpc85xx: Support controller register physical address beyond 32-bit
2021-02-18 15:57 ` Bin Meng
` (19 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-21 7:06 ` Heiko Schocher
2021-02-22 9:07 ` Priyanka Jain
-1 siblings, 2 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
devfdt_get_addr_index() returns fdt_addr_t which might be a 64-bit
physical address. Use map_physmem() to return the virtual address
that can be used by a 32-bit machine.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
drivers/pci/pci_mpc85xx.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c
index 7387a1e..f0d469a 100644
--- a/drivers/pci/pci_mpc85xx.c
+++ b/drivers/pci/pci_mpc85xx.c
@@ -134,9 +134,8 @@ static int mpc85xx_pci_of_to_plat(struct udevice *dev)
addr = devfdt_get_addr_index(dev, 0);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
- priv->cfg_addr = (void __iomem *)addr;
- addr += 4;
- priv->cfg_data = (void __iomem *)addr;
+ priv->cfg_addr = (void __iomem *)map_physmem(addr, 0, MAP_NOCACHE);
+ priv->cfg_data = (void __iomem *)((ulong)priv->cfg_addr + 4);
return 0;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 20/38] pci: mpc85xx: Support controller register physical address beyond 32-bit
2021-02-18 15:57 ` [PATCH v2 20/38] pci: mpc85xx: Support controller register physical address beyond 32-bit Bin Meng
@ 2021-02-21 7:06 ` Heiko Schocher
2021-02-22 9:07 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Heiko Schocher @ 2021-02-21 7:06 UTC (permalink / raw)
To: u-boot
Hello Bin,
On 18.02.21 16:57, Bin Meng wrote:
> devfdt_get_addr_index() returns fdt_addr_t which might be a 64-bit
> physical address. Use map_physmem() to return the virtual address
> that can be used by a 32-bit machine.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> (no changes since v1)
>
> drivers/pci/pci_mpc85xx.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
Reviewed-by: Heiko Schocher <hs@denx.de>
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 20/38] pci: mpc85xx: Support controller register physical address beyond 32-bit
2021-02-18 15:57 ` [PATCH v2 20/38] pci: mpc85xx: Support controller register physical address beyond 32-bit Bin Meng
2021-02-21 7:06 ` Heiko Schocher
@ 2021-02-22 9:07 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:07 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>; Heiko Schocher <hs@denx.de>
>Subject: [PATCH v2 20/38] pci: mpc85xx: Support controller register physical
>address beyond 32-bit
>
>devfdt_get_addr_index() returns fdt_addr_t which might be a 64-bit physical
>address. Use map_physmem() to return the virtual address that can be used
>by a 32-bit machine.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> drivers/pci/pci_mpc85xx.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 21/38] pci: mpc85xx: Support 64-bit bus and cpu address
2021-02-18 15:57 ` Bin Meng
` (20 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-21 7:06 ` Heiko Schocher
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
At present the driver only supports 32-bit bus and cpu address.
The controller's outbound registers/fields for extended address
are not programmed. Let's program them to support 64-bit bus and
cpu address.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
drivers/pci/pci_mpc85xx.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/pci_mpc85xx.c b/drivers/pci/pci_mpc85xx.c
index f0d469a..574cb78 100644
--- a/drivers/pci/pci_mpc85xx.c
+++ b/drivers/pci/pci_mpc85xx.c
@@ -93,18 +93,18 @@ static int mpc85xx_pci_dm_probe(struct udevice *dev)
pcix = priv->cfg_addr;
/* BAR 1: memory */
- out_be32(&pcix->potar1, (mem->bus_start >> 12) & 0x000fffff);
- out_be32(&pcix->potear1, 0);
- out_be32(&pcix->powbar1, (mem->phys_start >> 12) & 0x000fffff);
- out_be32(&pcix->powbear1, 0);
+ out_be32(&pcix->potar1, mem->bus_start >> 12);
+ out_be32(&pcix->potear1, (u64)mem->bus_start >> 44);
+ out_be32(&pcix->powbar1, mem->phys_start >> 12);
+ out_be32(&pcix->powbear1, (u64)mem->phys_start >> 44);
out_be32(&pcix->powar1, (POWAR_EN | POWAR_MEM_READ |
POWAR_MEM_WRITE | (__ilog2(mem->size) - 1)));
/* BAR 1: IO */
- out_be32(&pcix->potar2, (io->bus_start >> 12) & 0x000fffff);
- out_be32(&pcix->potear2, 0);
- out_be32(&pcix->powbar2, (io->phys_start >> 12) & 0x000fffff);
- out_be32(&pcix->powbear2, 0);
+ out_be32(&pcix->potar2, io->bus_start >> 12);
+ out_be32(&pcix->potear2, (u64)io->bus_start >> 44);
+ out_be32(&pcix->powbar2, io->phys_start >> 12);
+ out_be32(&pcix->powbear2, (u64)io->phys_start >> 44);
out_be32(&pcix->powar2, (POWAR_EN | POWAR_IO_READ |
POWAR_IO_WRITE | (__ilog2(io->size) - 1)));
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 21/38] pci: mpc85xx: Support 64-bit bus and cpu address
2021-02-18 15:57 ` [PATCH v2 21/38] pci: mpc85xx: Support 64-bit bus and cpu address Bin Meng
@ 2021-02-21 7:06 ` Heiko Schocher
0 siblings, 0 replies; 96+ messages in thread
From: Heiko Schocher @ 2021-02-21 7:06 UTC (permalink / raw)
To: u-boot
Hello Bin,
On 18.02.21 16:57, Bin Meng wrote:
> At present the driver only supports 32-bit bus and cpu address.
> The controller's outbound registers/fields for extended address
> are not programmed. Let's program them to support 64-bit bus and
> cpu address.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> (no changes since v1)
>
> drivers/pci/pci_mpc85xx.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
Reviewed-by: Heiko Schocher <hs@denx.de>
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 22/38] ppc: qemu: Switch over to use DM ETH and PCI
2021-02-18 15:57 ` Bin Meng
` (21 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-20 11:54 ` Simon Glass
2021-02-22 9:12 ` Priyanka Jain
-1 siblings, 2 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
At present the board supports non-DM version PCI and E1000 drivers.
Switch over to use DM ETH and PCI by:
- Rewrite the PCI address map functions using DM APIs
- Enable CONFIG_MISC_INIT_R to do the PCI initialization and
address map
- Drop unnecessary ad-hoc config macros
- Remove board_eth_init() in the board codes
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 111 ++++++----------------------
configs/qemu-ppce500_defconfig | 4 +-
include/configs/qemu-ppce500.h | 13 ----
3 files changed, 24 insertions(+), 104 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index db13582..659f794 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -6,6 +6,7 @@
#include <common.h>
#include <command.h>
#include <cpu_func.h>
+#include <dm.h>
#include <env.h>
#include <init.h>
#include <log.h>
@@ -79,27 +80,9 @@ int checkboard(void)
return 0;
}
-static int pci_map_region(void *fdt, int pci_node, int range_id,
- phys_addr_t *pbaddr, phys_size_t *ppaddr,
- pci_addr_t *pvaddr, pci_size_t *psize,
- ulong *pmap_addr)
+static int pci_map_region(phys_addr_t paddr, phys_size_t size, ulong *pmap_addr)
{
- uint64_t baddr;
- uint64_t paddr;
- uint64_t size;
ulong map_addr;
- int r;
-
- r = fdt_read_range(fdt, pci_node, range_id, &baddr, &paddr, &size);
- if (r)
- return r;
-
- if (pbaddr)
- *pbaddr = baddr;
- if (ppaddr)
- *ppaddr = paddr;
- if (psize)
- *psize = size;
if (!pmap_addr)
return 0;
@@ -117,82 +100,37 @@ static int pci_map_region(void *fdt, int pci_node, int range_id,
assert(!tlb_map_range(map_addr, paddr, size, TLB_MAP_IO));
*pmap_addr = map_addr + size;
- if (pvaddr)
- *pvaddr = map_addr;
-
return 0;
}
-void pci_init_board(void)
+int misc_init_r(void)
{
- struct pci_controller *pci_hoses;
- void *fdt = get_fdt_virt();
- int pci_node = -1;
- int pci_num = 0;
- int pci_count = 0;
+ struct udevice *dev;
+ struct pci_region *io;
+ struct pci_region *mem;
+ struct pci_region *pre;
ulong map_addr;
+ int ret;
- puts("\n");
+ /* Ensure PCI is probed */
+ uclass_first_device(UCLASS_PCI, &dev);
+
+ pci_get_regions(dev, &io, &mem, &pre);
/* Start MMIO and PIO range maps above RAM */
map_addr = CONFIG_SYS_PCI_MAP_START;
- /* Count and allocate PCI buses */
- pci_node = fdt_node_offset_by_prop_value(fdt, pci_node,
- "device_type", "pci", 4);
- while (pci_node != -FDT_ERR_NOTFOUND) {
- pci_node = fdt_node_offset_by_prop_value(fdt, pci_node,
- "device_type", "pci", 4);
- pci_count++;
- }
-
- if (pci_count) {
- pci_hoses = malloc(sizeof(struct pci_controller) * pci_count);
- } else {
- printf("PCI: disabled\n\n");
- return;
- }
+ /* Map MMIO range */
+ ret = pci_map_region(mem->phys_start, mem->size, &map_addr);
+ if (ret)
+ return ret;
- /* Spawn PCI buses based on device tree */
- pci_node = fdt_node_offset_by_prop_value(fdt, pci_node,
- "device_type", "pci", 4);
- while (pci_node != -FDT_ERR_NOTFOUND) {
- struct fsl_pci_info pci_info = { };
- const fdt32_t *reg;
- int r;
-
- reg = fdt_getprop(fdt, pci_node, "reg", NULL);
- pci_info.regs = fdt_translate_address(fdt, pci_node, reg);
-
- /* Map MMIO range */
- r = pci_map_region(fdt, pci_node, 0, &pci_info.mem_bus,
- &pci_info.mem_phys, NULL,
- &pci_info.mem_size, &map_addr);
- if (r)
- break;
-
- /* Map PIO range */
- r = pci_map_region(fdt, pci_node, 1, &pci_info.io_bus,
- &pci_info.io_phys, NULL,
- &pci_info.io_size, &map_addr);
- if (r)
- break;
-
- /* Instantiate */
- pci_info.pci_num = pci_num + 1;
-
- fsl_setup_hose(&pci_hoses[pci_num], pci_info.regs);
- printf("PCI: base address %lx\n", pci_info.regs);
-
- fsl_pci_init_port(&pci_info, &pci_hoses[pci_num], pci_num);
-
- /* Jump to next PCI node */
- pci_node = fdt_node_offset_by_prop_value(fdt, pci_node,
- "device_type", "pci", 4);
- pci_num++;
- }
+ /* Map PIO range */
+ ret = pci_map_region(io->phys_start, io->size, &map_addr);
+ if (ret)
+ return ret;
- puts("\n");
+ return 0;
}
int last_stage_init(void)
@@ -235,16 +173,9 @@ static uint64_t get_linear_ram_size(void)
panic("Couldn't determine RAM size");
}
-int board_eth_init(struct bd_info *bis)
-{
- return pci_eth_init(bis);
-}
-
#if defined(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, struct bd_info *bd)
{
- FT_FSL_PCI_SETUP;
-
return 0;
}
#endif
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index c528a68..4a4b369 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -11,7 +11,6 @@ CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_BOOTDELAY=1
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_LAST_STAGE_INIT=y
-# CONFIG_MISC_INIT_R is not set
CONFIG_HUSH_PARSER=y
CONFIG_CMD_REGINFO=y
CONFIG_CMD_BOOTZ=y
@@ -29,7 +28,10 @@ CONFIG_ENV_OVERWRITE=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
# CONFIG_MMC is not set
+CONFIG_DM_ETH=y
CONFIG_E1000=y
+CONFIG_DM_PCI=y
+CONFIG_PCI_MPC85XX=y
CONFIG_DM_SERIAL=y
CONFIG_SYS_NS16550=y
CONFIG_ADDR_MAP=y
diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h
index feac6ef..b1ee810 100644
--- a/include/configs/qemu-ppce500.h
+++ b/include/configs/qemu-ppce500.h
@@ -13,8 +13,6 @@
#define CONFIG_SYS_RAMBOOT
-#define CONFIG_PCI1 1 /* PCI controller 1 */
-#define CONFIG_FSL_PCI_INIT /* Use common FSL init code */
#define CONFIG_SYS_PCI_64BIT /* enable 64-bit PCI resources */
#define CONFIG_ENABLE_36BIT_PHYS
@@ -73,17 +71,6 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void);
#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
#define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024)
-/*
- * General PCI
- * Memory space is mapped 1-1, but I/O space must start from 0.
- */
-
-#ifdef CONFIG_PCI
-#define CONFIG_PCI_INDIRECT_BRIDGE
-
-#define CONFIG_PCI_SCAN_SHOW /* show pci devices on startup */
-#endif /* CONFIG_PCI */
-
#define CONFIG_LBA48
/*
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 22/38] ppc: qemu: Switch over to use DM ETH and PCI
2021-02-18 15:57 ` [PATCH v2 22/38] ppc: qemu: Switch over to use DM ETH and PCI Bin Meng
@ 2021-02-20 11:54 ` Simon Glass
2021-02-22 9:12 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Simon Glass @ 2021-02-20 11:54 UTC (permalink / raw)
To: u-boot
On Thu, 18 Feb 2021 at 09:00, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> At present the board supports non-DM version PCI and E1000 drivers.
> Switch over to use DM ETH and PCI by:
>
> - Rewrite the PCI address map functions using DM APIs
> - Enable CONFIG_MISC_INIT_R to do the PCI initialization and
> address map
> - Drop unnecessary ad-hoc config macros
> - Remove board_eth_init() in the board codes
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> (no changes since v1)
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 111 ++++++----------------------
> configs/qemu-ppce500_defconfig | 4 +-
> include/configs/qemu-ppce500.h | 13 ----
> 3 files changed, 24 insertions(+), 104 deletions(-)
>
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 22/38] ppc: qemu: Switch over to use DM ETH and PCI
2021-02-18 15:57 ` [PATCH v2 22/38] ppc: qemu: Switch over to use DM ETH and PCI Bin Meng
2021-02-20 11:54 ` Simon Glass
@ 2021-02-22 9:12 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:12 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 22/38] ppc: qemu: Switch over to use DM ETH and PCI
>
>At present the board supports non-DM version PCI and E1000 drivers.
>Switch over to use DM ETH and PCI by:
>
>- Rewrite the PCI address map functions using DM APIs
>- Enable CONFIG_MISC_INIT_R to do the PCI initialization and
> address map
>- Drop unnecessary ad-hoc config macros
>- Remove board_eth_init() in the board codes
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 111 ++++++----------------
>------
> configs/qemu-ppce500_defconfig | 4 +-
> include/configs/qemu-ppce500.h | 13 ----
> 3 files changed, 24 insertions(+), 104 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 23/38] ppc: qemu: Drop CONFIG_OF_BOARD_SETUP
2021-02-18 15:57 ` Bin Meng
` (22 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
-1 siblings, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
ft_board_setup() is now empty. Drop it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 7 -------
configs/qemu-ppce500_defconfig | 1 -
2 files changed, 8 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 659f794..79a6986 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -173,13 +173,6 @@ static uint64_t get_linear_ram_size(void)
panic("Couldn't determine RAM size");
}
-#if defined(CONFIG_OF_BOARD_SETUP)
-int ft_board_setup(void *blob, struct bd_info *bd)
-{
- return 0;
-}
-#endif
-
phys_size_t fixed_sdram(void)
{
return get_linear_ram_size();
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 4a4b369..918739b 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -6,7 +6,6 @@ CONFIG_MPC85xx=y
CONFIG_TARGET_QEMU_PPCE500=y
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
-CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_STDOUT_VIA_ALIAS=y
CONFIG_BOOTDELAY=1
# CONFIG_DISPLAY_BOARDINFO is not set
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 24/38] cmd: Fix virtio command dependency
2021-02-18 15:57 ` Bin Meng
` (23 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:13 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
The 'virtio' command calls blk_common_cmd() which is only available
when CONFIG_HAVE_BLOCK_DEVICE is on. Fix the Kconfig dependency.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
(no changes since v1)
cmd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 2021939..eda5190 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1344,6 +1344,7 @@ config CMD_PVBLOCK
config CMD_VIRTIO
bool "virtio"
depends on VIRTIO
+ depends on HAVE_BLOCK_DEVICE
default y if VIRTIO
help
VirtIO block device support
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 24/38] cmd: Fix virtio command dependency
2021-02-18 15:57 ` [PATCH v2 24/38] cmd: Fix virtio command dependency Bin Meng
@ 2021-02-22 9:13 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:13 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 24/38] cmd: Fix virtio command dependency
>
>The 'virtio' command calls blk_common_cmd() which is only available when
>CONFIG_HAVE_BLOCK_DEVICE is on. Fix the Kconfig dependency.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>---
>
>(no changes since v1)
>
> cmd/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
>diff --git a/cmd/Kconfig b/cmd/Kconfig
>index 2021939..eda5190 100644
>--- a/cmd/Kconfig
>+++ b/cmd/Kconfig
>@@ -1344,6 +1344,7 @@ config CMD_PVBLOCK config CMD_VIRTIO
> bool "virtio"
> depends on VIRTIO
>+ depends on HAVE_BLOCK_DEVICE
> default y if VIRTIO
> help
> VirtIO block device support
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 25/38] ppc: qemu: Enable VirtIO NET support
2021-02-18 15:57 ` Bin Meng
` (24 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:13 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
By default the QEMU ppce500 machine connects a VirtIO NET to the
PCI controller, although it can be replaced to an e1000 NIC via
additional command line options.
Now that we have switched over to DM PCI, VirtIO support becomes
possible. This commit enables the support.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
board/freescale/qemu-ppce500/qemu-ppce500.c | 8 ++++++++
configs/qemu-ppce500_defconfig | 2 ++
2 files changed, 10 insertions(+)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 79a6986..9c30c12 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -24,6 +24,8 @@
#include <fdtdec.h>
#include <errno.h>
#include <malloc.h>
+#include <virtio_types.h>
+#include <virtio.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -130,6 +132,12 @@ int misc_init_r(void)
if (ret)
return ret;
+ /*
+ * Make sure virtio bus is enumerated so that peripherals
+ * on the virtio bus can be discovered by their drivers.
+ */
+ virtio_init();
+
return 0;
}
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 918739b..202e97e 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -33,5 +33,7 @@ CONFIG_DM_PCI=y
CONFIG_PCI_MPC85XX=y
CONFIG_DM_SERIAL=y
CONFIG_SYS_NS16550=y
+CONFIG_VIRTIO_PCI=y
+CONFIG_VIRTIO_NET=y
CONFIG_ADDR_MAP=y
CONFIG_PANIC_HANG=y
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 25/38] ppc: qemu: Enable VirtIO NET support
2021-02-18 15:57 ` [PATCH v2 25/38] ppc: qemu: Enable VirtIO NET support Bin Meng
@ 2021-02-22 9:13 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:13 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 25/38] ppc: qemu: Enable VirtIO NET support
>
>By default the QEMU ppce500 machine connects a VirtIO NET to the PCI
>controller, although it can be replaced to an e1000 NIC via additional command
>line options.
>
>Now that we have switched over to DM PCI, VirtIO support becomes possible.
>This commit enables the support.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 8 ++++++++
> configs/qemu-ppce500_defconfig | 2 ++
> 2 files changed, 10 insertions(+)
>
>diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c
>b/board/freescale/qemu-ppce500/qemu-ppce500.c
>index 79a6986..9c30c12 100644
>--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
>+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
>@@ -24,6 +24,8 @@
> #include <fdtdec.h>
> #include <errno.h>
> #include <malloc.h>
>+#include <virtio_types.h>
>+#include <virtio.h>
>
> DECLARE_GLOBAL_DATA_PTR;
>
>@@ -130,6 +132,12 @@ int misc_init_r(void)
> if (ret)
> return ret;
>
>+ /*
>+ * Make sure virtio bus is enumerated so that peripherals
>+ * on the virtio bus can be discovered by their drivers.
>+ */
>+ virtio_init();
>+
> return 0;
> }
>
>diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-
>ppce500_defconfig index 918739b..202e97e 100644
>--- a/configs/qemu-ppce500_defconfig
>+++ b/configs/qemu-ppce500_defconfig
>@@ -33,5 +33,7 @@ CONFIG_DM_PCI=y
> CONFIG_PCI_MPC85XX=y
> CONFIG_DM_SERIAL=y
> CONFIG_SYS_NS16550=y
>+CONFIG_VIRTIO_PCI=y
>+CONFIG_VIRTIO_NET=y
> CONFIG_ADDR_MAP=y
> CONFIG_PANIC_HANG=y
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 26/38] virtio: Fix VirtIO BLK driver dependency
2021-02-18 15:57 ` Bin Meng
` (25 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-20 11:54 ` Simon Glass
2021-02-22 9:13 ` Priyanka Jain
-1 siblings, 2 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
The VirtIO BLK driver depends on the blk uclass driver.
Add the dependency in the Kconfig.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: virtio: Fix VirtIO BLK driver dependency
drivers/virtio/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index e800720..1835607 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -55,6 +55,7 @@ config VIRTIO_NET
config VIRTIO_BLK
bool "virtio block driver"
depends on VIRTIO
+ depends on BLK
help
This is the virtual block driver for virtio. It can be used with
QEMU based targets.
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 26/38] virtio: Fix VirtIO BLK driver dependency
2021-02-18 15:57 ` [PATCH v2 26/38] virtio: Fix VirtIO BLK driver dependency Bin Meng
@ 2021-02-20 11:54 ` Simon Glass
2021-02-22 9:13 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Simon Glass @ 2021-02-20 11:54 UTC (permalink / raw)
To: u-boot
On Thu, 18 Feb 2021 at 09:00, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> The VirtIO BLK driver depends on the blk uclass driver.
> Add the dependency in the Kconfig.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - new patch: virtio: Fix VirtIO BLK driver dependency
>
> drivers/virtio/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 26/38] virtio: Fix VirtIO BLK driver dependency
2021-02-18 15:57 ` [PATCH v2 26/38] virtio: Fix VirtIO BLK driver dependency Bin Meng
2021-02-20 11:54 ` Simon Glass
@ 2021-02-22 9:13 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:13 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 26/38] virtio: Fix VirtIO BLK driver dependency
>
>The VirtIO BLK driver depends on the blk uclass driver.
>Add the dependency in the Kconfig.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: virtio: Fix VirtIO BLK driver dependency
>
> drivers/virtio/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 27/38] ppc: qemu: Enable VirtIO BLK support
2021-02-18 15:57 ` Bin Meng
` (26 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:13 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
Enable VirtIO BLK driver so that we can store a kernel image to
a disk image and boot from there.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: qemu: Enable VirtIO BLK support
configs/qemu-ppce500_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 202e97e..b2510c8 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -26,6 +26,8 @@ CONFIG_OF_BOARD=y
CONFIG_ENV_OVERWRITE=y
CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
+CONFIG_BLK=y
+CONFIG_HAVE_BLOCK_DEVICE=y
# CONFIG_MMC is not set
CONFIG_DM_ETH=y
CONFIG_E1000=y
@@ -35,5 +37,6 @@ CONFIG_DM_SERIAL=y
CONFIG_SYS_NS16550=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_NET=y
+CONFIG_VIRTIO_BLK=y
CONFIG_ADDR_MAP=y
CONFIG_PANIC_HANG=y
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 27/38] ppc: qemu: Enable VirtIO BLK support
2021-02-18 15:57 ` [PATCH v2 27/38] ppc: qemu: Enable VirtIO BLK support Bin Meng
@ 2021-02-22 9:13 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:13 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 27/38] ppc: qemu: Enable VirtIO BLK support
>
>Enable VirtIO BLK driver so that we can store a kernel image to a disk image
>and boot from there.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: qemu: Enable VirtIO BLK support
>
> configs/qemu-ppce500_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 28/38] ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
2021-02-18 15:57 ` Bin Meng
` (27 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:13 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
Without this, the DM GPIO driver for MPC8xxx does not compile for
MPC85xx SoCs.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
arch/powerpc/include/asm/immap_85xx.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/immap_85xx.h b/arch/powerpc/include/asm/immap_85xx.h
index bfa601e..fec1b33 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -272,6 +272,7 @@ typedef struct ccsr_gpio {
u32 gpier;
u32 gpimr;
u32 gpicr;
+ u32 gpibe;
} ccsr_gpio_t;
#endif
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 28/38] ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
2021-02-18 15:57 ` [PATCH v2 28/38] ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio' Bin Meng
@ 2021-02-22 9:13 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:13 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 28/38] ppc: mpc85xx: Add 'gpibe' register to 'struct
>ccsr_gpio'
>
>Without this, the DM GPIO driver for MPC8xxx does not compile for MPC85xx
>SoCs.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
>
> arch/powerpc/include/asm/immap_85xx.h | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 29/38] gpio: mpc8xxx: Support controller register physical address beyond 32-bit
2021-02-18 15:57 ` Bin Meng
` (28 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:13 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
dev_read_addr_size_index() returns fdt_addr_t which might be a
64-bit physical address. This might be true for some 85xx SoCs
whose CCSBAR is mapped beyond 4 GiB.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: gpio: mpc8xxx: Support controller register physical address beyond 32-bit
arch/powerpc/include/asm/arch-mpc85xx/gpio.h | 2 +-
drivers/gpio/mpc8xxx_gpio.c | 7 ++++---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/arch-mpc85xx/gpio.h b/arch/powerpc/include/asm/arch-mpc85xx/gpio.h
index c7086a8..79ba786 100644
--- a/arch/powerpc/include/asm/arch-mpc85xx/gpio.h
+++ b/arch/powerpc/include/asm/arch-mpc85xx/gpio.h
@@ -18,7 +18,7 @@
#endif
struct mpc8xxx_gpio_plat {
- ulong addr;
+ phys_addr_t addr;
unsigned long size;
uint ngpios;
};
diff --git a/drivers/gpio/mpc8xxx_gpio.c b/drivers/gpio/mpc8xxx_gpio.c
index c733603..f7ffd89 100644
--- a/drivers/gpio/mpc8xxx_gpio.c
+++ b/drivers/gpio/mpc8xxx_gpio.c
@@ -20,7 +20,7 @@ struct mpc8xxx_gpio_data {
/* The bank's register base in memory */
struct ccsr_gpio __iomem *base;
/* The address of the registers; used to identify the bank */
- ulong addr;
+ phys_addr_t addr;
/* The GPIO count of the bank */
uint gpio_count;
/* The GPDAT register cannot be used to determine the value of output
@@ -181,7 +181,7 @@ static int mpc8xxx_gpio_of_to_plat(struct udevice *dev)
if (dev_read_bool(dev, "little-endian"))
data->little_endian = true;
- plat->addr = (ulong)dev_read_addr_size_index(dev, 0, (fdt_size_t *)&plat->size);
+ plat->addr = dev_read_addr_size_index(dev, 0, (fdt_size_t *)&plat->size);
plat->ngpios = dev_read_u32_default(dev, "ngpios", 32);
return 0;
@@ -220,7 +220,8 @@ static int mpc8xxx_gpio_probe(struct udevice *dev)
mpc8xxx_gpio_plat_to_priv(dev);
- snprintf(name, sizeof(name), "MPC@%lx_", data->addr);
+ snprintf(name, sizeof(name), "MPC@%.8llx",
+ (unsigned long long)data->addr);
str = strdup(name);
if (!str)
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 29/38] gpio: mpc8xxx: Support controller register physical address beyond 32-bit
2021-02-18 15:57 ` [PATCH v2 29/38] gpio: mpc8xxx: Support controller register physical address beyond 32-bit Bin Meng
@ 2021-02-22 9:13 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:13 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 29/38] gpio: mpc8xxx: Support controller register physical
>address beyond 32-bit
>
>dev_read_addr_size_index() returns fdt_addr_t which might be a 64-bit
>physical address. This might be true for some 85xx SoCs whose CCSBAR is
>mapped beyond 4 GiB.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: gpio: mpc8xxx: Support controller register physical address
>beyond 32-bit
>
> arch/powerpc/include/asm/arch-mpc85xx/gpio.h | 2 +-
> drivers/gpio/mpc8xxx_gpio.c | 7 ++++---
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 30/38] ppc: qemu: Enable GPIO support
2021-02-18 15:57 ` Bin Meng
` (29 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-22 9:13 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
QEMU ppce500 target integrates a GPIO controller that is compatible
with the QorIQ GPIO controller. Enable the DM GPIO driver for it
and the 'gpio' command.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: qemu: Enable GPIO support
configs/qemu-ppce500_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index b2510c8..c5e2ad3 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -1,6 +1,7 @@
CONFIG_PPC=y
CONFIG_SYS_TEXT_BASE=0xf01000
CONFIG_ENV_SIZE=0x2000
+CONFIG_DM_GPIO=y
CONFIG_MPC85xx=y
# CONFIG_CMD_ERRATA is not set
CONFIG_TARGET_QEMU_PPCE500=y
@@ -15,6 +16,7 @@ CONFIG_CMD_REGINFO=y
CONFIG_CMD_BOOTZ=y
CONFIG_CMD_GREPENV=y
CONFIG_CMD_DM=y
+CONFIG_CMD_GPIO=y
CONFIG_CMD_PCI=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
@@ -28,6 +30,7 @@ CONFIG_SYS_RELOC_GD_ENV_ADDR=y
CONFIG_DM=y
CONFIG_BLK=y
CONFIG_HAVE_BLOCK_DEVICE=y
+CONFIG_MPC8XXX_GPIO=y
# CONFIG_MMC is not set
CONFIG_DM_ETH=y
CONFIG_E1000=y
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 30/38] ppc: qemu: Enable GPIO support
2021-02-18 15:57 ` [PATCH v2 30/38] ppc: qemu: Enable GPIO support Bin Meng
@ 2021-02-22 9:13 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:13 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 30/38] ppc: qemu: Enable GPIO support
>
>QEMU ppce500 target integrates a GPIO controller that is compatible with the
>QorIQ GPIO controller. Enable the DM GPIO driver for it and the 'gpio'
>command.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: qemu: Enable GPIO support
>
> configs/qemu-ppce500_defconfig | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 31/38] dm: sysreset: Add a Kconfig option for the 'reset' command
2021-02-18 15:57 ` Bin Meng
` (30 preceding siblings ...)
(?)
@ 2021-02-18 15:57 ` Bin Meng
2021-02-20 11:55 ` Simon Glass
2021-02-22 9:15 ` Priyanka Jain
-1 siblings, 2 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:57 UTC (permalink / raw)
To: u-boot
sysreset uclass driver provides an implementation of 'reset'
command using the sysreset_ APIs unconditionally. It also
supports the 'poweroff' command using the sysreset_ APIs,
but under a Kconfig option CONFIG_SYSRESET_CMD_POWEROFF.
Let's do the same for the 'reset' command, by introducing a
new Kconfig option CONFIG_SYSRESET_CMD_RESET, and set it to
on by default, to allow a board that don't have a sysreset
reset driver yet, but have a sysreset poweroff driver to
compile without any issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: dm: sysreset: Add a Kconfig option for the 'reset' command
drivers/sysreset/Kconfig | 6 ++++++
drivers/sysreset/sysreset-uclass.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 0e5c7c9..968dfa4 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -33,6 +33,12 @@ config TPL_SYSRESET
if SYSRESET
+config SYSRESET_CMD_RESET
+ bool "sysreset implementation of the reset command"
+ default y
+ help
+ Enable sysreset implementation of the reset command.
+
if CMD_POWEROFF
config SYSRESET_CMD_POWEROFF
diff --git a/drivers/sysreset/sysreset-uclass.c b/drivers/sysreset/sysreset-uclass.c
index a9908eb..6c9dc7a 100644
--- a/drivers/sysreset/sysreset-uclass.c
+++ b/drivers/sysreset/sysreset-uclass.c
@@ -119,6 +119,7 @@ void reset_cpu(ulong addr)
}
+#if IS_ENABLED(CONFIG_SYSRESET_CMD_RESET)
int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
printf("resetting ...\n");
@@ -128,6 +129,7 @@ int do_reset(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
return 0;
}
+#endif
#if IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 31/38] dm: sysreset: Add a Kconfig option for the 'reset' command
2021-02-18 15:57 ` [PATCH v2 31/38] dm: sysreset: Add a Kconfig option for the 'reset' command Bin Meng
@ 2021-02-20 11:55 ` Simon Glass
2021-02-22 9:15 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Simon Glass @ 2021-02-20 11:55 UTC (permalink / raw)
To: u-boot
On Thu, 18 Feb 2021 at 09:00, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> sysreset uclass driver provides an implementation of 'reset'
> command using the sysreset_ APIs unconditionally. It also
> supports the 'poweroff' command using the sysreset_ APIs,
> but under a Kconfig option CONFIG_SYSRESET_CMD_POWEROFF.
>
> Let's do the same for the 'reset' command, by introducing a
> new Kconfig option CONFIG_SYSRESET_CMD_RESET, and set it to
> on by default, to allow a board that don't have a sysreset
> reset driver yet, but have a sysreset poweroff driver to
> compile without any issue.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
> Changes in v2:
> - new patch: dm: sysreset: Add a Kconfig option for the 'reset' command
>
> drivers/sysreset/Kconfig | 6 ++++++
> drivers/sysreset/sysreset-uclass.c | 2 ++
> 2 files changed, 8 insertions(+)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 31/38] dm: sysreset: Add a Kconfig option for the 'reset' command
2021-02-18 15:57 ` [PATCH v2 31/38] dm: sysreset: Add a Kconfig option for the 'reset' command Bin Meng
2021-02-20 11:55 ` Simon Glass
@ 2021-02-22 9:15 ` Priyanka Jain
1 sibling, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:15 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 31/38] dm: sysreset: Add a Kconfig option for the 'reset'
>command
>
>sysreset uclass driver provides an implementation of 'reset'
>command using the sysreset_ APIs unconditionally. It also supports the
>'poweroff' command using the sysreset_ APIs, but under a Kconfig option
>CONFIG_SYSRESET_CMD_POWEROFF.
>
>Let's do the same for the 'reset' command, by introducing a new Kconfig
>option CONFIG_SYSRESET_CMD_RESET, and set it to on by default, to allow a
>board that don't have a sysreset reset driver yet, but have a sysreset
>poweroff driver to compile without any issue.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: dm: sysreset: Add a Kconfig option for the 'reset' command
>
> drivers/sysreset/Kconfig | 6 ++++++
> drivers/sysreset/sysreset-uclass.c | 2 ++
> 2 files changed, 8 insertions(+)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 32/38] ppc: qemu: Enable support for power off via GPIO
2021-02-18 15:57 ` Bin Meng
` (31 preceding siblings ...)
(?)
@ 2021-02-18 15:58 ` Bin Meng
2021-02-22 9:15 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:58 UTC (permalink / raw)
To: u-boot
The QEMU ppce500 target provides the power off functionality via
the GPIO pin#0, and we can support this using the sysreset gpio
poweroff driver. Let's enable it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: qemu: Enable support for power off via GPIO
configs/qemu-ppce500_defconfig | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index c5e2ad3..8798db6 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -1,7 +1,6 @@
CONFIG_PPC=y
CONFIG_SYS_TEXT_BASE=0xf01000
CONFIG_ENV_SIZE=0x2000
-CONFIG_DM_GPIO=y
CONFIG_MPC85xx=y
# CONFIG_CMD_ERRATA is not set
CONFIG_TARGET_QEMU_PPCE500=y
@@ -18,6 +17,7 @@ CONFIG_CMD_GREPENV=y
CONFIG_CMD_DM=y
CONFIG_CMD_GPIO=y
CONFIG_CMD_PCI=y
+CONFIG_CMD_POWEROFF=y
CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
# CONFIG_CMD_HASH is not set
@@ -38,6 +38,10 @@ CONFIG_DM_PCI=y
CONFIG_PCI_MPC85XX=y
CONFIG_DM_SERIAL=y
CONFIG_SYS_NS16550=y
+CONFIG_SYSRESET=y
+# CONFIG_SYSRESET_CMD_RESET is not set
+CONFIG_SYSRESET_CMD_POWEROFF=y
+CONFIG_POWEROFF_GPIO=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_NET=y
CONFIG_VIRTIO_BLK=y
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 32/38] ppc: qemu: Enable support for power off via GPIO
2021-02-18 15:58 ` [PATCH v2 32/38] ppc: qemu: Enable support for power off via GPIO Bin Meng
@ 2021-02-22 9:15 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:15 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 32/38] ppc: qemu: Enable support for power off via GPIO
>
>The QEMU ppce500 target provides the power off functionality via the GPIO
>pin#0, and we can support this using the sysreset gpio poweroff driver. Let's
>enable it.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: qemu: Enable support for power off via GPIO
>
> configs/qemu-ppce500_defconfig | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 33/38] ppc: qemu: Enable RTC support via I2C
2021-02-18 15:57 ` Bin Meng
` (32 preceding siblings ...)
(?)
@ 2021-02-18 15:58 ` Bin Meng
2021-02-22 9:15 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:58 UTC (permalink / raw)
To: u-boot
The QEMU ppce500 target integrates a Freescale I2C controller and
has a Pericom pt7c4338 RTC connected to it. Enable corresponding
DM drivers so that 'date' command is actually useful.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: qemu: Enable RTC support via I2C
configs/qemu-ppce500_defconfig | 3 +++
include/configs/qemu-ppce500.h | 3 +++
2 files changed, 6 insertions(+)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 8798db6..536fe7d 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -31,11 +31,14 @@ CONFIG_DM=y
CONFIG_BLK=y
CONFIG_HAVE_BLOCK_DEVICE=y
CONFIG_MPC8XXX_GPIO=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_FSL=y
# CONFIG_MMC is not set
CONFIG_DM_ETH=y
CONFIG_E1000=y
CONFIG_DM_PCI=y
CONFIG_PCI_MPC85XX=y
+CONFIG_DM_RTC=y
CONFIG_DM_SERIAL=y
CONFIG_SYS_NS16550=y
CONFIG_SYSRESET=y
diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h
index b1ee810..7c65e64 100644
--- a/include/configs/qemu-ppce500.h
+++ b/include/configs/qemu-ppce500.h
@@ -73,6 +73,9 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void);
#define CONFIG_LBA48
+/* RTC */
+#define CONFIG_RTC_PT7C4338
+
/*
* Environment
*/
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 33/38] ppc: qemu: Enable RTC support via I2C
2021-02-18 15:58 ` [PATCH v2 33/38] ppc: qemu: Enable RTC support via I2C Bin Meng
@ 2021-02-22 9:15 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:15 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 33/38] ppc: qemu: Enable RTC support via I2C
>
>The QEMU ppce500 target integrates a Freescale I2C controller and has a
>Pericom pt7c4338 RTC connected to it. Enable corresponding DM drivers so
>that 'date' command is actually useful.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: qemu: Enable RTC support via I2C
>
> configs/qemu-ppce500_defconfig | 3 +++
> include/configs/qemu-ppce500.h | 3 +++
> 2 files changed, 6 insertions(+)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 34/38] ppc: qemu: Delete the temporary FDT virtual-physical mapping after U-Boot is relocated
2021-02-18 15:57 ` Bin Meng
` (33 preceding siblings ...)
(?)
@ 2021-02-18 15:58 ` Bin Meng
2021-02-22 9:16 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:58 UTC (permalink / raw)
To: u-boot
After U-Boot is relocated to RAM already, the previous temporary FDT
virtual-physical mapping that was used in the pre-relocation phase
is no longer needed. Let's delete the mapping.
get_fdt_virt() might be used before and after relocation, update it
to return different virtual address of FDT.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: qemu: Delete the temporary FDT virtual-physical mapping after U-Boot is relocated
board/freescale/qemu-ppce500/qemu-ppce500.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 9c30c12..480776a 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -31,7 +31,10 @@ DECLARE_GLOBAL_DATA_PTR;
static void *get_fdt_virt(void)
{
- return (void *)CONFIG_SYS_TMPVIRT;
+ if (gd->flags & GD_FLG_RELOC)
+ return (void *)gd->fdt_blob;
+ else
+ return (void *)CONFIG_SYS_TMPVIRT;
}
static uint64_t get_fdt_phys(void)
@@ -138,6 +141,12 @@ int misc_init_r(void)
*/
virtio_init();
+ /*
+ * U-Boot is relocated to RAM already, let's delete the temporary FDT
+ * virtual-physical mapping that was used in the pre-relocation phase.
+ */
+ disable_tlb(find_tlb_idx((void *)CONFIG_SYS_TMPVIRT, 1));
+
return 0;
}
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 34/38] ppc: qemu: Delete the temporary FDT virtual-physical mapping after U-Boot is relocated
2021-02-18 15:58 ` [PATCH v2 34/38] ppc: qemu: Delete the temporary FDT virtual-physical mapping after U-Boot is relocated Bin Meng
@ 2021-02-22 9:16 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:16 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 34/38] ppc: qemu: Delete the temporary FDT virtual-
>physical mapping after U-Boot is relocated
>
>After U-Boot is relocated to RAM already, the previous temporary FDT virtual-
>physical mapping that was used in the pre-relocation phase is no longer
>needed. Let's delete the mapping.
>
>get_fdt_virt() might be used before and after relocation, update it to return
>different virtual address of FDT.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: qemu: Delete the temporary FDT virtual-physical mapping
>after U-Boot is relocated
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 35/38] ppc: qemu: Drop a custom env variable 'fdt_addr_r'
2021-02-18 15:57 ` Bin Meng
` (34 preceding siblings ...)
(?)
@ 2021-02-18 15:58 ` Bin Meng
2021-02-22 9:16 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:58 UTC (permalink / raw)
To: u-boot
Now that we have switched to CONFIG_OF_CONTROL, and we can use the
env variable 'fdtcontroladdr' directly instead of creating one that
is duplicated.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: qemu: Drop a custom env variable 'fdt_addr_r'
board/freescale/qemu-ppce500/qemu-ppce500.c | 3 ---
include/configs/qemu-ppce500.h | 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 480776a..202b7f6 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -168,9 +168,6 @@ int last_stage_init(void)
if (prop && (len >= 8))
env_set_hex("qemu_kernel_addr", *prop);
- /* Give the user a variable for the host fdt */
- env_set_hex("fdt_addr_r", (ulong)fdt);
-
return 0;
}
diff --git a/include/configs/qemu-ppce500.h b/include/configs/qemu-ppce500.h
index 7c65e64..b2e1204 100644
--- a/include/configs/qemu-ppce500.h
+++ b/include/configs/qemu-ppce500.h
@@ -106,6 +106,6 @@ extern unsigned long long get_phys_ccsrbar_addr_early(void);
#define CONFIG_LOADADDR 1000000
#define CONFIG_BOOTCOMMAND \
- "test -n \"$qemu_kernel_addr\" && bootm $qemu_kernel_addr - $fdt_addr_r\0"
+ "test -n \"$qemu_kernel_addr\" && bootm $qemu_kernel_addr - $fdtcontroladdr\0"
#endif /* __QEMU_PPCE500_H */
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 35/38] ppc: qemu: Drop a custom env variable 'fdt_addr_r'
2021-02-18 15:58 ` [PATCH v2 35/38] ppc: qemu: Drop a custom env variable 'fdt_addr_r' Bin Meng
@ 2021-02-22 9:16 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:16 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 35/38] ppc: qemu: Drop a custom env variable 'fdt_addr_r'
>
>Now that we have switched to CONFIG_OF_CONTROL, and we can use the
>env variable 'fdtcontroladdr' directly instead of creating one that is duplicated.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: qemu: Drop a custom env variable 'fdt_addr_r'
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 3 ---
> include/configs/qemu-ppce500.h | 2 +-
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 36/38] ppc: qemu: Drop fixed_sdram()
2021-02-18 15:57 ` Bin Meng
` (35 preceding siblings ...)
(?)
@ 2021-02-18 15:58 ` Bin Meng
2021-02-22 9:16 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:58 UTC (permalink / raw)
To: u-boot
This function is not called anywhere. Only fsl_ddr_sdram_size() is
necessary [1] for QEMU. Drop it.
[1] arch/powerpc/cpu/mpc85xx/cpu.c::dram_init()
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
Changes in v2:
- new patch: ppc: qemu: Drop fixed_sdram()
board/freescale/qemu-ppce500/qemu-ppce500.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/freescale/qemu-ppce500/qemu-ppce500.c
index 202b7f6..7d711b8 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -187,11 +187,6 @@ static uint64_t get_linear_ram_size(void)
panic("Couldn't determine RAM size");
}
-phys_size_t fixed_sdram(void)
-{
- return get_linear_ram_size();
-}
-
phys_size_t fsl_ddr_sdram_size(void)
{
return get_linear_ram_size();
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 36/38] ppc: qemu: Drop fixed_sdram()
2021-02-18 15:58 ` [PATCH v2 36/38] ppc: qemu: Drop fixed_sdram() Bin Meng
@ 2021-02-22 9:16 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:16 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 36/38] ppc: qemu: Drop fixed_sdram()
>
>This function is not called anywhere. Only fsl_ddr_sdram_size() is necessary [1]
>for QEMU. Drop it.
>
>[1] arch/powerpc/cpu/mpc85xx/cpu.c::dram_init()
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
>---
>
>Changes in v2:
>- new patch: ppc: qemu: Drop fixed_sdram()
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 5 -----
> 1 file changed, 5 deletions(-)
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 37/38] ppc: qemu: Move board directory from board/freescale to board/emulation
2021-02-18 15:57 ` Bin Meng
` (36 preceding siblings ...)
(?)
@ 2021-02-18 15:58 ` Bin Meng
2021-02-22 9:18 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:58 UTC (permalink / raw)
To: u-boot
board/emulation is the place for other QEMU targets like x86, arm,
riscv. Let's move the qemu-ppce500 board codes there.
List me as a co-maintainer for this board.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
(no changes since v1)
arch/powerpc/cpu/mpc85xx/Kconfig | 2 +-
board/{freescale => emulation}/qemu-ppce500/Kconfig | 2 +-
board/{freescale => emulation}/qemu-ppce500/MAINTAINERS | 3 ++-
board/{freescale => emulation}/qemu-ppce500/Makefile | 0
board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c | 1 +
5 files changed, 5 insertions(+), 3 deletions(-)
rename board/{freescale => emulation}/qemu-ppce500/Kconfig (86%)
rename board/{freescale => emulation}/qemu-ppce500/MAINTAINERS (67%)
rename board/{freescale => emulation}/qemu-ppce500/Makefile (100%)
rename board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c (99%)
diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 870ab80..f59801a 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -1428,6 +1428,7 @@ config SYS_FSL_LBC_CLK_DIV
Defines divider of platform clock(clock input to
eLBC controller).
+source "board/emulation/qemu-ppce500/Kconfig"
source "board/freescale/corenet_ds/Kconfig"
source "board/freescale/mpc8541cds/Kconfig"
source "board/freescale/mpc8548cds/Kconfig"
@@ -1437,7 +1438,6 @@ source "board/freescale/mpc8569mds/Kconfig"
source "board/freescale/p1010rdb/Kconfig"
source "board/freescale/p1_p2_rdb_pc/Kconfig"
source "board/freescale/p2041rdb/Kconfig"
-source "board/freescale/qemu-ppce500/Kconfig"
source "board/freescale/t102xrdb/Kconfig"
source "board/freescale/t104xrdb/Kconfig"
source "board/freescale/t208xqds/Kconfig"
diff --git a/board/freescale/qemu-ppce500/Kconfig b/board/emulation/qemu-ppce500/Kconfig
similarity index 86%
rename from board/freescale/qemu-ppce500/Kconfig
rename to board/emulation/qemu-ppce500/Kconfig
index 236cd17..4312d98 100644
--- a/board/freescale/qemu-ppce500/Kconfig
+++ b/board/emulation/qemu-ppce500/Kconfig
@@ -4,7 +4,7 @@ config SYS_BOARD
default "qemu-ppce500"
config SYS_VENDOR
- default "freescale"
+ default "emulation"
config SYS_CONFIG_NAME
default "qemu-ppce500"
diff --git a/board/freescale/qemu-ppce500/MAINTAINERS b/board/emulation/qemu-ppce500/MAINTAINERS
similarity index 67%
rename from board/freescale/qemu-ppce500/MAINTAINERS
rename to board/emulation/qemu-ppce500/MAINTAINERS
index e70c095..7317983 100644
--- a/board/freescale/qemu-ppce500/MAINTAINERS
+++ b/board/emulation/qemu-ppce500/MAINTAINERS
@@ -1,6 +1,7 @@
QEMU-PPCE500 BOARD
M: Alexander Graf <agraf@csgraf.de>
+M: Bin Meng <bmeng.cn@gmail.com>
S: Maintained
-F: board/freescale/qemu-ppce500/
+F: board/emulation/qemu-ppce500/
F: include/configs/qemu-ppce500.h
F: configs/qemu-ppce500_defconfig
diff --git a/board/freescale/qemu-ppce500/Makefile b/board/emulation/qemu-ppce500/Makefile
similarity index 100%
rename from board/freescale/qemu-ppce500/Makefile
rename to board/emulation/qemu-ppce500/Makefile
diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c b/board/emulation/qemu-ppce500/qemu-ppce500.c
similarity index 99%
rename from board/freescale/qemu-ppce500/qemu-ppce500.c
rename to board/emulation/qemu-ppce500/qemu-ppce500.c
index 7d711b8..daa103c 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/emulation/qemu-ppce500/qemu-ppce500.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2007,2009-2014 Freescale Semiconductor, Inc.
+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
*/
#include <common.h>
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 37/38] ppc: qemu: Move board directory from board/freescale to board/emulation
2021-02-18 15:58 ` [PATCH v2 37/38] ppc: qemu: Move board directory from board/freescale to board/emulation Bin Meng
@ 2021-02-22 9:18 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:18 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 37/38] ppc: qemu: Move board directory from
>board/freescale to board/emulation
>
>board/emulation is the place for other QEMU targets like x86, arm, riscv. Let's
>move the qemu-ppce500 board codes there.
>
>List me as a co-maintainer for this board.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>---
>
>(no changes since v1)
>
> arch/powerpc/cpu/mpc85xx/Kconfig | 2 +-
> board/{freescale => emulation}/qemu-ppce500/Kconfig | 2 +-
> board/{freescale => emulation}/qemu-ppce500/MAINTAINERS | 3 ++-
> board/{freescale => emulation}/qemu-ppce500/Makefile | 0
> board/{freescale => emulation}/qemu-ppce500/qemu-ppce500.c | 1 +
> 5 files changed, 5 insertions(+), 3 deletions(-) rename board/{freescale =>
>emulation}/qemu-ppce500/Kconfig (86%) rename board/{freescale =>
>emulation}/qemu-ppce500/MAINTAINERS (67%) rename board/{freescale =>
>emulation}/qemu-ppce500/Makefile (100%) rename board/{freescale =>
>emulation}/qemu-ppce500/qemu-ppce500.c (99%)
>
>diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig
>b/arch/powerpc/cpu/mpc85xx/Kconfig
>index 870ab80..f59801a 100644
>--- a/arch/powerpc/cpu/mpc85xx/Kconfig
>+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
>@@ -1428,6 +1428,7 @@ config SYS_FSL_LBC_CLK_DIV
> Defines divider of platform clock(clock input to
> eLBC controller).
>
>+source "board/emulation/qemu-ppce500/Kconfig"
> source "board/freescale/corenet_ds/Kconfig"
> source "board/freescale/mpc8541cds/Kconfig"
> source "board/freescale/mpc8548cds/Kconfig"
>@@ -1437,7 +1438,6 @@ source "board/freescale/mpc8569mds/Kconfig"
> source "board/freescale/p1010rdb/Kconfig"
> source "board/freescale/p1_p2_rdb_pc/Kconfig"
> source "board/freescale/p2041rdb/Kconfig"
>-source "board/freescale/qemu-ppce500/Kconfig"
> source "board/freescale/t102xrdb/Kconfig"
> source "board/freescale/t104xrdb/Kconfig"
> source "board/freescale/t208xqds/Kconfig"
>diff --git a/board/freescale/qemu-ppce500/Kconfig
>b/board/emulation/qemu-ppce500/Kconfig
>similarity index 86%
>rename from board/freescale/qemu-ppce500/Kconfig
>rename to board/emulation/qemu-ppce500/Kconfig
>index 236cd17..4312d98 100644
>--- a/board/freescale/qemu-ppce500/Kconfig
>+++ b/board/emulation/qemu-ppce500/Kconfig
>@@ -4,7 +4,7 @@ config SYS_BOARD
> default "qemu-ppce500"
>
> config SYS_VENDOR
>- default "freescale"
>+ default "emulation"
>
> config SYS_CONFIG_NAME
> default "qemu-ppce500"
>diff --git a/board/freescale/qemu-ppce500/MAINTAINERS
>b/board/emulation/qemu-ppce500/MAINTAINERS
>similarity index 67%
>rename from board/freescale/qemu-ppce500/MAINTAINERS
>rename to board/emulation/qemu-ppce500/MAINTAINERS
>index e70c095..7317983 100644
>--- a/board/freescale/qemu-ppce500/MAINTAINERS
>+++ b/board/emulation/qemu-ppce500/MAINTAINERS
>@@ -1,6 +1,7 @@
> QEMU-PPCE500 BOARD
> M: Alexander Graf <agraf@csgraf.de>
>+M: Bin Meng <bmeng.cn@gmail.com>
> S: Maintained
>-F: board/freescale/qemu-ppce500/
>+F: board/emulation/qemu-ppce500/
> F: include/configs/qemu-ppce500.h
> F: configs/qemu-ppce500_defconfig
>diff --git a/board/freescale/qemu-ppce500/Makefile
>b/board/emulation/qemu-ppce500/Makefile
>similarity index 100%
>rename from board/freescale/qemu-ppce500/Makefile
>rename to board/emulation/qemu-ppce500/Makefile
>diff --git a/board/freescale/qemu-ppce500/qemu-ppce500.c
>b/board/emulation/qemu-ppce500/qemu-ppce500.c
>similarity index 99%
>rename from board/freescale/qemu-ppce500/qemu-ppce500.c
>rename to board/emulation/qemu-ppce500/qemu-ppce500.c
>index 7d711b8..daa103c 100644
>--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
>+++ b/board/emulation/qemu-ppce500/qemu-ppce500.c
>@@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * Copyright 2007,2009-2014 Freescale Semiconductor, Inc.
>+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
> */
>
> #include <common.h>
>--
>2.7.4
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* [PATCH v2 38/38] doc: Add a reST document for qemu-ppce500
2021-02-18 15:57 ` Bin Meng
` (37 preceding siblings ...)
(?)
@ 2021-02-18 15:58 ` Bin Meng
2021-02-22 9:18 ` Priyanka Jain
-1 siblings, 1 reply; 96+ messages in thread
From: Bin Meng @ 2021-02-18 15:58 UTC (permalink / raw)
To: u-boot
Add a reST document to describe how to build and run U-Boot for
the QEMU ppce500 machine.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- add descriptions for VirtIO BLK, RTC and power off
doc/board/emulation/index.rst | 1 +
doc/board/emulation/qemu-ppce500.rst | 88 ++++++++++++++++++++++++++++++++++++
2 files changed, 89 insertions(+)
create mode 100644 doc/board/emulation/qemu-ppce500.rst
diff --git a/doc/board/emulation/index.rst b/doc/board/emulation/index.rst
index a09ead1..be66b6b 100644
--- a/doc/board/emulation/index.rst
+++ b/doc/board/emulation/index.rst
@@ -8,6 +8,7 @@ Emulation
qemu-arm
qemu-mips
+ qemu-ppce500
qemu-riscv
qemu-x86
qemu_capsule_update
diff --git a/doc/board/emulation/qemu-ppce500.rst b/doc/board/emulation/qemu-ppce500.rst
new file mode 100644
index 0000000..0a5c86c
--- /dev/null
+++ b/doc/board/emulation/qemu-ppce500.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+
+QEMU PPC E500
+=============
+
+QEMU for PPC supports a special 'ppce500' machine designed for emulation and
+virtualization purposes. This document describes how to run U-Boot under it.
+
+The QEMU ppce500 machine models a generic PowerPC E500 virtual machine with
+support for the VirtIO standard networking device connected to the built-in
+PCI host controller. Some common devices in the CCSBAR space are modeled,
+including MPIC, 16550A UART devices, GPIO, I2C and PCI host controller with
+MSI delivery to MPIC. It uses device-tree to pass configuration information
+to guest software.
+
+Building U-Boot
+---------------
+Set the CROSS_COMPILE environment variable as usual, and run::
+
+ $ make qemu-ppce500_defconfig
+ $ make
+
+Running U-Boot
+--------------
+The minimal QEMU command line to get U-Boot up and running is::
+
+ $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot
+
+You can also run U-Boot using 'qemu-system-ppc64'::
+
+ $ qemu-system-ppc64 -nographic -machine ppce500 -bios u-boot
+
+The commands above create a target with 128 MiB memory by default. A freely
+configurable amount of RAM can be created via the '-m' parameter. For example,
+'-m 2G' creates 2 GiB memory for the target, and the memory node in the
+embedded DTB created by QEMU reflects the new setting.
+
+Both qemu-system-ppc and qemu-system-ppc64 provide emulation for the following
+32-bit PowerPC CPUs:
+
+* e500v2
+* e500mc
+
+Additionally qemu-system-ppc64 provides support for the following 64-bit CPUs:
+
+* e5500
+* e6500
+
+The CPU type can be specified via the '-cpu' command line. If not specified,
+it creates a machine with e500v2 core. The following example shows an e6500
+based machine creation::
+
+ $ qemu-system-ppc64 -nographic -machine ppce500 -cpu e6500 -bios u-boot
+
+When U-Boot boots, you will notice the following::
+
+ CPU: Unknown, Version: 0.0, (0x00000000)
+ Core: e6500, Version: 2.0, (0x80400020)
+
+This is because we only specified a core name to QEMU and it does not have a
+meaningful SVR value which represents an actual SoC that integrates such core.
+You can specify a real world SoC device that QEMU has built-in support but all
+these SoCs are e500v2 based MPC85xx series, hence you cannot test anything
+built for P4080 (e500mc), P5020 (e5500) and T2080 (e6500).
+
+By default a VirtIO standard PCI networking device is connected as an ethernet
+interface at PCI address 0.1.0, but we can switch that to an e1000 NIC by::
+
+ $ qemu-system-ppc -nographic -machine ppce500 -bios u-boot \
+ -nic tap,ifname=tap0,script=no,downscript=no,model=e1000
+
+VirtIO BLK driver is also enabled to support booting from a disk image where
+a kernel image is stored. Append the following to QEMU::
+
+ -drive file=disk.img,format=raw,id=disk0 -device virtio-blk-pci,drive=disk0
+
+Pericom pt7c4338 RTC is supported so we can use the 'date' command::
+
+ => date
+ Date: 2021-02-18 (Thursday) Time: 15:33:20
+
+Additionally, 'poweroff' command is supported to shut down the QEMU session::
+
+ => poweroff
+ poweroff ...
+
+These have been tested in QEMU 5.2.0.
--
2.7.4
^ permalink raw reply related [flat|nested] 96+ messages in thread* [PATCH v2 38/38] doc: Add a reST document for qemu-ppce500
2021-02-18 15:58 ` [PATCH v2 38/38] doc: Add a reST document for qemu-ppce500 Bin Meng
@ 2021-02-22 9:18 ` Priyanka Jain
0 siblings, 0 replies; 96+ messages in thread
From: Priyanka Jain @ 2021-02-22 9:18 UTC (permalink / raw)
To: u-boot
>-----Original Message-----
>From: Bin Meng <bmeng.cn@gmail.com>
>Sent: Thursday, February 18, 2021 9:28 PM
>To: Simon Glass <sjg@chromium.org>; Alexander Graf <agraf@csgraf.de>;
>Priyanka Jain <priyanka.jain@nxp.com>
>Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini
><trini@konsulko.com>
>Subject: [PATCH v2 38/38] doc: Add a reST document for qemu-ppce500
>
>Add a reST document to describe how to build and run U-Boot for the QEMU
>ppce500 machine.
>
>Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>Reviewed-by: Simon Glass <sjg@chromium.org>
>
>---
>
>Changes in v2:
>- add descriptions for VirtIO BLK, RTC and power off
>
> doc/board/emulation/index.rst | 1 +
> doc/board/emulation/qemu-ppce500.rst | 88
>++++++++++++++++++++++++++++++++++++
> 2 files changed, 89 insertions(+)
> create mode 100644 doc/board/emulation/qemu-ppce500.rst
>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
^ permalink raw reply [flat|nested] 96+ messages in thread
* Re: [PATCH v2 00/38] ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support
2021-02-18 15:57 ` Bin Meng
@ 2021-02-19 1:29 ` Bin Meng
-1 siblings, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-19 1:29 UTC (permalink / raw)
To: Simon Glass, Alexander Graf, Priyanka Jain
Cc: Tom Rini, Matthias Brugger, qemu-devel@nongnu.org Developers,
U-Boot Mailing List, qemu-ppc, Heiko Schocher, Marek Szyprowski
On Thu, Feb 18, 2021 at 11:58 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> At present when building qemu-ppce500 the following warnings are seen:
>
> ===================== WARNING ======================
> This board does not use CONFIG_DM. CONFIG_DM will be
> compulsory starting with the v2020.01 release.
> Failure to update may result in board removal.
> UPD include/generated/timestamp_autogenerated.h
> See doc/driver-model/migration.rst for more info.
> ====================================================
> ===================== WARNING ======================
> This board does not use CONFIG_DM_PCI Please update
> the board to use CONFIG_DM_PCI before the v2019.07 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
> ====================================================
> ===================== WARNING ======================
> This board does not use CONFIG_DM_ETH (Driver Model
> for Ethernet drivers). Please update the board to use
> CONFIG_DM_ETH before the v2020.07 release. Failure to
> update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
> ====================================================
>
> The conversion of qemu-ppce500 board to driver model is long overdue.
>
> When testing the exisitng qemu-ppce500 support, PCI was found broken.
> This is caused by 2 separate issues:
>
> - One issue was caused by U-Boot:
> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> Patch #1 updated the non-DM fsl_pci_init driver to dynamically allocate the
> PCI regions, to keep in sync with the pci uclass driver
> - One issue was caused by QEMU:
> commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
> commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
> Patch #3-4 fixed this issue to keep in sync with latest QEMU upstream
>
> Patch #5-8, #34-36 are minor fixes and clean-ups.
>
> Starting from patch#9, these are driver model conversion patches.
>
> Patch #11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets
> that have non-identity virtual-physical address mappings. A new command 'addrmap'
> is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
> made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
> relocation phase. Also the initialization of this library is moved a bit earlier
> in the post-relocation phase otherwise device drivers won't work.
>
> Patch #19-21 are 85xx PCI driver fixes. It adds support to controller register
> physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
> as current upstream QEMU uses 64-bit cpu address.
>
> Starting from patch#24, these are additional driver support patches.
>
> Patch #24, #26 are minor fix to the 'virtio' command and BLK driver dependency.
>
> Patch #25 enables the VirtIO NET support as by default a VirtIO standard PCI
> networking device is connected as an ethernet interface at PCI address 0.1.0.
>
> Patch #27 enables the VirtIO BLK driver support.
>
> Patch #28-30 enables the GPIO support.
>
> Patch #31-32 enables poweroff via GPIO.
>
> Patch #33 enables RTC over the I2C bus.
>
> Patch #37 moves the qemu-ppce500 boards codes to board/emulation as that is the
> place for other QEMU targets like x86, arm, riscv.
>
> Patch #38 adds a reST document to describe how to build and run U-Boot for the
> QEMU ppce500 machine.
>
> I hope we can make this series to U-Boot v2021.04 release.
>
> This series is available at u-boot-x86/qemu-ppc for testing.
>
> This cover letter is cc'ed to QEMU mailing list for a heads-up.
> A future patch will be sent to QEMU mailing list to bring its in-tree
> U-Boot source codes up-to-date.
>
> Changes in v2:
> - drop the revert patch of commit e002474158d1
> - new patch: pci: fsl_pci_init: Dynamically allocate the PCI regions
> - add more details in the commit message, and put some comments
> in the codes to explain why
> - add doc/usage/addrmap.rst
> - new patch: test: cmd: Add a basic test for 'addrmap' command
> - new patch: virtio: Fix VirtIO BLK driver dependency
> - new patch: ppc: qemu: Enable VirtIO BLK support
> - new patch: ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
> - new patch: gpio: mpc8xxx: Support controller register physical address beyond 32-bit
> - new patch: ppc: qemu: Enable GPIO support
> - new patch: dm: sysreset: Add a Kconfig option for the 'reset' command
> - new patch: ppc: qemu: Enable support for power off via GPIO
> - new patch: ppc: qemu: Enable RTC support via I2C
> - new patch: ppc: qemu: Delete the temporary FDT virtual-physical mapping after U-Boot is relocated
> - new patch: ppc: qemu: Drop a custom env variable 'fdt_addr_r'
> - new patch: ppc: qemu: Drop fixed_sdram()
> - add descriptions for VirtIO BLK, RTC and power off
>
Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=324&view=results
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread* [PATCH v2 00/38] ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support
@ 2021-02-19 1:29 ` Bin Meng
0 siblings, 0 replies; 96+ messages in thread
From: Bin Meng @ 2021-02-19 1:29 UTC (permalink / raw)
To: u-boot
On Thu, Feb 18, 2021 at 11:58 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> At present when building qemu-ppce500 the following warnings are seen:
>
> ===================== WARNING ======================
> This board does not use CONFIG_DM. CONFIG_DM will be
> compulsory starting with the v2020.01 release.
> Failure to update may result in board removal.
> UPD include/generated/timestamp_autogenerated.h
> See doc/driver-model/migration.rst for more info.
> ====================================================
> ===================== WARNING ======================
> This board does not use CONFIG_DM_PCI Please update
> the board to use CONFIG_DM_PCI before the v2019.07 release.
> Failure to update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
> ====================================================
> ===================== WARNING ======================
> This board does not use CONFIG_DM_ETH (Driver Model
> for Ethernet drivers). Please update the board to use
> CONFIG_DM_ETH before the v2020.07 release. Failure to
> update by the deadline may result in board removal.
> See doc/driver-model/migration.rst for more info.
> ====================================================
>
> The conversion of qemu-ppce500 board to driver model is long overdue.
>
> When testing the exisitng qemu-ppce500 support, PCI was found broken.
> This is caused by 2 separate issues:
>
> - One issue was caused by U-Boot:
> Commit e002474158d1 ("pci: pci-uclass: Dynamically allocate the PCI regions")
> Patch #1 updated the non-DM fsl_pci_init driver to dynamically allocate the
> PCI regions, to keep in sync with the pci uclass driver
> - One issue was caused by QEMU:
> commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space")
> commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs")
> Patch #3-4 fixed this issue to keep in sync with latest QEMU upstream
>
> Patch #5-8, #34-36 are minor fixes and clean-ups.
>
> Starting from patch#9, these are driver model conversion patches.
>
> Patch #11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets
> that have non-identity virtual-physical address mappings. A new command 'addrmap'
> is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is
> made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post-
> relocation phase. Also the initialization of this library is moved a bit earlier
> in the post-relocation phase otherwise device drivers won't work.
>
> Patch #19-21 are 85xx PCI driver fixes. It adds support to controller register
> physical address beyond 32-bit, as well as support to 64-bit bus and cpu address
> as current upstream QEMU uses 64-bit cpu address.
>
> Starting from patch#24, these are additional driver support patches.
>
> Patch #24, #26 are minor fix to the 'virtio' command and BLK driver dependency.
>
> Patch #25 enables the VirtIO NET support as by default a VirtIO standard PCI
> networking device is connected as an ethernet interface at PCI address 0.1.0.
>
> Patch #27 enables the VirtIO BLK driver support.
>
> Patch #28-30 enables the GPIO support.
>
> Patch #31-32 enables poweroff via GPIO.
>
> Patch #33 enables RTC over the I2C bus.
>
> Patch #37 moves the qemu-ppce500 boards codes to board/emulation as that is the
> place for other QEMU targets like x86, arm, riscv.
>
> Patch #38 adds a reST document to describe how to build and run U-Boot for the
> QEMU ppce500 machine.
>
> I hope we can make this series to U-Boot v2021.04 release.
>
> This series is available at u-boot-x86/qemu-ppc for testing.
>
> This cover letter is cc'ed to QEMU mailing list for a heads-up.
> A future patch will be sent to QEMU mailing list to bring its in-tree
> U-Boot source codes up-to-date.
>
> Changes in v2:
> - drop the revert patch of commit e002474158d1
> - new patch: pci: fsl_pci_init: Dynamically allocate the PCI regions
> - add more details in the commit message, and put some comments
> in the codes to explain why
> - add doc/usage/addrmap.rst
> - new patch: test: cmd: Add a basic test for 'addrmap' command
> - new patch: virtio: Fix VirtIO BLK driver dependency
> - new patch: ppc: qemu: Enable VirtIO BLK support
> - new patch: ppc: mpc85xx: Add 'gpibe' register to 'struct ccsr_gpio'
> - new patch: gpio: mpc8xxx: Support controller register physical address beyond 32-bit
> - new patch: ppc: qemu: Enable GPIO support
> - new patch: dm: sysreset: Add a Kconfig option for the 'reset' command
> - new patch: ppc: qemu: Enable support for power off via GPIO
> - new patch: ppc: qemu: Enable RTC support via I2C
> - new patch: ppc: qemu: Delete the temporary FDT virtual-physical mapping after U-Boot is relocated
> - new patch: ppc: qemu: Drop a custom env variable 'fdt_addr_r'
> - new patch: ppc: qemu: Drop fixed_sdram()
> - add descriptions for VirtIO BLK, RTC and power off
>
Azure results: PASS
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=324&view=results
Regards,
Bin
^ permalink raw reply [flat|nested] 96+ messages in thread