| Message ID | 1437982423-28391-3-git-send-email-bmeng.cn@gmail.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Simon Glass |
| Headers | show |
Hi Bin, On 27 July 2015 at 01:33, Bin Meng <bmeng.cn@gmail.com> wrote: > Increase CONFIG_MALLOC_F_LEN so that dm pci does not fail with -ENOMEM > before relocation. This makes pci uart work again on Intel Crown Bay. > > Signed-off-by: Bin Meng <bmeng.cn@gmail.com> > --- > > arch/x86/cpu/queensbay/Kconfig | 3 +++ > arch/x86/cpu/queensbay/tnc.c | 13 +++++++++++++ > arch/x86/dts/crownbay.dts | 2 -- > 3 files changed, 16 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig > index fbf85f2..8eb619c 100644 > --- a/arch/x86/cpu/queensbay/Kconfig > +++ b/arch/x86/cpu/queensbay/Kconfig > @@ -42,4 +42,7 @@ config CPU_ADDR_BITS > int > default 32 > > +config SYS_MALLOC_F_LEN > + default 0x8000 32KB? Wow that's a huge amount. How much does it actually use? Perhaps we should change PCI so that it respects the u-boot,dm-pre-reloc property? > + > endif > diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c > index de50893..322534b 100644 > --- a/arch/x86/cpu/queensbay/tnc.c > +++ b/arch/x86/cpu/queensbay/tnc.c > @@ -13,6 +13,7 @@ > #include <asm/arch/tnc.h> > #include <asm/fsp/fsp_support.h> > #include <asm/processor.h> > +#include <dm.h> > > static void unprotect_spi_flash(void) > { > @@ -36,6 +37,18 @@ int arch_cpu_init(void) > if (ret) > return ret; > > + return 0; > +} > + > +int arch_cpu_init_dm(void) > +{ > + struct udevice *dev; > + int ret; > + > + ret = uclass_first_device(UCLASS_PCI, &dev); > + if (ret) > + return ret; > + > unprotect_spi_flash(); > > return 0; > diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts > index 3af9cc3..2714370 100644 > --- a/arch/x86/dts/crownbay.dts > +++ b/arch/x86/dts/crownbay.dts > @@ -100,13 +100,11 @@ > pcie@17,0 { > #address-cells = <3>; > #size-cells = <2>; > - compatible = "intel,pci"; > device_type = "pci"; > > topcliff@0,0 { > #address-cells = <3>; > #size-cells = <2>; > - compatible = "intel,pci"; > device_type = "pci"; > > pciuart0: uart@a,1 { > -- > 1.8.2.1 > Regards, Simon
Hi Simon, On Mon, Aug 3, 2015 at 6:31 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 27 July 2015 at 01:33, Bin Meng <bmeng.cn@gmail.com> wrote: >> Increase CONFIG_MALLOC_F_LEN so that dm pci does not fail with -ENOMEM >> before relocation. This makes pci uart work again on Intel Crown Bay. >> >> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >> --- >> >> arch/x86/cpu/queensbay/Kconfig | 3 +++ >> arch/x86/cpu/queensbay/tnc.c | 13 +++++++++++++ >> arch/x86/dts/crownbay.dts | 2 -- >> 3 files changed, 16 insertions(+), 2 deletions(-) >> >> diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig >> index fbf85f2..8eb619c 100644 >> --- a/arch/x86/cpu/queensbay/Kconfig >> +++ b/arch/x86/cpu/queensbay/Kconfig >> @@ -42,4 +42,7 @@ config CPU_ADDR_BITS >> int >> default 32 >> >> +config SYS_MALLOC_F_LEN >> + default 0x8000 > > 32KB? Wow that's a huge amount. How much does it actually use? Perhaps > we should change PCI so that it respects the u-boot,dm-pre-reloc > property? > I just add a zero to the original value :) I did not measure the actual memory consumption since after fsp_init() we have plenty of memory to be used as the stack. For queensbay platform, it has lots of pci devices each of which will need allocate some memory for dm pci to use. Regards, Bin
Hi Bin, On 2 August 2015 at 19:52, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Mon, Aug 3, 2015 at 6:31 AM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 27 July 2015 at 01:33, Bin Meng <bmeng.cn@gmail.com> wrote: >>> Increase CONFIG_MALLOC_F_LEN so that dm pci does not fail with -ENOMEM >>> before relocation. This makes pci uart work again on Intel Crown Bay. >>> >>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >>> --- >>> >>> arch/x86/cpu/queensbay/Kconfig | 3 +++ >>> arch/x86/cpu/queensbay/tnc.c | 13 +++++++++++++ >>> arch/x86/dts/crownbay.dts | 2 -- >>> 3 files changed, 16 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig >>> index fbf85f2..8eb619c 100644 >>> --- a/arch/x86/cpu/queensbay/Kconfig >>> +++ b/arch/x86/cpu/queensbay/Kconfig >>> @@ -42,4 +42,7 @@ config CPU_ADDR_BITS >>> int >>> default 32 >>> >>> +config SYS_MALLOC_F_LEN >>> + default 0x8000 >> >> 32KB? Wow that's a huge amount. How much does it actually use? Perhaps >> we should change PCI so that it respects the u-boot,dm-pre-reloc >> property? >> > > I just add a zero to the original value :) I did not measure the > actual memory consumption since after fsp_init() we have plenty of > memory to be used as the stack. For queensbay platform, it has lots of > pci devices each of which will need allocate some memory for dm pci to > use. I think it is worth checking this and using a value closer to what you need. board_init_f.c has a debug output for it I think. Also I wonder if we can avoid creating PCI devices for everything pre-relocation, when we only need serial? Regards, SImon
Hi Simon, On Wed, Aug 5, 2015 at 10:39 PM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 2 August 2015 at 19:52, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Simon, >> >> On Mon, Aug 3, 2015 at 6:31 AM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Bin, >>> >>> On 27 July 2015 at 01:33, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> Increase CONFIG_MALLOC_F_LEN so that dm pci does not fail with -ENOMEM >>>> before relocation. This makes pci uart work again on Intel Crown Bay. >>>> >>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >>>> --- >>>> >>>> arch/x86/cpu/queensbay/Kconfig | 3 +++ >>>> arch/x86/cpu/queensbay/tnc.c | 13 +++++++++++++ >>>> arch/x86/dts/crownbay.dts | 2 -- >>>> 3 files changed, 16 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig >>>> index fbf85f2..8eb619c 100644 >>>> --- a/arch/x86/cpu/queensbay/Kconfig >>>> +++ b/arch/x86/cpu/queensbay/Kconfig >>>> @@ -42,4 +42,7 @@ config CPU_ADDR_BITS >>>> int >>>> default 32 >>>> >>>> +config SYS_MALLOC_F_LEN >>>> + default 0x8000 >>> >>> 32KB? Wow that's a huge amount. How much does it actually use? Perhaps >>> we should change PCI so that it respects the u-boot,dm-pre-reloc >>> property? >>> >> >> I just add a zero to the original value :) I did not measure the >> actual memory consumption since after fsp_init() we have plenty of >> memory to be used as the stack. For queensbay platform, it has lots of >> pci devices each of which will need allocate some memory for dm pci to >> use. > > I think it is worth checking this and using a value closer to what you > need. board_init_f.c has a debug output for it I think. > OK, I will have a check. > Also I wonder if we can avoid creating PCI devices for everything > pre-relocation, when we only need serial? > Yes, looks that we only need serial. However x86 is a specific case since pci bus is the fundamental bus that is used to set up other devices. After conversion to dm pci, if we implement it correctly, any call to a pci api will trigger the enumeration and it is probably a side effect of using dm? I even think we can hardcoded pci uart in the pre-relocation phase without using dm at all, but that is not a portable way. Regards, Bin
Hi Bin, On 5 August 2015 at 20:48, Bin Meng <bmeng.cn@gmail.com> wrote: > Hi Simon, > > On Wed, Aug 5, 2015 at 10:39 PM, Simon Glass <sjg@chromium.org> wrote: >> Hi Bin, >> >> On 2 August 2015 at 19:52, Bin Meng <bmeng.cn@gmail.com> wrote: >>> Hi Simon, >>> >>> On Mon, Aug 3, 2015 at 6:31 AM, Simon Glass <sjg@chromium.org> wrote: >>>> Hi Bin, >>>> >>>> On 27 July 2015 at 01:33, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>> Increase CONFIG_MALLOC_F_LEN so that dm pci does not fail with -ENOMEM >>>>> before relocation. This makes pci uart work again on Intel Crown Bay. >>>>> >>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >>>>> --- >>>>> >>>>> arch/x86/cpu/queensbay/Kconfig | 3 +++ >>>>> arch/x86/cpu/queensbay/tnc.c | 13 +++++++++++++ >>>>> arch/x86/dts/crownbay.dts | 2 -- >>>>> 3 files changed, 16 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig >>>>> index fbf85f2..8eb619c 100644 >>>>> --- a/arch/x86/cpu/queensbay/Kconfig >>>>> +++ b/arch/x86/cpu/queensbay/Kconfig >>>>> @@ -42,4 +42,7 @@ config CPU_ADDR_BITS >>>>> int >>>>> default 32 >>>>> >>>>> +config SYS_MALLOC_F_LEN >>>>> + default 0x8000 >>>> >>>> 32KB? Wow that's a huge amount. How much does it actually use? Perhaps >>>> we should change PCI so that it respects the u-boot,dm-pre-reloc >>>> property? >>>> >>> >>> I just add a zero to the original value :) I did not measure the >>> actual memory consumption since after fsp_init() we have plenty of >>> memory to be used as the stack. For queensbay platform, it has lots of >>> pci devices each of which will need allocate some memory for dm pci to >>> use. >> >> I think it is worth checking this and using a value closer to what you >> need. board_init_f.c has a debug output for it I think. >> > > OK, I will have a check. > >> Also I wonder if we can avoid creating PCI devices for everything >> pre-relocation, when we only need serial? >> > > Yes, looks that we only need serial. However x86 is a specific case > since pci bus is the fundamental bus that is used to set up other > devices. After conversion to dm pci, if we implement it correctly, any > call to a pci api will trigger the enumeration and it is probably a > side effect of using dm? I even think we can hardcoded pci uart in > the pre-relocation phase without using dm at all, but that is not a > portable way. Yes that's right. Of course for the UART we can do a special case at least for the debug UART, since that should be available early (before DM). How about this: - early stage, before board_init_f(): use special x86 PCI functions, enable UART - pre-reloc: set up only a few devices which are needed before relocation - post-reloc: full scan of PCI Regards, Simon
Hi Simon, On Thu, Aug 6, 2015 at 10:55 AM, Simon Glass <sjg@chromium.org> wrote: > Hi Bin, > > On 5 August 2015 at 20:48, Bin Meng <bmeng.cn@gmail.com> wrote: >> Hi Simon, >> >> On Wed, Aug 5, 2015 at 10:39 PM, Simon Glass <sjg@chromium.org> wrote: >>> Hi Bin, >>> >>> On 2 August 2015 at 19:52, Bin Meng <bmeng.cn@gmail.com> wrote: >>>> Hi Simon, >>>> >>>> On Mon, Aug 3, 2015 at 6:31 AM, Simon Glass <sjg@chromium.org> wrote: >>>>> Hi Bin, >>>>> >>>>> On 27 July 2015 at 01:33, Bin Meng <bmeng.cn@gmail.com> wrote: >>>>>> Increase CONFIG_MALLOC_F_LEN so that dm pci does not fail with -ENOMEM >>>>>> before relocation. This makes pci uart work again on Intel Crown Bay. >>>>>> >>>>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> >>>>>> --- >>>>>> >>>>>> arch/x86/cpu/queensbay/Kconfig | 3 +++ >>>>>> arch/x86/cpu/queensbay/tnc.c | 13 +++++++++++++ >>>>>> arch/x86/dts/crownbay.dts | 2 -- >>>>>> 3 files changed, 16 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig >>>>>> index fbf85f2..8eb619c 100644 >>>>>> --- a/arch/x86/cpu/queensbay/Kconfig >>>>>> +++ b/arch/x86/cpu/queensbay/Kconfig >>>>>> @@ -42,4 +42,7 @@ config CPU_ADDR_BITS >>>>>> int >>>>>> default 32 >>>>>> >>>>>> +config SYS_MALLOC_F_LEN >>>>>> + default 0x8000 >>>>> >>>>> 32KB? Wow that's a huge amount. How much does it actually use? Perhaps >>>>> we should change PCI so that it respects the u-boot,dm-pre-reloc >>>>> property? >>>>> >>>> >>>> I just add a zero to the original value :) I did not measure the >>>> actual memory consumption since after fsp_init() we have plenty of >>>> memory to be used as the stack. For queensbay platform, it has lots of >>>> pci devices each of which will need allocate some memory for dm pci to >>>> use. >>> >>> I think it is worth checking this and using a value closer to what you >>> need. board_init_f.c has a debug output for it I think. >>> >> >> OK, I will have a check. >> >>> Also I wonder if we can avoid creating PCI devices for everything >>> pre-relocation, when we only need serial? >>> >> >> Yes, looks that we only need serial. However x86 is a specific case >> since pci bus is the fundamental bus that is used to set up other >> devices. After conversion to dm pci, if we implement it correctly, any >> call to a pci api will trigger the enumeration and it is probably a >> side effect of using dm? I even think we can hardcoded pci uart in >> the pre-relocation phase without using dm at all, but that is not a >> portable way. > > Yes that's right. Of course for the UART we can do a special case at > least for the debug UART, since that should be available early (before > DM). > > How about this: > > - early stage, before board_init_f(): use special x86 PCI functions, enable UART > - pre-reloc: set up only a few devices which are needed before relocation > - post-reloc: full scan of PCI > This sounds good. I will need do more investigation on this. Regards, Bin
diff --git a/arch/x86/cpu/queensbay/Kconfig b/arch/x86/cpu/queensbay/Kconfig index fbf85f2..8eb619c 100644 --- a/arch/x86/cpu/queensbay/Kconfig +++ b/arch/x86/cpu/queensbay/Kconfig @@ -42,4 +42,7 @@ config CPU_ADDR_BITS int default 32 +config SYS_MALLOC_F_LEN + default 0x8000 + endif diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c index de50893..322534b 100644 --- a/arch/x86/cpu/queensbay/tnc.c +++ b/arch/x86/cpu/queensbay/tnc.c @@ -13,6 +13,7 @@ #include <asm/arch/tnc.h> #include <asm/fsp/fsp_support.h> #include <asm/processor.h> +#include <dm.h> static void unprotect_spi_flash(void) { @@ -36,6 +37,18 @@ int arch_cpu_init(void) if (ret) return ret; + return 0; +} + +int arch_cpu_init_dm(void) +{ + struct udevice *dev; + int ret; + + ret = uclass_first_device(UCLASS_PCI, &dev); + if (ret) + return ret; + unprotect_spi_flash(); return 0; diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts index 3af9cc3..2714370 100644 --- a/arch/x86/dts/crownbay.dts +++ b/arch/x86/dts/crownbay.dts @@ -100,13 +100,11 @@ pcie@17,0 { #address-cells = <3>; #size-cells = <2>; - compatible = "intel,pci"; device_type = "pci"; topcliff@0,0 { #address-cells = <3>; #size-cells = <2>; - compatible = "intel,pci"; device_type = "pci"; pciuart0: uart@a,1 {
Increase CONFIG_MALLOC_F_LEN so that dm pci does not fail with -ENOMEM before relocation. This makes pci uart work again on Intel Crown Bay. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> --- arch/x86/cpu/queensbay/Kconfig | 3 +++ arch/x86/cpu/queensbay/tnc.c | 13 +++++++++++++ arch/x86/dts/crownbay.dts | 2 -- 3 files changed, 16 insertions(+), 2 deletions(-)