* [PATCH 00/26] ppc: qemu: Convert qemu-ppce500 to driver model
@ 2021-02-07 15:11 ` Bin Meng
0 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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 reverts this commit as it broken all boards that have not converted
to driver model PCI.
- 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 are minor fixes and clean-ups.
Starting from patch#9, these are driver model conversion patches.
Patch #11-16 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 #18-20 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.
Patch #23 is minor fix to the 'virtio' command dependency.
Patch #24 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 #25 moves the qemu-ppce500 boards codes to board/emulation as that is the
place for other QEMU targets like x86, arm, riscv.
Patch #26 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.
Bin Meng (26):
Revert "pci: pci-uclass: 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
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
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/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 | 159 ++++++---------------
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 | 15 +-
configs/qemu-ppce500_defconfig | 14 +-
doc/board/emulation/index.rst | 1 +
doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++
drivers/pci/pci-uclass.c | 14 +-
drivers/pci/pci_mpc85xx.c | 25 ++--
include/addr_map.h | 16 ++-
include/configs/qemu-ppce500.h | 25 +---
include/pci.h | 4 +-
lib/Kconfig | 2 +
lib/addr_map.c | 6 +-
24 files changed, 250 insertions(+), 190 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 (68%)
delete mode 100644 board/freescale/qemu-ppce500/MAINTAINERS
create mode 100644 cmd/addrmap.c
create mode 100644 doc/board/emulation/qemu-ppce500.rst
--
2.7.4
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-07 15:11 ` Bin Meng
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-07 15:33 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 UTC (permalink / raw)
To: u-boot
This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
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.
We may update every non-DM PCI board codes to do the dynamical
allocation of PCI regions but that's a lot of work (e.g.: almost
all Freescale PowerPC boards are broken now and need to be fixed).
Let's do the easy way.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
drivers/pci/pci-uclass.c | 14 ++++++--------
include/pci.h | 4 +++-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index ba65f47..8a94ea2 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -907,7 +907,6 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node,
int cells_per_record;
struct bd_info *bd;
const u32 *prop;
- int max_regions;
int len;
int i;
@@ -927,13 +926,7 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node,
hose->region_count = 0;
debug("%s: len=%d, cells_per_record=%d\n", __func__, len,
cells_per_record);
-
- /* Dynamically allocate the regions array */
- max_regions = len / cells_per_record + CONFIG_NR_DRAM_BANKS;
- hose->regions = (struct pci_region *)
- calloc(1, max_regions * sizeof(struct pci_region));
-
- for (i = 0; i < max_regions; i++, len -= cells_per_record) {
+ for (i = 0; i < MAX_PCI_REGIONS; i++, len -= cells_per_record) {
u64 pci_addr, addr, size;
int space_code;
u32 flags;
@@ -987,6 +980,11 @@ static void decode_regions(struct pci_controller *hose, ofnode parent_node,
return;
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
+ if (hose->region_count == MAX_PCI_REGIONS) {
+ pr_err("maximum number of regions parsed, aborting\n");
+ break;
+ }
+
if (bd->bi_dram[i].size) {
pci_set_region(hose->regions + hose->region_count++,
bd->bi_dram[i].start,
diff --git a/include/pci.h b/include/pci.h
index 5f36537..64dff55 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -610,6 +610,8 @@ extern void pci_cfgfunc_do_nothing(struct pci_controller* hose, pci_dev_t dev,
extern void pci_cfgfunc_config_device(struct pci_controller* hose, pci_dev_t dev,
struct pci_config_table *);
+#define MAX_PCI_REGIONS 7
+
#define INDIRECT_TYPE_NO_PCIE_LINK 1
/**
@@ -650,7 +652,7 @@ struct pci_controller {
* for PCI controllers and a separate UCLASS (or perhaps
* UCLASS_PCI_GENERIC) is used for bridges.
*/
- struct pci_region *regions;
+ struct pci_region regions[MAX_PCI_REGIONS];
int region_count;
struct pci_config_table *config_table;
--
2.7.4
^ permalink raw reply related [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-07 15:11 ` [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions" Bin Meng
@ 2021-02-07 15:33 ` Simon Glass
2021-02-07 19:33 ` Tom Rini
2021-02-10 0:46 ` Bin Meng
0 siblings, 2 replies; 63+ messages in thread
From: Simon Glass @ 2021-02-07 15:33 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>
> 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.
>
> We may update every non-DM PCI board codes to do the dynamical
> allocation of PCI regions but that's a lot of work (e.g.: almost
> all Freescale PowerPC boards are broken now and need to be fixed).
> Let's do the easy way.
No one has noticed since July, apparently. I think it would be better
to disable PCI on these boards, until either someone migrates them or
they are removed. The PCI deadline was about 18 months ago.
Tom, do you know the situation here?
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> drivers/pci/pci-uclass.c | 14 ++++++--------
> include/pci.h | 4 +++-
> 2 files changed, 9 insertions(+), 9 deletions(-)
Regards,
Simon
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-07 15:33 ` Simon Glass
@ 2021-02-07 19:33 ` Tom Rini
2021-02-10 0:46 ` Bin Meng
1 sibling, 0 replies; 63+ messages in thread
From: Tom Rini @ 2021-02-07 19:33 UTC (permalink / raw)
To: u-boot
On Sun, Feb 07, 2021 at 08:33:50AM -0700, Simon Glass wrote:
> Hi Bin,
>
> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> >
> > 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.
> >
> > We may update every non-DM PCI board codes to do the dynamical
> > allocation of PCI regions but that's a lot of work (e.g.: almost
> > all Freescale PowerPC boards are broken now and need to be fixed).
> > Let's do the easy way.
>
> No one has noticed since July, apparently. I think it would be better
> to disable PCI on these boards, until either someone migrates them or
> they are removed. The PCI deadline was about 18 months ago.
>
> Tom, do you know the situation here?
I want to hear what Priyanka has to say, as there's been an effort a
few times on NXP's part to remove boards they don't want to maintain
anymore.
Outside of that, I do keep meaning to, but not quite finding the time
to, pick a random well-past migration deadline, make it fatal, and then
go start removing boards. I think I'll go pick a not-PCI (as some
number of PowerPC ones will fail, and that's not as interesting until
Priyanka can chime in) one right now and see what fails there.
--
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/20210207/e092fc24/attachment.sig>
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-07 15:33 ` Simon Glass
2021-02-07 19:33 ` Tom Rini
@ 2021-02-10 0:46 ` Bin Meng
2021-02-10 2:36 ` Tom Rini
` (2 more replies)
1 sibling, 3 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-10 0:46 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> >
> > 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.
> >
> > We may update every non-DM PCI board codes to do the dynamical
> > allocation of PCI regions but that's a lot of work (e.g.: almost
> > all Freescale PowerPC boards are broken now and need to be fixed).
> > Let's do the easy way.
>
> No one has noticed since July, apparently. I think it would be better
> to disable PCI on these boards, until either someone migrates them or
> they are removed. The PCI deadline was about 18 months ago.
>
Yep, but I'd like to keep this revert instead of just fixing the
qemu-ppce500 here, to give people a chance to test their original
non-DM version of PCI driver before the DM conversion.
Once all boards have converted to DM PCI, we can revert this revert patch again.
> Tom, do you know the situation here?
>
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> > drivers/pci/pci-uclass.c | 14 ++++++--------
> > include/pci.h | 4 +++-
> > 2 files changed, 9 insertions(+), 9 deletions(-)
Regards,
Bin
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 0:46 ` Bin Meng
@ 2021-02-10 2:36 ` Tom Rini
2021-02-10 5:10 ` Simon Glass
2021-02-10 14:13 ` Tom Rini
2 siblings, 0 replies; 63+ messages in thread
From: Tom Rini @ 2021-02-10 2:36 UTC (permalink / raw)
To: u-boot
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> Hi Simon,
>
> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > >
> > > 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.
> > >
> > > We may update every non-DM PCI board codes to do the dynamical
> > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > Let's do the easy way.
> >
> > No one has noticed since July, apparently. I think it would be better
> > to disable PCI on these boards, until either someone migrates them or
> > they are removed. The PCI deadline was about 18 months ago.
> >
>
> Yep, but I'd like to keep this revert instead of just fixing the
> qemu-ppce500 here, to give people a chance to test their original
> non-DM version of PCI driver before the DM conversion.
>
> Once all boards have converted to DM PCI, we can revert this revert patch again.
I'm not quite sure as a number of PowerPC boards did convert. I will
see what's left, on top of the series I'm currently testing that deals
with LIBATA+AHCI (and in turn kills off some PowerPC stuff).
--
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/20210209/3007e9ea/attachment.sig>
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 0:46 ` Bin Meng
2021-02-10 2:36 ` Tom Rini
@ 2021-02-10 5:10 ` Simon Glass
2021-02-10 7:13 ` Stefan Roese
2021-02-10 14:13 ` Tom Rini
2 siblings, 1 reply; 63+ messages in thread
From: Simon Glass @ 2021-02-10 5:10 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Tue, 9 Feb 2021 at 17:47, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > >
> > > 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.
> > >
> > > We may update every non-DM PCI board codes to do the dynamical
> > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > Let's do the easy way.
> >
> > No one has noticed since July, apparently. I think it would be better
> > to disable PCI on these boards, until either someone migrates them or
> > they are removed. The PCI deadline was about 18 months ago.
> >
>
> Yep, but I'd like to keep this revert instead of just fixing the
> qemu-ppce500 here, to give people a chance to test their original
> non-DM version of PCI driver before the DM conversion.
>
> Once all boards have converted to DM PCI, we can revert this revert patch again.
I'm fine with that if Tom is. But deleting unmaintained code is always
another option!
>
> > Tom, do you know the situation here?
> >
Regards,
Simon
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 5:10 ` Simon Glass
@ 2021-02-10 7:13 ` Stefan Roese
0 siblings, 0 replies; 63+ messages in thread
From: Stefan Roese @ 2021-02-10 7:13 UTC (permalink / raw)
To: u-boot
Hi Simon, Bin & Tom,
On 10.02.21 06:10, Simon Glass wrote:
> Hi Bin,
>
> On Tue, 9 Feb 2021 at 17:47, Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> Hi Simon,
>>
>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>
>>> Hi Bin,
>>>
>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>
>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>
>>>> 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.
>>>>
>>>> We may update every non-DM PCI board codes to do the dynamical
>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>> Let's do the easy way.
>>>
>>> No one has noticed since July, apparently. I think it would be better
>>> to disable PCI on these boards, until either someone migrates them or
>>> they are removed. The PCI deadline was about 18 months ago.
>>>
>>
>> Yep, but I'd like to keep this revert instead of just fixing the
>> qemu-ppce500 here, to give people a chance to test their original
>> non-DM version of PCI driver before the DM conversion.
>>
>> Once all boards have converted to DM PCI, we can revert this revert patch again.
>
> I'm fine with that if Tom is. But deleting unmaintained code is always
> another option!
Sorry for chiming in this late in this discussion. If we decide to
revert this patch, this will break OcteonTX/TX2 support. As we need
a higher value for the PCI regions here. Originally we just increased
MAX_PCI_REGIONS to 10. This dynamic allocation superseeded this change.
This increase might introduce size issues on other platforms though.
So please keep this in mind that with the revert the value of
MAX_PCI_REGIONS needs to get increased to 10 - at least for Octeon TX.
Thanks,
Stefan
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 0:46 ` Bin Meng
2021-02-10 2:36 ` Tom Rini
2021-02-10 5:10 ` Simon Glass
@ 2021-02-10 14:13 ` Tom Rini
2021-02-10 14:27 ` Marek Vasut
2021-02-14 4:53 ` Bin Meng
2 siblings, 2 replies; 63+ messages in thread
From: Tom Rini @ 2021-02-10 14:13 UTC (permalink / raw)
To: u-boot
On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> Hi Simon,
>
> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > >
> > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > >
> > > 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.
> > >
> > > We may update every non-DM PCI board codes to do the dynamical
> > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > Let's do the easy way.
> >
> > No one has noticed since July, apparently. I think it would be better
> > to disable PCI on these boards, until either someone migrates them or
> > they are removed. The PCI deadline was about 18 months ago.
> >
>
> Yep, but I'd like to keep this revert instead of just fixing the
> qemu-ppce500 here, to give people a chance to test their original
> non-DM version of PCI driver before the DM conversion.
>
> Once all boards have converted to DM PCI, we can revert this revert patch again.
>
> > Tom, do you know the situation here?
So, I made a lack of DM_PCI migration be fatal and got a build done
here:
https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
Of note, MIPS malta fails, so I had to drop that from pytest to complete
the world build. There's then a handful of ARM boards, another large
chunk of PowerPC, and then a few others such as r7780mp. SH is the big
what to do here to me, other than PowerPC, as other than r2dplus
everything is missing the main "convert to DM" migration deadline as
well.
--
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/20210210/8af0d233/attachment.sig>
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 14:13 ` Tom Rini
@ 2021-02-10 14:27 ` Marek Vasut
2021-02-10 14:48 ` Tom Rini
2021-02-14 4:53 ` Bin Meng
1 sibling, 1 reply; 63+ messages in thread
From: Marek Vasut @ 2021-02-10 14:27 UTC (permalink / raw)
To: u-boot
On 2/10/21 3:13 PM, Tom Rini wrote:
> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
>> Hi Simon,
>>
>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>
>>> Hi Bin,
>>>
>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>
>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>
>>>> 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.
>>>>
>>>> We may update every non-DM PCI board codes to do the dynamical
>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>> Let's do the easy way.
>>>
>>> No one has noticed since July, apparently. I think it would be better
>>> to disable PCI on these boards, until either someone migrates them or
>>> they are removed. The PCI deadline was about 18 months ago.
>>>
>>
>> Yep, but I'd like to keep this revert instead of just fixing the
>> qemu-ppce500 here, to give people a chance to test their original
>> non-DM version of PCI driver before the DM conversion.
>>
>> Once all boards have converted to DM PCI, we can revert this revert patch again.
>>
>>> Tom, do you know the situation here?
>
> So, I made a lack of DM_PCI migration be fatal and got a build done
> here:
> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
>
> Of note, MIPS malta fails, so I had to drop that from pytest to complete
> the world build. There's then a handful of ARM boards, another large
> chunk of PowerPC, and then a few others such as r7780mp. SH is the big
> what to do here to me, other than PowerPC, as other than r2dplus
> everything is missing the main "convert to DM" migration deadline as
> well.
Anything SH except r2dplus is likely dead.
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 14:27 ` Marek Vasut
@ 2021-02-10 14:48 ` Tom Rini
2021-02-10 14:50 ` Marek Vasut
0 siblings, 1 reply; 63+ messages in thread
From: Tom Rini @ 2021-02-10 14:48 UTC (permalink / raw)
To: u-boot
On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:
> On 2/10/21 3:13 PM, Tom Rini wrote:
> > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > >
> > > > > 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.
> > > > >
> > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > Let's do the easy way.
> > > >
> > > > No one has noticed since July, apparently. I think it would be better
> > > > to disable PCI on these boards, until either someone migrates them or
> > > > they are removed. The PCI deadline was about 18 months ago.
> > > >
> > >
> > > Yep, but I'd like to keep this revert instead of just fixing the
> > > qemu-ppce500 here, to give people a chance to test their original
> > > non-DM version of PCI driver before the DM conversion.
> > >
> > > Once all boards have converted to DM PCI, we can revert this revert patch again.
> > >
> > > > Tom, do you know the situation here?
> >
> > So, I made a lack of DM_PCI migration be fatal and got a build done
> > here:
> > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> >
> > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > the world build. There's then a handful of ARM boards, another large
> > chunk of PowerPC, and then a few others such as r7780mp. SH is the big
> > what to do here to me, other than PowerPC, as other than r2dplus
> > everything is missing the main "convert to DM" migration deadline as
> > well.
>
> Anything SH except r2dplus is likely dead.
Shall I send a series to remove most of the boards then?
--
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/20210210/df7375ce/attachment.sig>
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 14:48 ` Tom Rini
@ 2021-02-10 14:50 ` Marek Vasut
0 siblings, 0 replies; 63+ messages in thread
From: Marek Vasut @ 2021-02-10 14:50 UTC (permalink / raw)
To: u-boot
On 2/10/21 3:48 PM, Tom Rini wrote:
> On Wed, Feb 10, 2021 at 03:27:22PM +0100, Marek Vasut wrote:
>> On 2/10/21 3:13 PM, Tom Rini wrote:
>>> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>>>
>>>>> Hi Bin,
>>>>>
>>>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>
>>>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> We may update every non-DM PCI board codes to do the dynamical
>>>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>>>> Let's do the easy way.
>>>>>
>>>>> No one has noticed since July, apparently. I think it would be better
>>>>> to disable PCI on these boards, until either someone migrates them or
>>>>> they are removed. The PCI deadline was about 18 months ago.
>>>>>
>>>>
>>>> Yep, but I'd like to keep this revert instead of just fixing the
>>>> qemu-ppce500 here, to give people a chance to test their original
>>>> non-DM version of PCI driver before the DM conversion.
>>>>
>>>> Once all boards have converted to DM PCI, we can revert this revert patch again.
>>>>
>>>>> Tom, do you know the situation here?
>>>
>>> So, I made a lack of DM_PCI migration be fatal and got a build done
>>> here:
>>> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
>>>
>>> Of note, MIPS malta fails, so I had to drop that from pytest to complete
>>> the world build. There's then a handful of ARM boards, another large
>>> chunk of PowerPC, and then a few others such as r7780mp. SH is the big
>>> what to do here to me, other than PowerPC, as other than r2dplus
>>> everything is missing the main "convert to DM" migration deadline as
>>> well.
>>
>> Anything SH except r2dplus is likely dead.
>
> Shall I send a series to remove most of the boards then?
You can.
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-10 14:13 ` Tom Rini
2021-02-10 14:27 ` Marek Vasut
@ 2021-02-14 4:53 ` Bin Meng
2021-02-14 14:35 ` Tom Rini
1 sibling, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-14 4:53 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Bin,
> > >
> > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > >
> > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > >
> > > > 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.
> > > >
> > > > We may update every non-DM PCI board codes to do the dynamical
> > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > Let's do the easy way.
> > >
> > > No one has noticed since July, apparently. I think it would be better
> > > to disable PCI on these boards, until either someone migrates them or
> > > they are removed. The PCI deadline was about 18 months ago.
> > >
> >
> > Yep, but I'd like to keep this revert instead of just fixing the
> > qemu-ppce500 here, to give people a chance to test their original
> > non-DM version of PCI driver before the DM conversion.
> >
> > Once all boards have converted to DM PCI, we can revert this revert patch again.
> >
> > > Tom, do you know the situation here?
>
> So, I made a lack of DM_PCI migration be fatal and got a build done
> here:
> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
>
> Of note, MIPS malta fails, so I had to drop that from pytest to complete
> the world build. There's then a handful of ARM boards, another large
> chunk of PowerPC, and then a few others such as r7780mp. SH is the big
> what to do here to me, other than PowerPC, as other than r2dplus
> everything is missing the main "convert to DM" migration deadline as
> well.
What should we do for this patch?
If the plan is to drop all boards that are not converted to DM PCI in
2021.04, I can drop this revert patch in v2.
Regards,
Bin
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-14 4:53 ` Bin Meng
@ 2021-02-14 14:35 ` Tom Rini
2021-02-14 14:44 ` Marek Vasut
0 siblings, 1 reply; 63+ messages in thread
From: Tom Rini @ 2021-02-14 14:35 UTC (permalink / raw)
To: u-boot
On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
> Hi Tom,
>
> On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > >
> > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > >
> > > > > 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.
> > > > >
> > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > Let's do the easy way.
> > > >
> > > > No one has noticed since July, apparently. I think it would be better
> > > > to disable PCI on these boards, until either someone migrates them or
> > > > they are removed. The PCI deadline was about 18 months ago.
> > > >
> > >
> > > Yep, but I'd like to keep this revert instead of just fixing the
> > > qemu-ppce500 here, to give people a chance to test their original
> > > non-DM version of PCI driver before the DM conversion.
> > >
> > > Once all boards have converted to DM PCI, we can revert this revert patch again.
> > >
> > > > Tom, do you know the situation here?
> >
> > So, I made a lack of DM_PCI migration be fatal and got a build done
> > here:
> > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> >
> > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > the world build. There's then a handful of ARM boards, another large
> > chunk of PowerPC, and then a few others such as r7780mp. SH is the big
> > what to do here to me, other than PowerPC, as other than r2dplus
> > everything is missing the main "convert to DM" migration deadline as
> > well.
>
> What should we do for this patch?
>
> If the plan is to drop all boards that are not converted to DM PCI in
> 2021.04, I can drop this revert patch in v2.
I've posted the patch to drop the SH boards. Daniel, what about Malta?
I guess maybe the next steps are I need to pull in the already acked
board removal patches I've posted and then do another posting of "remove
these boards now" and see what shakes out.
--
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/20210214/411b1493/attachment.sig>
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-14 14:35 ` Tom Rini
@ 2021-02-14 14:44 ` Marek Vasut
2021-02-14 14:52 ` Tom Rini
0 siblings, 1 reply; 63+ messages in thread
From: Marek Vasut @ 2021-02-14 14:44 UTC (permalink / raw)
To: u-boot
On 2/14/21 3:35 PM, Tom Rini wrote:
> On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
>> Hi Tom,
>>
>> On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
>>>
>>> On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
>>>> Hi Simon,
>>>>
>>>> On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
>>>>>
>>>>> Hi Bin,
>>>>>
>>>>> On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>>>>
>>>>>> This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> We may update every non-DM PCI board codes to do the dynamical
>>>>>> allocation of PCI regions but that's a lot of work (e.g.: almost
>>>>>> all Freescale PowerPC boards are broken now and need to be fixed).
>>>>>> Let's do the easy way.
>>>>>
>>>>> No one has noticed since July, apparently. I think it would be better
>>>>> to disable PCI on these boards, until either someone migrates them or
>>>>> they are removed. The PCI deadline was about 18 months ago.
>>>>>
>>>>
>>>> Yep, but I'd like to keep this revert instead of just fixing the
>>>> qemu-ppce500 here, to give people a chance to test their original
>>>> non-DM version of PCI driver before the DM conversion.
>>>>
>>>> Once all boards have converted to DM PCI, we can revert this revert patch again.
>>>>
>>>>> Tom, do you know the situation here?
>>>
>>> So, I made a lack of DM_PCI migration be fatal and got a build done
>>> here:
>>> https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
>>>
>>> Of note, MIPS malta fails, so I had to drop that from pytest to complete
>>> the world build. There's then a handful of ARM boards, another large
>>> chunk of PowerPC, and then a few others such as r7780mp. SH is the big
>>> what to do here to me, other than PowerPC, as other than r2dplus
>>> everything is missing the main "convert to DM" migration deadline as
>>> well.
>>
>> What should we do for this patch?
>>
>> If the plan is to drop all boards that are not converted to DM PCI in
>> 2021.04, I can drop this revert patch in v2.
>
> I've posted the patch to drop the SH boards. Daniel, what about Malta?
Malta should be fixed, since it's mips used in CI.
> I guess maybe the next steps are I need to pull in the already acked
> board removal patches I've posted and then do another posting of "remove
> these boards now" and see what shakes out.
Yeah
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-14 14:44 ` Marek Vasut
@ 2021-02-14 14:52 ` Tom Rini
2021-02-14 19:12 ` Daniel Schwierzeck
0 siblings, 1 reply; 63+ messages in thread
From: Tom Rini @ 2021-02-14 14:52 UTC (permalink / raw)
To: u-boot
On Sun, Feb 14, 2021 at 03:44:26PM +0100, Marek Vasut wrote:
> On 2/14/21 3:35 PM, Tom Rini wrote:
> > On Sun, Feb 14, 2021 at 12:53:29PM +0800, Bin Meng wrote:
> > > Hi Tom,
> > >
> > > On Wed, Feb 10, 2021 at 10:13 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Feb 10, 2021 at 08:46:51AM +0800, Bin Meng wrote:
> > > > > Hi Simon,
> > > > >
> > > > > On Sun, Feb 7, 2021 at 11:34 PM Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > On Sun, 7 Feb 2021 at 08:11, Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > > >
> > > > > > > This reverts commit e002474158d1054a7a2ff9a66149384c639ff242.
> > > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > > > We may update every non-DM PCI board codes to do the dynamical
> > > > > > > allocation of PCI regions but that's a lot of work (e.g.: almost
> > > > > > > all Freescale PowerPC boards are broken now and need to be fixed).
> > > > > > > Let's do the easy way.
> > > > > >
> > > > > > No one has noticed since July, apparently. I think it would be better
> > > > > > to disable PCI on these boards, until either someone migrates them or
> > > > > > they are removed. The PCI deadline was about 18 months ago.
> > > > > >
> > > > >
> > > > > Yep, but I'd like to keep this revert instead of just fixing the
> > > > > qemu-ppce500 here, to give people a chance to test their original
> > > > > non-DM version of PCI driver before the DM conversion.
> > > > >
> > > > > Once all boards have converted to DM PCI, we can revert this revert patch again.
> > > > >
> > > > > > Tom, do you know the situation here?
> > > >
> > > > So, I made a lack of DM_PCI migration be fatal and got a build done
> > > > here:
> > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > >
> > > > Of note, MIPS malta fails, so I had to drop that from pytest to complete
> > > > the world build. There's then a handful of ARM boards, another large
> > > > chunk of PowerPC, and then a few others such as r7780mp. SH is the big
> > > > what to do here to me, other than PowerPC, as other than r2dplus
> > > > everything is missing the main "convert to DM" migration deadline as
> > > > well.
> > >
> > > What should we do for this patch?
> > >
> > > If the plan is to drop all boards that are not converted to DM PCI in
> > > 2021.04, I can drop this revert patch in v2.
> >
> > I've posted the patch to drop the SH boards. Daniel, what about Malta?
>
> Malta should be fixed, since it's mips used in CI.
There's also qemu_mips* in CI, so it depends on what Daniel thinks is
the right overall answer here.
--
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/20210214/73c59c45/attachment.sig>
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-14 14:52 ` Tom Rini
@ 2021-02-14 19:12 ` Daniel Schwierzeck
2021-02-14 20:30 ` Tom Rini
0 siblings, 1 reply; 63+ messages in thread
From: Daniel Schwierzeck @ 2021-02-14 19:12 UTC (permalink / raw)
To: u-boot
Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
...
> > > > > >
> > > > > > > Tom, do you know the situation here?
> > > > >
> > > > > So, I made a lack of DM_PCI migration be fatal and got a
> > > > > build done
> > > > > here:
> > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > > >
> > > > > Of note, MIPS malta fails, so I had to drop that from pytest
> > > > > to complete
> > > > > the world build. There's then a handful of ARM boards,
> > > > > another large
> > > > > chunk of PowerPC, and then a few others such as r7780mp. SH
> > > > > is the big
> > > > > what to do here to me, other than PowerPC, as other than
> > > > > r2dplus
> > > > > everything is missing the main "convert to DM" migration
> > > > > deadline as
> > > > > well.
> > > >
> > > > What should we do for this patch?
> > > >
> > > > If the plan is to drop all boards that are not converted to DM
> > > > PCI in
> > > > 2021.04, I can drop this revert patch in v2.
> > >
> > > I've posted the patch to drop the SH boards. Daniel, what about
> > > Malta?
> >
> > Malta should be fixed, since it's mips used in CI.
>
> There's also qemu_mips* in CI, so it depends on what Daniel thinks is
> the right overall answer here.
>
Malta is the MIPS reference board physically as well as in Qemu.
qemu_mips is actually deprecated and is going to be removed from Qemu
sooner or later. That's why I added Malta to CI with the goal to remove
qemu_mips.
The problem with MIPS and DM_PCI is that there are some generic issues
with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual
address. Actually I have a pending patch queue from Paul Burton for
Malta for converting to DM_PCI, but that requires resolving the generic
issues with some refactoring for all MIPS boards. It's still on my TODO
list ;)
Until I can spare enough time to resolve all issues, I could try to
disable the PCI driver in Malta defconfig and mark the driver as broken
in Kconfig. This way we can avoid removing the whole board.
--
- Daniel
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-14 19:12 ` Daniel Schwierzeck
@ 2021-02-14 20:30 ` Tom Rini
2021-02-18 0:32 ` Bin Meng
0 siblings, 1 reply; 63+ messages in thread
From: Tom Rini @ 2021-02-14 20:30 UTC (permalink / raw)
To: u-boot
On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote:
> Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
>
> ...
>
> > > > > > >
> > > > > > > > Tom, do you know the situation here?
> > > > > >
> > > > > > So, I made a lack of DM_PCI migration be fatal and got a
> > > > > > build done
> > > > > > here:
> > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > > > >
> > > > > > Of note, MIPS malta fails, so I had to drop that from pytest
> > > > > > to complete
> > > > > > the world build. There's then a handful of ARM boards,
> > > > > > another large
> > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH
> > > > > > is the big
> > > > > > what to do here to me, other than PowerPC, as other than
> > > > > > r2dplus
> > > > > > everything is missing the main "convert to DM" migration
> > > > > > deadline as
> > > > > > well.
> > > > >
> > > > > What should we do for this patch?
> > > > >
> > > > > If the plan is to drop all boards that are not converted to DM
> > > > > PCI in
> > > > > 2021.04, I can drop this revert patch in v2.
> > > >
> > > > I've posted the patch to drop the SH boards. Daniel, what about
> > > > Malta?
> > >
> > > Malta should be fixed, since it's mips used in CI.
> >
> > There's also qemu_mips* in CI, so it depends on what Daniel thinks is
> > the right overall answer here.
> >
>
> Malta is the MIPS reference board physically as well as in Qemu.
> qemu_mips is actually deprecated and is going to be removed from Qemu
> sooner or later. That's why I added Malta to CI with the goal to remove
> qemu_mips.
>
> The problem with MIPS and DM_PCI is that there are some generic issues
> with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual
> address. Actually I have a pending patch queue from Paul Burton for
> Malta for converting to DM_PCI, but that requires resolving the generic
> issues with some refactoring for all MIPS boards. It's still on my TODO
> list ;)
>
> Until I can spare enough time to resolve all issues, I could try to
> disable the PCI driver in Malta defconfig and mark the driver as broken
> in Kconfig. This way we can avoid removing the whole board.
Thanks for explaining. Yes, lets go that route for now.
--
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/20210214/4a36d686/attachment.sig>
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 01/26] Revert "pci: pci-uclass: Dynamically allocate the PCI regions"
2021-02-14 20:30 ` Tom Rini
@ 2021-02-18 0:32 ` Bin Meng
0 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-18 0:32 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Mon, Feb 15, 2021 at 4:30 AM Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Feb 14, 2021 at 08:12:16PM +0100, Daniel Schwierzeck wrote:
> > Am Sonntag, den 14.02.2021, 09:52 -0500 schrieb Tom Rini:
> >
> > ...
> >
> > > > > > > >
> > > > > > > > > Tom, do you know the situation here?
> > > > > > >
> > > > > > > So, I made a lack of DM_PCI migration be fatal and got a
> > > > > > > build done
> > > > > > > here:
> > > > > > > https://gitlab.denx.de/u-boot/u-boot/-/pipelines/6348
> > > > > > >
> > > > > > > Of note, MIPS malta fails, so I had to drop that from pytest
> > > > > > > to complete
> > > > > > > the world build. There's then a handful of ARM boards,
> > > > > > > another large
> > > > > > > chunk of PowerPC, and then a few others such as r7780mp. SH
> > > > > > > is the big
> > > > > > > what to do here to me, other than PowerPC, as other than
> > > > > > > r2dplus
> > > > > > > everything is missing the main "convert to DM" migration
> > > > > > > deadline as
> > > > > > > well.
> > > > > >
> > > > > > What should we do for this patch?
> > > > > >
> > > > > > If the plan is to drop all boards that are not converted to DM
> > > > > > PCI in
> > > > > > 2021.04, I can drop this revert patch in v2.
> > > > >
> > > > > I've posted the patch to drop the SH boards. Daniel, what about
> > > > > Malta?
> > > >
> > > > Malta should be fixed, since it's mips used in CI.
> > >
> > > There's also qemu_mips* in CI, so it depends on what Daniel thinks is
> > > the right overall answer here.
> > >
> >
> > Malta is the MIPS reference board physically as well as in Qemu.
> > qemu_mips is actually deprecated and is going to be removed from Qemu
> > sooner or later. That's why I added Malta to CI with the goal to remove
> > qemu_mips.
> >
> > The problem with MIPS and DM_PCI is that there are some generic issues
> > with memory mapping and CONFIG_SYS_SDRAM_BASE being used as virtual
> > address. Actually I have a pending patch queue from Paul Burton for
> > Malta for converting to DM_PCI, but that requires resolving the generic
> > issues with some refactoring for all MIPS boards. It's still on my TODO
> > list ;)
> >
> > Until I can spare enough time to resolve all issues, I could try to
> > disable the PCI driver in Malta defconfig and mark the driver as broken
> > in Kconfig. This way we can avoid removing the whole board.
>
> Thanks for explaining. Yes, lets go that route for now.
To make this series not to depend on board removal series, I will drop
this revert patch in v2, and fix the non-DM PCI driver of mpc85xx
instead.
Regards,
Bin
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 02/26] ppc: qemu: Update MAINTAINERS for correct email address
2021-02-07 15:11 ` Bin Meng
(?)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 UTC (permalink / raw)
To: u-boot
Alex's previous email address is no longer reachable.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
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] 63+ messages in thread
* [PATCH 03/26] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-07 15:11 ` Bin Meng
` (2 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:21 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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.
This adds the special handling of such case.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
common/fdt_support.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 638eca9..b3aa865 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1602,22 +1602,31 @@ 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> */
+ 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] 63+ messages in thread* [PATCH 03/26] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-07 15:11 ` [PATCH 03/26] common: fdt_support: Support special case of PCI address in fdt_read_prop() Bin Meng
@ 2021-02-08 4:21 ` Simon Glass
2021-02-08 5:17 ` Bin Meng
0 siblings, 1 reply; 63+ messages in thread
From: Simon Glass @ 2021-02-08 4:21 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Sun, 7 Feb 2021 at 08:11, 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.
>
> This adds the special handling of such case.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
> common/fdt_support.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
I think this is missing why it is needed. Also needs an update to
function to the comment in the header file.
Regards,
Simon
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 03/26] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-08 4:21 ` Simon Glass
@ 2021-02-08 5:17 ` Bin Meng
2021-02-08 14:08 ` Simon Glass
0 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-08 5:17 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Feb 8, 2021 at 12:21 PM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Bin,
>
> On Sun, 7 Feb 2021 at 08:11, 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.
> >
> > This adds the special handling of such case.
> >
> > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > ---
> >
> > common/fdt_support.c | 15 ++++++++++++---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
>
> I think this is missing why it is needed. Also needs an update to
> function to the comment in the header file.
>
I will try to add more details in v2.
The reason why this is needed is because in fdt_read_range() may be
used to read PCI address from <ranges>.
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.
Regards,
Bin
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 03/26] common: fdt_support: Support special case of PCI address in fdt_read_prop()
2021-02-08 5:17 ` Bin Meng
@ 2021-02-08 14:08 ` Simon Glass
0 siblings, 0 replies; 63+ messages in thread
From: Simon Glass @ 2021-02-08 14:08 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Sun, 7 Feb 2021 at 22:17, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Mon, Feb 8, 2021 at 12:21 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, 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.
> > >
> > > This adds the special handling of such case.
> > >
> > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> > > ---
> > >
> > > common/fdt_support.c | 15 ++++++++++++---
> > > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > I think this is missing why it is needed. Also needs an update to
> > function to the comment in the header file.
> >
>
> I will try to add more details in v2.
>
> The reason why this is needed is because in fdt_read_range() may be
> used to read PCI address from <ranges>.
> 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.
OK, that could go in the commit message and a function comment
somewhere about the case.
There is similar code in decode_regions(), so we have two places that
read ranges.
Regards,
Simon
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 04/26] ppc: qemu: Support non-identity PCI bus address
2021-02-07 15:11 ` Bin Meng
` (3 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 3395377..f82501c 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -84,20 +84,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;
@@ -114,7 +118,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)
@@ -165,24 +169,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] 63+ messages in thread* [PATCH 05/26] ppc: qemu: Fix CONFIG_SYS_PCI_MAP_END
2021-02-07 15:11 ` Bin Meng
` (4 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 06/26] ppc: mpc85xx: Wrap LAW related codes with CONFIG_FSL_LAW
2021-02-07 15:11 ` Bin Meng
` (5 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 3ff1ef4..9d3a68e 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -394,7 +394,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 c519e8b..b0c2e2a 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init_early.c
@@ -122,7 +122,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] 63+ messages in thread* [PATCH 07/26] ppc: qemu: Drop init_laws() and print_laws()
2021-02-07 15:11 ` Bin Meng
` (6 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 UTC (permalink / raw)
To: u-boot
These are no longer needed. Drop them.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
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 f82501c..fb0b01f 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -253,11 +253,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();
@@ -301,11 +296,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] 63+ messages in thread* [PATCH 08/26] ppc: qemu: Drop board_early_init_f()
2021-02-07 15:11 ` Bin Meng
` (7 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 UTC (permalink / raw)
To: u-boot
This function does nothing. Drop it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
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 fb0b01f..33d71ba 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -73,11 +73,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] 63+ messages in thread* [PATCH 09/26] ppc: qemu: Enable OF_CONTROL
2021-02-07 15:11 ` Bin Meng
` (8 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 33d71ba..83cff2d 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -363,3 +363,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] 63+ messages in thread* [PATCH 09/26] ppc: qemu: Enable OF_CONTROL
2021-02-07 15:11 ` [PATCH 09/26] ppc: qemu: Enable OF_CONTROL Bin Meng
@ 2021-02-08 4:20 ` Simon Glass
0 siblings, 0 replies; 63+ messages in thread
From: Simon Glass @ 2021-02-08 4:20 UTC (permalink / raw)
To: u-boot
On Sun, 7 Feb 2021 at 08:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> 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>
> ---
>
> board/freescale/qemu-ppce500/qemu-ppce500.c | 10 ++++++++++
> configs/qemu-ppce500_defconfig | 3 ++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 10/26] ppc: qemu: Enable driver model
2021-02-07 15:11 ` Bin Meng
` (9 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 11/26] include: Remove extern from addr_map.h
2021-02-07 15:11 ` Bin Meng
` (10 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 12/26] lib: addr_map: Move address_map[] type to the header file
2021-02-07 15:11 ` Bin Meng
` (11 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:21 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 13/26] cmd: Add a command to display the address map
2021-02-07 15:11 ` Bin Meng
` (12 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
cmd/Kconfig | 7 +++++++
cmd/Makefile | 1 +
cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 43 insertions(+)
create mode 100644 cmd/addrmap.c
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",
+ ""
+);
--
2.7.4
^ permalink raw reply related [flat|nested] 63+ messages in thread* [PATCH 13/26] cmd: Add a command to display the address map
2021-02-07 15:11 ` [PATCH 13/26] cmd: Add a command to display the address map Bin Meng
@ 2021-02-08 4:20 ` Simon Glass
2021-02-08 5:12 ` Bin Meng
0 siblings, 1 reply; 63+ messages in thread
From: Simon Glass @ 2021-02-08 4:20 UTC (permalink / raw)
To: u-boot
On Sun, 7 Feb 2021 at 08:12, 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>
> ---
>
> cmd/Kconfig | 7 +++++++
> cmd/Makefile | 1 +
> cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++
> 3 files changed, 43 insertions(+)
> create mode 100644 cmd/addrmap.c
This should have a test (e.g. see mem_search.c) and doc/usage file.
Regards,
Simon
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 13/26] cmd: Add a command to display the address map
2021-02-08 4:20 ` Simon Glass
@ 2021-02-08 5:12 ` Bin Meng
2021-02-08 14:13 ` Simon Glass
0 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-08 5:12 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Mon, Feb 8, 2021 at 12:20 PM Simon Glass <sjg@chromium.org> wrote:
>
> On Sun, 7 Feb 2021 at 08:12, 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>
> > ---
> >
> > cmd/Kconfig | 7 +++++++
> > cmd/Makefile | 1 +
> > cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++
> > 3 files changed, 43 insertions(+)
> > create mode 100644 cmd/addrmap.c
>
> This should have a test (e.g. see mem_search.c) and doc/usage file.
I am not sure how that is useful to add a test for this command,
because this command only prints some value from an array.
Regards,
Bin
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 13/26] cmd: Add a command to display the address map
2021-02-08 5:12 ` Bin Meng
@ 2021-02-08 14:13 ` Simon Glass
0 siblings, 0 replies; 63+ messages in thread
From: Simon Glass @ 2021-02-08 14:13 UTC (permalink / raw)
To: u-boot
Hi Bin,
On Sun, 7 Feb 2021 at 22:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Simon,
>
> On Mon, Feb 8, 2021 at 12:20 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > On Sun, 7 Feb 2021 at 08:12, 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>
> > > ---
> > >
> > > cmd/Kconfig | 7 +++++++
> > > cmd/Makefile | 1 +
> > > cmd/addrmap.c | 35 +++++++++++++++++++++++++++++++++++
> > > 3 files changed, 43 insertions(+)
> > > create mode 100644 cmd/addrmap.c
> >
> > This should have a test (e.g. see mem_search.c) and doc/usage file.
>
> I am not sure how that is useful to add a test for this command,
> because this command only prints some value from an array.
Right but then it will only be a short test:
console_record_reset();
ut_assertok(run_command("...", 0));
ut_assert_nextline()
..
ut_assert_console_end();
Then if someone expands it later they will feel obligated to add to the test.
I feel that a lot of things look too trivial to test when started, but
it is often that first trivial test that determines whether we have
tests ever. That is why we have the patman check about adding tests
for new commands.
Regards,
Simon
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 14/26] lib: kconfig: Mention CONFIG_ADDR_MAP limitation in the help
2021-02-07 15:11 ` Bin Meng
` (13 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:21 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 15/26] ppc: io.h: Use addrmap_ translation APIs only in post-relocation phase
2021-02-07 15:11 ` Bin Meng
` (14 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 16/26] common: Move initr_addr_map() to a bit earlier
2021-02-07 15:11 ` Bin Meng
` (15 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:21 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 9fa4d4b..cce0336 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -625,6 +625,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 */
@@ -660,9 +663,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] 63+ messages in thread* [PATCH 16/26] common: Move initr_addr_map() to a bit earlier
2021-02-07 15:11 ` [PATCH 16/26] common: Move initr_addr_map() to a bit earlier Bin Meng
@ 2021-02-08 4:21 ` Simon Glass
0 siblings, 0 replies; 63+ messages in thread
From: Simon Glass @ 2021-02-08 4:21 UTC (permalink / raw)
To: u-boot
On Sun, 7 Feb 2021 at 08:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> 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>
> ---
>
> common/board_r.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 17/26] ppc: qemu: Switch over to use DM serial
2021-02-07 15:11 ` Bin Meng
` (16 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 83cff2d..48588e8 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -373,3 +373,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] 63+ messages in thread* [PATCH 17/26] ppc: qemu: Switch over to use DM serial
2021-02-07 15:11 ` [PATCH 17/26] ppc: qemu: Switch over to use DM serial Bin Meng
@ 2021-02-08 4:20 ` Simon Glass
0 siblings, 0 replies; 63+ messages in thread
From: Simon Glass @ 2021-02-08 4:20 UTC (permalink / raw)
To: u-boot
On Sun, 7 Feb 2021 at 08:12, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> 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>
> ---
>
> 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: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 18/26] pci: mpc85xx: Wrap LAW programming with CONFIG_FSL_LAW
2021-02-07 15:11 ` Bin Meng
` (17 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 19/26] pci: mpc85xx: Support controller register physical address beyond 32-bit
2021-02-07 15:11 ` Bin Meng
` (18 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 20/26] pci: mpc85xx: Support 64-bit bus and cpu address
2021-02-07 15:11 ` Bin Meng
` (19 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 21/26] ppc: qemu: Switch over to use DM ETH and PCI
2021-02-07 15:11 ` Bin Meng
` (20 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 48588e8..88cada1 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>
@@ -78,27 +79,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;
@@ -116,82 +99,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)
@@ -234,16 +172,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] 63+ messages in thread* [PATCH 22/26] ppc: qemu: Drop CONFIG_OF_BOARD_SETUP
2021-02-07 15:11 ` Bin Meng
` (21 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 UTC (permalink / raw)
To: u-boot
ft_board_setup() is now empty. Drop it.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---
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 88cada1..b85316b 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -172,13 +172,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] 63+ messages in thread* [PATCH 23/26] cmd: Fix virtio command dependency
2021-02-07 15:11 ` Bin Meng
` (22 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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] 63+ messages in thread* [PATCH 24/26] ppc: qemu: Enable VirtIO NET support
2021-02-07 15:11 ` Bin Meng
` (23 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 b85316b..a105130 100644
--- a/board/freescale/qemu-ppce500/qemu-ppce500.c
+++ b/board/freescale/qemu-ppce500/qemu-ppce500.c
@@ -23,6 +23,8 @@
#include <fdtdec.h>
#include <errno.h>
#include <malloc.h>
+#include <virtio_types.h>
+#include <virtio.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -129,6 +131,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] 63+ messages in thread* [PATCH 25/26] ppc: qemu: Move board directory from board/freescale to board/emulation
2021-02-07 15:11 ` Bin Meng
` (24 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
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 54c7fd9..d40ea85 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -1437,6 +1437,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/mpc8544ds/Kconfig"
@@ -1448,7 +1449,6 @@ source "board/freescale/mpc8572ds/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 a105130..4955563 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] 63+ messages in thread* [PATCH 26/26] doc: Add a reST document for qemu-ppce500
2021-02-07 15:11 ` Bin Meng
` (25 preceding siblings ...)
(?)
@ 2021-02-07 15:11 ` Bin Meng
2021-02-08 4:20 ` Simon Glass
-1 siblings, 1 reply; 63+ messages in thread
From: Bin Meng @ 2021-02-07 15:11 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>
---
doc/board/emulation/index.rst | 1 +
doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++++++++++++++++++++++++++++
2 files changed, 74 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..7472867
--- /dev/null
+++ b/doc/board/emulation/qemu-ppce500.rst
@@ -0,0 +1,73 @@
+.. 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
+
+These have been tested in QEMU 5.2.0.
--
2.7.4
^ permalink raw reply related [flat|nested] 63+ messages in thread* [PATCH 26/26] doc: Add a reST document for qemu-ppce500
2021-02-07 15:11 ` [PATCH 26/26] doc: Add a reST document for qemu-ppce500 Bin Meng
@ 2021-02-08 4:20 ` Simon Glass
0 siblings, 0 replies; 63+ messages in thread
From: Simon Glass @ 2021-02-08 4:20 UTC (permalink / raw)
To: u-boot
On Sun, 7 Feb 2021 at 08:13, Bin Meng <bmeng.cn@gmail.com> wrote:
>
> 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>
>
> ---
>
> doc/board/emulation/index.rst | 1 +
> doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 74 insertions(+)
> create mode 100644 doc/board/emulation/qemu-ppce500.rst
Reviewed-by: Simon Glass <sjg@chromium.org>
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 00/26] ppc: qemu: Convert qemu-ppce500 to driver model
2021-02-07 15:11 ` Bin Meng
@ 2021-02-10 0:36 ` Bin Meng
-1 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-10 0:36 UTC (permalink / raw)
To: Simon Glass, Alexander Graf, Priyanka Jain
Cc: Tom Rini, Heiko Schocher, qemu-devel@nongnu.org Developers,
U-Boot Mailing List, Matthias Brugger, qemu-ppc, Stefan Roese,
Marek Szyprowski
On Sun, Feb 7, 2021 at 11:11 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 reverts this commit as it broken all boards that have not converted
> to driver model PCI.
> - 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 are minor fixes and clean-ups.
>
> Starting from patch#9, these are driver model conversion patches.
>
> Patch #11-16 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 #18-20 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.
>
> Patch #23 is minor fix to the 'virtio' command dependency.
>
> Patch #24 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 #25 moves the qemu-ppce500 boards codes to board/emulation as that is the
> place for other QEMU targets like x86, arm, riscv.
>
> Patch #26 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.
>
>
> Bin Meng (26):
> Revert "pci: pci-uclass: 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
> 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
> 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/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 | 159 ++++++---------------
> 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 | 15 +-
> configs/qemu-ppce500_defconfig | 14 +-
> doc/board/emulation/index.rst | 1 +
> doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++
> drivers/pci/pci-uclass.c | 14 +-
> drivers/pci/pci_mpc85xx.c | 25 ++--
> include/addr_map.h | 16 ++-
> include/configs/qemu-ppce500.h | 25 +---
> include/pci.h | 4 +-
> lib/Kconfig | 2 +
> lib/addr_map.c | 6 +-
> 24 files changed, 250 insertions(+), 190 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 (68%)
> delete mode 100644 board/freescale/qemu-ppce500/MAINTAINERS
> create mode 100644 cmd/addrmap.c
> create mode 100644 doc/board/emulation/qemu-ppce500.rst
>
Alex, Priyanka, do you have some time to review this series?
Regards,
Bin
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 00/26] ppc: qemu: Convert qemu-ppce500 to driver model
@ 2021-02-10 0:36 ` Bin Meng
0 siblings, 0 replies; 63+ messages in thread
From: Bin Meng @ 2021-02-10 0:36 UTC (permalink / raw)
To: u-boot
On Sun, Feb 7, 2021 at 11:11 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 reverts this commit as it broken all boards that have not converted
> to driver model PCI.
> - 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 are minor fixes and clean-ups.
>
> Starting from patch#9, these are driver model conversion patches.
>
> Patch #11-16 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 #18-20 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.
>
> Patch #23 is minor fix to the 'virtio' command dependency.
>
> Patch #24 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 #25 moves the qemu-ppce500 boards codes to board/emulation as that is the
> place for other QEMU targets like x86, arm, riscv.
>
> Patch #26 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.
>
>
> Bin Meng (26):
> Revert "pci: pci-uclass: 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
> 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
> 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/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 | 159 ++++++---------------
> 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 | 15 +-
> configs/qemu-ppce500_defconfig | 14 +-
> doc/board/emulation/index.rst | 1 +
> doc/board/emulation/qemu-ppce500.rst | 73 ++++++++++
> drivers/pci/pci-uclass.c | 14 +-
> drivers/pci/pci_mpc85xx.c | 25 ++--
> include/addr_map.h | 16 ++-
> include/configs/qemu-ppce500.h | 25 +---
> include/pci.h | 4 +-
> lib/Kconfig | 2 +
> lib/addr_map.c | 6 +-
> 24 files changed, 250 insertions(+), 190 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 (68%)
> delete mode 100644 board/freescale/qemu-ppce500/MAINTAINERS
> create mode 100644 cmd/addrmap.c
> create mode 100644 doc/board/emulation/qemu-ppce500.rst
>
Alex, Priyanka, do you have some time to review this series?
Regards,
Bin
^ permalink raw reply [flat|nested] 63+ messages in thread