| Message ID | 20180807080859.3817451-1-amitay@ozlabs.org |
|---|---|
| State | Accepted |
| Headers | show |
| Series | main: Add P8 kernel devicetree | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | master/apply_patch Successfully applied |
| snowpatch_ozlabs/build-multiarch | success | Test build-multiarch on branch master |
Joel do you know if there is someway to differentiate between P8 and P9 on OpenBMC? This patch makes it mandatory to specify p8 vs. p9 on the command line which feels like a step backwards. If we can't do it from the BMC then we will have to probe it from the host. - Alistair On Tuesday, 7 August 2018 6:08:59 PM AEST Amitay Isaacs wrote: > From: Benjamin Herrenschmidt <benh@kernel.crashing.org> > > This makes palmettos use kernel backend on bmc using coldfire driver. > > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> > Signed-off-by: Amitay Isaacs <amitay@ozlabs.org> > --- > Makefile.am | 3 ++- > p8-kernel.dts.m4 | 45 +++++++++++++++++++++++++++++++++++++++++++++ > src/main.c | 10 +++++++++- > 3 files changed, 56 insertions(+), 2 deletions(-) > create mode 100644 p8-kernel.dts.m4 > > diff --git a/Makefile.am b/Makefile.am > index e2783f1..2e3d67e 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -14,6 +14,7 @@ EXTRA_DIST = \ > p8-fsi.dts.m4 \ > p8-host.dts.m4 \ > p8-i2c.dts.m4 \ > + p8-kernel.dts.m4 \ > p8-pib.dts.m4 \ > p9-fsi.dtsi.m4 \ > p9-host.dts.m4 \ > @@ -26,7 +27,7 @@ EXTRA_DIST = \ > generate_dt_header.sh > > if TARGET_ARM > -DT_ARM = p8-fsi.dts p8-i2c.dts \ > +DT_ARM = p8-fsi.dts p8-i2c.dts p8-kernel.dts \ > p9w-fsi.dts p9r-fsi.dts p9z-fsi.dts p9-kernel.dts > ARCH_FLAGS="-DTARGET_ARM=1" > endif > diff --git a/p8-kernel.dts.m4 b/p8-kernel.dts.m4 > new file mode 100644 > index 0000000..4a59b78 > --- /dev/null > +++ b/p8-kernel.dts.m4 > @@ -0,0 +1,45 @@ > +/dts-v1/; > + > +/ { > + #address-cells = <0x1>; > + #size-cells = <0x0>; > + > + fsi0: kernelfsi@0 { > + #address-cells = <0x2>; > + #size-cells = <0x1>; > + compatible = "ibm,kernel-fsi"; > + reg = <0x0 0x0 0x0>; > + > + index = <0x0>; > + status = "mustexist"; > + > + pib@1000 { > + #address-cells = <0x2>; > + #size-cells = <0x1>; > + reg = <0x0 0x1000 0x7>; > + index = <0x0>; > + compatible = "ibm,fsi-pib", "ibm,power8-fsi-pib"; > + include(p8-pib.dts.m4)dnl > + }; > + > + hmfsi@100000 { > + #address-cells = <0x2>; > + #size-cells = <0x1>; > + compatible = "ibm,fsi-hmfsi"; > + reg = <0x0 0x100000 0x8000>; > + port = <0x1>; > + index = <0x1>; > + > + pib@1000 { > + #address-cells = <0x2>; > + #size-cells = <0x1>; > + reg = <0x0 0x1000 0x7>; > + compatible = "ibm,fsi-pib", "ibm,power8-fsi-pib"; > + index = <0x1>; > + include(p8-pib.dts.m4)dnl > + }; > + > + }; > + }; > +}; > + > diff --git a/src/main.c b/src/main.c > index fcdab67..2330007 100644 > --- a/src/main.c > +++ b/src/main.c > @@ -46,6 +46,7 @@ > #ifdef TARGET_ARM > #include "p8-i2c.dt.h" > #include "p8-fsi.dt.h" > +#include "p8-kernel.dt.h" > #include "p9w-fsi.dt.h" > #include "p9r-fsi.dt.h" > #include "p9z-fsi.dt.h" > @@ -619,7 +620,14 @@ static int target_selection(void) > break; > > case KERNEL: > - pdbg_targets_init(&_binary_p9_kernel_dtb_o_start); > + if (device_node == NULL) { > + PR_ERROR("kernel backend requires a device type\n"); > + return -1; > + } > + if (!strcmp(device_node, "p8")) > + pdbg_targets_init(&_binary_p8_kernel_dtb_o_start); > + else > + pdbg_targets_init(&_binary_p9_kernel_dtb_o_start); > break; > > #endif >
On Mon, 13 Aug 2018 at 14:48, Alistair Popple <alistair@popple.id.au> wrote: > > Joel do you know if there is someway to differentiate between P8 and P9 on > OpenBMC? This patch makes it mandatory to specify p8 vs. p9 on the command line > which feels like a step backwards. If we can't do it from the BMC then we will > have to probe it from the host. I spent more time than I'd like to admit looking at this last week. We could assume that ast2400 == p8, as it is true for all the machines that exist to date. I looked into geteauxval etc, but it appears there's no way to detect you're on an ast2400 (or even just an ARM9) without parsing files. So the 'best' we have would be to open up the device tree at /sys/firmware, or parse /proc/cpuinfo. The device tree would be neater. Cheers, Joel
On Monday, 13 August 2018 4:13:56 PM AEST Joel Stanley wrote: > On Mon, 13 Aug 2018 at 14:48, Alistair Popple <alistair@popple.id.au> wrote: > > > > Joel do you know if there is someway to differentiate between P8 and P9 on > > OpenBMC? This patch makes it mandatory to specify p8 vs. p9 on the command line > > which feels like a step backwards. If we can't do it from the BMC then we will > > have to probe it from the host. > > I spent more time than I'd like to admit looking at this last week. Thanks! > We could assume that ast2400 == p8, as it is true for all the machines > that exist to date. > > I looked into geteauxval etc, but it appears there's no way to detect > you're on an ast2400 (or even just an ARM9) without parsing files. So > the 'best' we have would be to open up the device tree at > /sys/firmware, or parse /proc/cpuinfo. > > The device tree would be neater. Ok. I guess we already have stuff to read the device-tree for the FSI bit-banging backend so we could use that. But it would be better to just probe the host CFAM and read it from there. Means the host has to be powered on, but if it isn't pdbg won't be able to do much anyway. - Alistair > Cheers, > > Joel >
On Mon, 13 Aug 2018 at 16:26, Alistair Popple <alistair@popple.id.au> wrote: > > On Monday, 13 August 2018 4:13:56 PM AEST Joel Stanley wrote: > > On Mon, 13 Aug 2018 at 14:48, Alistair Popple <alistair@popple.id.au> wrote: > > > > > > Joel do you know if there is someway to differentiate between P8 and P9 on > > > OpenBMC? This patch makes it mandatory to specify p8 vs. p9 on the command line > > > which feels like a step backwards. If we can't do it from the BMC then we will > > > have to probe it from the host. > > > > I spent more time than I'd like to admit looking at this last week. > > Thanks! > > > We could assume that ast2400 == p8, as it is true for all the machines > > that exist to date. > > > > I looked into geteauxval etc, but it appears there's no way to detect > > you're on an ast2400 (or even just an ARM9) without parsing files. So > > the 'best' we have would be to open up the device tree at > > /sys/firmware, or parse /proc/cpuinfo. > > > > The device tree would be neater. > > Ok. I guess we already have stuff to read the device-tree for the FSI > bit-banging backend so we could use that. But it would be better to just probe > the host CFAM and read it from there. Means the host has to be powered on, but > if it isn't pdbg won't be able to do much anyway. Sounds good to me. Poking around in sysfs was going to be fragile. Cheers, Joel
On Mon, 2018-08-13 at 16:13 +0930, Joel Stanley wrote: > On Mon, 13 Aug 2018 at 14:48, Alistair Popple <alistair@popple.id.au> wrote: > > > > Joel do you know if there is someway to differentiate between P8 and P9 on > > OpenBMC? This patch makes it mandatory to specify p8 vs. p9 on the command line > > which feels like a step backwards. If we can't do it from the BMC then we will > > have to probe it from the host. > > I spent more time than I'd like to admit looking at this last week. > > We could assume that ast2400 == p8, as it is true for all the machines > that exist to date. > > I looked into geteauxval etc, but it appears there's no way to detect > you're on an ast2400 (or even just an ARM9) without parsing files. So > the 'best' we have would be to open up the device tree at > /sys/firmware, or parse /proc/cpuinfo. > > The device tree would be neater. What about CFAM ID ? Ben.
On Monday, 13 August 2018 9:12:39 PM AEST Benjamin Herrenschmidt wrote: > On Mon, 2018-08-13 at 16:13 +0930, Joel Stanley wrote: > > On Mon, 13 Aug 2018 at 14:48, Alistair Popple <alistair@popple.id.au> wrote: > > > > > > Joel do you know if there is someway to differentiate between P8 and P9 on > > > OpenBMC? This patch makes it mandatory to specify p8 vs. p9 on the command line > > > which feels like a step backwards. If we can't do it from the BMC then we will > > > have to probe it from the host. > > > > I spent more time than I'd like to admit looking at this last week. > > > > We could assume that ast2400 == p8, as it is true for all the machines > > that exist to date. > > > > I looked into geteauxval etc, but it appears there's no way to detect > > you're on an ast2400 (or even just an ARM9) without parsing files. So > > the 'best' we have would be to open up the device tree at > > /sys/firmware, or parse /proc/cpuinfo. > > > > The device tree would be neater. > > What about CFAM ID ? Yep. That is what I meant when I mentioned we could "probe the host". Obviously depends on the host being powered on, but that is not really an issue as you're not going to be debugging much if the host isn't powered on. - Alistair > Ben. > > >
diff --git a/Makefile.am b/Makefile.am index e2783f1..2e3d67e 100644 --- a/Makefile.am +++ b/Makefile.am @@ -14,6 +14,7 @@ EXTRA_DIST = \ p8-fsi.dts.m4 \ p8-host.dts.m4 \ p8-i2c.dts.m4 \ + p8-kernel.dts.m4 \ p8-pib.dts.m4 \ p9-fsi.dtsi.m4 \ p9-host.dts.m4 \ @@ -26,7 +27,7 @@ EXTRA_DIST = \ generate_dt_header.sh if TARGET_ARM -DT_ARM = p8-fsi.dts p8-i2c.dts \ +DT_ARM = p8-fsi.dts p8-i2c.dts p8-kernel.dts \ p9w-fsi.dts p9r-fsi.dts p9z-fsi.dts p9-kernel.dts ARCH_FLAGS="-DTARGET_ARM=1" endif diff --git a/p8-kernel.dts.m4 b/p8-kernel.dts.m4 new file mode 100644 index 0000000..4a59b78 --- /dev/null +++ b/p8-kernel.dts.m4 @@ -0,0 +1,45 @@ +/dts-v1/; + +/ { + #address-cells = <0x1>; + #size-cells = <0x0>; + + fsi0: kernelfsi@0 { + #address-cells = <0x2>; + #size-cells = <0x1>; + compatible = "ibm,kernel-fsi"; + reg = <0x0 0x0 0x0>; + + index = <0x0>; + status = "mustexist"; + + pib@1000 { + #address-cells = <0x2>; + #size-cells = <0x1>; + reg = <0x0 0x1000 0x7>; + index = <0x0>; + compatible = "ibm,fsi-pib", "ibm,power8-fsi-pib"; + include(p8-pib.dts.m4)dnl + }; + + hmfsi@100000 { + #address-cells = <0x2>; + #size-cells = <0x1>; + compatible = "ibm,fsi-hmfsi"; + reg = <0x0 0x100000 0x8000>; + port = <0x1>; + index = <0x1>; + + pib@1000 { + #address-cells = <0x2>; + #size-cells = <0x1>; + reg = <0x0 0x1000 0x7>; + compatible = "ibm,fsi-pib", "ibm,power8-fsi-pib"; + index = <0x1>; + include(p8-pib.dts.m4)dnl + }; + + }; + }; +}; + diff --git a/src/main.c b/src/main.c index fcdab67..2330007 100644 --- a/src/main.c +++ b/src/main.c @@ -46,6 +46,7 @@ #ifdef TARGET_ARM #include "p8-i2c.dt.h" #include "p8-fsi.dt.h" +#include "p8-kernel.dt.h" #include "p9w-fsi.dt.h" #include "p9r-fsi.dt.h" #include "p9z-fsi.dt.h" @@ -619,7 +620,14 @@ static int target_selection(void) break; case KERNEL: - pdbg_targets_init(&_binary_p9_kernel_dtb_o_start); + if (device_node == NULL) { + PR_ERROR("kernel backend requires a device type\n"); + return -1; + } + if (!strcmp(device_node, "p8")) + pdbg_targets_init(&_binary_p8_kernel_dtb_o_start); + else + pdbg_targets_init(&_binary_p9_kernel_dtb_o_start); break; #endif