| Message ID | 1447968947-8395-11-git-send-email-dinguyen@opensource.altera.com |
|---|---|
| State | Superseded |
| Delegated to: | Marek Vasut |
| Headers | show |
On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen@opensource.altera.com wrote: > From: Dinh Nguyen <dinguyen@opensource.altera.com> > > Update Makefile to build Arria 10. > > Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> > --- > arch/arm/mach-socfpga/Makefile | 7 +++++-- > arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ > 2 files changed, 12 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/mach-socfpga/arria10/Makefile > > diff --git a/arch/arm/mach-socfpga/Makefile > b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 > --- a/arch/arm/mach-socfpga/Makefile > +++ b/arch/arm/mach-socfpga/Makefile > @@ -6,15 +6,18 @@ > # > # SPDX-License-Identifier: GPL-2.0+ > # > - > +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) > obj-y += misc.o timer.o reset_manager.o system_manager.o clock_manager.o \ > fpga_manager.o scan_manager.o > obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o > - > # QTS-generated config file wrappers > obj-y += wrap_pll_config.o > obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ > wrap_sdram_config.o > +else > +obj-y += arria10/ So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ? > +endif > + > CFLAGS_wrap_iocsr_config.o += -I$(srctree)/board/$(BOARDDIR) > CFLAGS_wrap_pinmux_config.o += -I$(srctree)/board/$(BOARDDIR) > CFLAGS_wrap_pll_config.o += -I$(srctree)/board/$(BOARDDIR) > diff --git a/arch/arm/mach-socfpga/arria10/Makefile > b/arch/arm/mach-socfpga/arria10/Makefile new file mode 100644 > index 0000000..f5e4b7d > --- /dev/null > +++ b/arch/arm/mach-socfpga/arria10/Makefile > @@ -0,0 +1,7 @@ > +# > +# Copyright (C) 2015 Altera Corporation <www.altera.com> > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > + > +obj-y := misc_a10.o reset_manager_a10.o sdram_a10.o Best regards, Marek Vasut
On 11/19/2015 04:45 PM, Marek Vasut wrote: > On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen@opensource.altera.com > wrote: >> From: Dinh Nguyen <dinguyen@opensource.altera.com> >> >> Update Makefile to build Arria 10. >> >> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> >> --- >> arch/arm/mach-socfpga/Makefile | 7 +++++-- >> arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ >> 2 files changed, 12 insertions(+), 2 deletions(-) >> create mode 100644 arch/arm/mach-socfpga/arria10/Makefile >> >> diff --git a/arch/arm/mach-socfpga/Makefile >> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 >> --- a/arch/arm/mach-socfpga/Makefile >> +++ b/arch/arm/mach-socfpga/Makefile >> @@ -6,15 +6,18 @@ >> # >> # SPDX-License-Identifier: GPL-2.0+ >> # >> - >> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) >> obj-y += misc.o timer.o reset_manager.o system_manager.o > clock_manager.o \ >> fpga_manager.o scan_manager.o >> obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o >> - >> # QTS-generated config file wrappers >> obj-y += wrap_pll_config.o >> obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ >> wrap_sdram_config.o >> +else >> +obj-y += arria10/ > > So why exactly does A10 have it's own dedicated dir if most of the code > is probably shared between A10 and AV/CV ? > Yes, there are some sharing. But I think that there will be enough differences that will ultimately warrant it's own directory. I think with it's own directory, the Makefile changes stay a bit cleaner. I One of the biggest differences is that the A10's SDRAM support is going to be a bit ugly. The main point is that we need to program the FPGA during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory. Dinh
On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote: > On 11/19/2015 04:45 PM, Marek Vasut wrote: > > On Thursday, November 19, 2015 at 10:35:47 PM, > > dinguyen@opensource.altera.com > > > > wrote: > >> From: Dinh Nguyen <dinguyen@opensource.altera.com> > >> > >> Update Makefile to build Arria 10. > >> > >> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> > >> --- > >> > >> arch/arm/mach-socfpga/Makefile | 7 +++++-- > >> arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ > >> 2 files changed, 12 insertions(+), 2 deletions(-) > >> create mode 100644 arch/arm/mach-socfpga/arria10/Makefile > >> > >> diff --git a/arch/arm/mach-socfpga/Makefile > >> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 > >> --- a/arch/arm/mach-socfpga/Makefile > >> +++ b/arch/arm/mach-socfpga/Makefile > >> @@ -6,15 +6,18 @@ > >> > >> # > >> # SPDX-License-Identifier: GPL-2.0+ > >> # > >> > >> - > >> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) > >> > >> obj-y += misc.o timer.o reset_manager.o system_manager.o > > > > clock_manager.o \ > > > >> fpga_manager.o scan_manager.o > >> > >> obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o > >> > >> - > >> > >> # QTS-generated config file wrappers > >> obj-y += wrap_pll_config.o > >> obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ > >> > >> wrap_sdram_config.o > >> > >> +else > >> +obj-y += arria10/ > > > > So why exactly does A10 have it's own dedicated dir if most of the code > > is probably shared between A10 and AV/CV ? > > Yes, there are some sharing. But I think that there will be enough > differences that will ultimately warrant it's own directory. I think > with it's own directory, the Makefile changes stay a bit cleaner. I Linux doesn't seem to require a separate directory though, does it ? I'm not convinced we need one either. > One of the biggest differences is that the A10's SDRAM support is going > to be a bit ugly. The SDRAM code goes into drivers/ddr/ , no problem. > The main point is that we need to program the FPGA > during U-Boot booting up with a ~>10 MB rbf file while being limited to > the OCRAM's size. I would like to contain this ugliness in it's own > directory. What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it. Best regards, Marek Vasut
On Thu 2015-11-19 17:28:47, Dinh Nguyen wrote: > On 11/19/2015 04:45 PM, Marek Vasut wrote: > > On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen@opensource.altera.com > > wrote: > >> From: Dinh Nguyen <dinguyen@opensource.altera.com> > >> > >> Update Makefile to build Arria 10. > >> > >> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> > >> --- > >> arch/arm/mach-socfpga/Makefile | 7 +++++-- > >> arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ > >> 2 files changed, 12 insertions(+), 2 deletions(-) > >> create mode 100644 arch/arm/mach-socfpga/arria10/Makefile > >> > >> diff --git a/arch/arm/mach-socfpga/Makefile > >> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 > >> --- a/arch/arm/mach-socfpga/Makefile > >> +++ b/arch/arm/mach-socfpga/Makefile > >> @@ -6,15 +6,18 @@ > >> # > >> # SPDX-License-Identifier: GPL-2.0+ > >> # > >> - > >> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) > >> obj-y += misc.o timer.o reset_manager.o system_manager.o > > clock_manager.o \ > >> fpga_manager.o scan_manager.o > >> obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o > >> - > >> # QTS-generated config file wrappers > >> obj-y += wrap_pll_config.o > >> obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ > >> wrap_sdram_config.o > >> +else > >> +obj-y += arria10/ > > > > So why exactly does A10 have it's own dedicated dir if most of the code > > is probably shared between A10 and AV/CV ? > > > > Yes, there are some sharing. But I think that there will be enough > differences that will ultimately warrant it's own directory. I think > with it's own directory, the Makefile changes stay a bit cleaner. I > > One of the biggest differences is that the A10's SDRAM support is going > to be a bit ugly. The main point is that we need to program the FPGA > during U-Boot booting up with a ~>10 MB rbf file while being limited to > the OCRAM's size. I would like to contain this ugliness in it's own > directory. Well.. so you'll have to optimize memory consuption of the fpga programming. It may be ugly, but once you are done, you'll want to use the optimized version for everyone -- not to keep two versions. Best regards, Pavel
On 11/20/2015 06:49 AM, Marek Vasut wrote: > On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote: >> On 11/19/2015 04:45 PM, Marek Vasut wrote: >>> On Thursday, November 19, 2015 at 10:35:47 PM, >>> dinguyen@opensource.altera.com >>> >>> wrote: >>>> From: Dinh Nguyen <dinguyen@opensource.altera.com> >>>> >>>> Update Makefile to build Arria 10. >>>> >>>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> >>>> --- >>>> >>>> arch/arm/mach-socfpga/Makefile | 7 +++++-- >>>> arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ >>>> 2 files changed, 12 insertions(+), 2 deletions(-) >>>> create mode 100644 arch/arm/mach-socfpga/arria10/Makefile >>>> >>>> diff --git a/arch/arm/mach-socfpga/Makefile >>>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 >>>> --- a/arch/arm/mach-socfpga/Makefile >>>> +++ b/arch/arm/mach-socfpga/Makefile >>>> @@ -6,15 +6,18 @@ >>>> >>>> # >>>> # SPDX-License-Identifier: GPL-2.0+ >>>> # >>>> >>>> - >>>> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) >>>> >>>> obj-y += misc.o timer.o reset_manager.o system_manager.o >>> >>> clock_manager.o \ >>> >>>> fpga_manager.o scan_manager.o >>>> >>>> obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o >>>> >>>> - >>>> >>>> # QTS-generated config file wrappers >>>> obj-y += wrap_pll_config.o >>>> obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ >>>> >>>> wrap_sdram_config.o >>>> >>>> +else >>>> +obj-y += arria10/ >>> >>> So why exactly does A10 have it's own dedicated dir if most of the code >>> is probably shared between A10 and AV/CV ? >> >> Yes, there are some sharing. But I think that there will be enough >> differences that will ultimately warrant it's own directory. I think >> with it's own directory, the Makefile changes stay a bit cleaner. I > > Linux doesn't seem to require a separate directory though, does it ? > I'm not convinced we need one either. > >> One of the biggest differences is that the A10's SDRAM support is going >> to be a bit ugly. > > The SDRAM code goes into drivers/ddr/ , no problem. > >> The main point is that we need to program the FPGA >> during U-Boot booting up with a ~>10 MB rbf file while being limited to >> the OCRAM's size. I would like to contain this ugliness in it's own >> directory. > > What's the problem with this ? We already support loading files from storage > in SPL, so just compile the FPGA manager into SPL as well and use it. > Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing. Dinh
On Monday, November 23, 2015 at 03:36:14 PM, Dinh Nguyen wrote: > On 11/20/2015 06:49 AM, Marek Vasut wrote: > > On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote: > >> On 11/19/2015 04:45 PM, Marek Vasut wrote: > >>> On Thursday, November 19, 2015 at 10:35:47 PM, > >>> dinguyen@opensource.altera.com > >>> > >>> wrote: > >>>> From: Dinh Nguyen <dinguyen@opensource.altera.com> > >>>> > >>>> Update Makefile to build Arria 10. > >>>> > >>>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> > >>>> --- > >>>> > >>>> arch/arm/mach-socfpga/Makefile | 7 +++++-- > >>>> arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ > >>>> 2 files changed, 12 insertions(+), 2 deletions(-) > >>>> create mode 100644 arch/arm/mach-socfpga/arria10/Makefile > >>>> > >>>> diff --git a/arch/arm/mach-socfpga/Makefile > >>>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 > >>>> --- a/arch/arm/mach-socfpga/Makefile > >>>> +++ b/arch/arm/mach-socfpga/Makefile > >>>> @@ -6,15 +6,18 @@ > >>>> > >>>> # > >>>> # SPDX-License-Identifier: GPL-2.0+ > >>>> # > >>>> > >>>> - > >>>> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) > >>>> > >>>> obj-y += misc.o timer.o reset_manager.o system_manager.o > >>> > >>> clock_manager.o \ > >>> > >>>> fpga_manager.o scan_manager.o > >>>> > >>>> obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o > >>>> > >>>> - > >>>> > >>>> # QTS-generated config file wrappers > >>>> obj-y += wrap_pll_config.o > >>>> obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ > >>>> > >>>> wrap_sdram_config.o > >>>> > >>>> +else > >>>> +obj-y += arria10/ > >>> > >>> So why exactly does A10 have it's own dedicated dir if most of the code > >>> is probably shared between A10 and AV/CV ? > >> > >> Yes, there are some sharing. But I think that there will be enough > >> differences that will ultimately warrant it's own directory. I think > >> with it's own directory, the Makefile changes stay a bit cleaner. I > > > > Linux doesn't seem to require a separate directory though, does it ? > > I'm not convinced we need one either. > > > >> One of the biggest differences is that the A10's SDRAM support is going > >> to be a bit ugly. > > > > The SDRAM code goes into drivers/ddr/ , no problem. > > > >> The main point is that we need to program the FPGA > >> during U-Boot booting up with a ~>10 MB rbf file while being limited to > >> the OCRAM's size. I would like to contain this ugliness in it's own > >> directory. > > > > What's the problem with this ? We already support loading files from > > storage in SPL, so just compile the FPGA manager into SPL as well and > > use it. > > Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing. But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?
On 11/23/2015 09:38 AM, Marek Vasut wrote: > On Monday, November 23, 2015 at 03:36:14 PM, Dinh Nguyen wrote: >> On 11/20/2015 06:49 AM, Marek Vasut wrote: >>> On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote: >>>> On 11/19/2015 04:45 PM, Marek Vasut wrote: >>>>> On Thursday, November 19, 2015 at 10:35:47 PM, >>>>> dinguyen@opensource.altera.com >>>>> >>>>> wrote: >>>>>> From: Dinh Nguyen <dinguyen@opensource.altera.com> >>>>>> >>>>>> Update Makefile to build Arria 10. >>>>>> >>>>>> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com> >>>>>> --- >>>>>> >>>>>> arch/arm/mach-socfpga/Makefile | 7 +++++-- >>>>>> arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ >>>>>> 2 files changed, 12 insertions(+), 2 deletions(-) >>>>>> create mode 100644 arch/arm/mach-socfpga/arria10/Makefile >>>>>> >>>>>> diff --git a/arch/arm/mach-socfpga/Makefile >>>>>> b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 >>>>>> --- a/arch/arm/mach-socfpga/Makefile >>>>>> +++ b/arch/arm/mach-socfpga/Makefile >>>>>> @@ -6,15 +6,18 @@ >>>>>> >>>>>> # >>>>>> # SPDX-License-Identifier: GPL-2.0+ >>>>>> # >>>>>> >>>>>> - >>>>>> +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) >>>>>> >>>>>> obj-y += misc.o timer.o reset_manager.o system_manager.o >>>>> >>>>> clock_manager.o \ >>>>> >>>>>> fpga_manager.o scan_manager.o >>>>>> >>>>>> obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o >>>>>> >>>>>> - >>>>>> >>>>>> # QTS-generated config file wrappers >>>>>> obj-y += wrap_pll_config.o >>>>>> obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ >>>>>> >>>>>> wrap_sdram_config.o >>>>>> >>>>>> +else >>>>>> +obj-y += arria10/ >>>>> >>>>> So why exactly does A10 have it's own dedicated dir if most of the code >>>>> is probably shared between A10 and AV/CV ? >>>> >>>> Yes, there are some sharing. But I think that there will be enough >>>> differences that will ultimately warrant it's own directory. I think >>>> with it's own directory, the Makefile changes stay a bit cleaner. I >>> >>> Linux doesn't seem to require a separate directory though, does it ? >>> I'm not convinced we need one either. >>> >>>> One of the biggest differences is that the A10's SDRAM support is going >>>> to be a bit ugly. >>> >>> The SDRAM code goes into drivers/ddr/ , no problem. >>> >>>> The main point is that we need to program the FPGA >>>> during U-Boot booting up with a ~>10 MB rbf file while being limited to >>>> the OCRAM's size. I would like to contain this ugliness in it's own >>>> directory. >>> >>> What's the problem with this ? We already support loading files from >>> storage in SPL, so just compile the FPGA manager into SPL as well and >>> use it. >> >> Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing. > > But you didn't really answer my question -- what is the problem with the FPGA > loader in SPL ? > I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose. Dinh
On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote: [...] > >>>> The main point is that we need to program the FPGA > >>>> during U-Boot booting up with a ~>10 MB rbf file while being limited > >>>> to the OCRAM's size. I would like to contain this ugliness in it's > >>>> own directory. > >>> > >>> What's the problem with this ? We already support loading files from > >>> storage in SPL, so just compile the FPGA manager into SPL as well and > >>> use it. > >> > >> Ok, let me re-work it all under the c5/a5 directory. Thanks for > >> reviewing. > > > > But you didn't really answer my question -- what is the problem with the > > FPGA loader in SPL ? > > I thought you've already answered your own question. For whatever > reason, the downstream A10 is re-doing the FPGA manager just for this > purpose. Could the reason be that the FPGA manager in it's current state expects one big buffer with the entire FPGA bitstream ? When you're in SPL and you still don't have DRAM running, you cannot create such buffer anywhere. Thus, what you need to do is to have some sort of code which loads a bit of the bitstream file at time and feeds it into the FPGA manager, piece by piece. This should be doable pretty easily, what do you think ? Best regards, Marek Vasut
On 11/23/2015 04:46 PM, Marek Vasut wrote: > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote: > [...] >>>>>> The main point is that we need to program the FPGA >>>>>> during U-Boot booting up with a ~>10 MB rbf file while being limited >>>>>> to the OCRAM's size. I would like to contain this ugliness in it's >>>>>> own directory. >>>>> >>>>> What's the problem with this ? We already support loading files from >>>>> storage in SPL, so just compile the FPGA manager into SPL as well and >>>>> use it. >>>> >>>> Ok, let me re-work it all under the c5/a5 directory. Thanks for >>>> reviewing. >>> >>> But you didn't really answer my question -- what is the problem with the >>> FPGA loader in SPL ? >> >> I thought you've already answered your own question. For whatever >> reason, the downstream A10 is re-doing the FPGA manager just for this >> purpose. > > Could the reason be that the FPGA manager in it's current state expects one big > buffer with the entire FPGA bitstream ? When you're in SPL and you still don't > have DRAM running, you cannot create such buffer anywhere. Thus, what you need > to do is to have some sort of code which loads a bit of the bitstream file at > time and feeds it into the FPGA manager, piece by piece. This should be doable > pretty easily, what do you think ? > That's exactly what is being in the mach-socfpga directory. Yes, but should that code go into mach-socfpga or drivers? Dinh
On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote: > On 11/23/2015 04:46 PM, Marek Vasut wrote: > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote: > > [...] > > > >>>>>> The main point is that we need to program the FPGA > >>>>>> during U-Boot booting up with a ~>10 MB rbf file while being limited > >>>>>> to the OCRAM's size. I would like to contain this ugliness in it's > >>>>>> own directory. > >>>>> > >>>>> What's the problem with this ? We already support loading files from > >>>>> storage in SPL, so just compile the FPGA manager into SPL as well and > >>>>> use it. > >>>> > >>>> Ok, let me re-work it all under the c5/a5 directory. Thanks for > >>>> reviewing. > >>> > >>> But you didn't really answer my question -- what is the problem with > >>> the FPGA loader in SPL ? > >> > >> I thought you've already answered your own question. For whatever > >> reason, the downstream A10 is re-doing the FPGA manager just for this > >> purpose. > > > > Could the reason be that the FPGA manager in it's current state expects > > one big buffer with the entire FPGA bitstream ? When you're in SPL and > > you still don't have DRAM running, you cannot create such buffer > > anywhere. Thus, what you need to do is to have some sort of code which > > loads a bit of the bitstream file at time and feeds it into the FPGA > > manager, piece by piece. This should be doable pretty easily, what do > > you think ? > > That's exactly what is being in the mach-socfpga directory. Um, am I missing it in this patchset ? > Yes, but should that code go into mach-socfpga or drivers? The FPGA manager bits are already in drivers/fpga/ , so that's where the improvements should go. If you need some special handling in the SPL, that should be in mach-socfpga . In case it's too much change to the current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make sense ... or something like that, possibly even with some spl-common.c . Best regards, Marek Vasut
On 11/23/2015 05:03 PM, Marek Vasut wrote: > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote: >> On 11/23/2015 04:46 PM, Marek Vasut wrote: >>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote: >>> [...] >>> >>>>>>>> The main point is that we need to program the FPGA >>>>>>>> during U-Boot booting up with a ~>10 MB rbf file while being limited >>>>>>>> to the OCRAM's size. I would like to contain this ugliness in it's >>>>>>>> own directory. >>>>>>> >>>>>>> What's the problem with this ? We already support loading files from >>>>>>> storage in SPL, so just compile the FPGA manager into SPL as well and >>>>>>> use it. >>>>>> >>>>>> Ok, let me re-work it all under the c5/a5 directory. Thanks for >>>>>> reviewing. >>>>> >>>>> But you didn't really answer my question -- what is the problem with >>>>> the FPGA loader in SPL ? >>>> >>>> I thought you've already answered your own question. For whatever >>>> reason, the downstream A10 is re-doing the FPGA manager just for this >>>> purpose. >>> >>> Could the reason be that the FPGA manager in it's current state expects >>> one big buffer with the entire FPGA bitstream ? When you're in SPL and >>> you still don't have DRAM running, you cannot create such buffer >>> anywhere. Thus, what you need to do is to have some sort of code which >>> loads a bit of the bitstream file at time and feeds it into the FPGA >>> manager, piece by piece. This should be doable pretty easily, what do >>> you think ? >> >> That's exactly what is being in the mach-socfpga directory. > > Um, am I missing it in this patchset ? > No, you're not missing it, I have not sent it up yet. That support is in the downstream, but also with the fpga-manager driver re-written. I need to clean this up before I can send it. >> Yes, but should that code go into mach-socfpga or drivers? > > The FPGA manager bits are already in drivers/fpga/ , so that's where the > improvements should go. If you need some special handling in the SPL, > that should be in mach-socfpga . In case it's too much change to the current > SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c might make > sense ... or something like that, possibly even with some spl-common.c . > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can use to setup the SDRAM. Dinh
On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote: > On 11/23/2015 05:03 PM, Marek Vasut wrote: > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote: > >> On 11/23/2015 04:46 PM, Marek Vasut wrote: > >>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote: > >>> [...] > >>> > >>>>>>>> The main point is that we need to program the FPGA > >>>>>>>> during U-Boot booting up with a ~>10 MB rbf file while being > >>>>>>>> limited to the OCRAM's size. I would like to contain this > >>>>>>>> ugliness in it's own directory. > >>>>>>> > >>>>>>> What's the problem with this ? We already support loading files > >>>>>>> from storage in SPL, so just compile the FPGA manager into SPL as > >>>>>>> well and use it. > >>>>>> > >>>>>> Ok, let me re-work it all under the c5/a5 directory. Thanks for > >>>>>> reviewing. > >>>>> > >>>>> But you didn't really answer my question -- what is the problem with > >>>>> the FPGA loader in SPL ? > >>>> > >>>> I thought you've already answered your own question. For whatever > >>>> reason, the downstream A10 is re-doing the FPGA manager just for this > >>>> purpose. > >>> > >>> Could the reason be that the FPGA manager in it's current state expects > >>> one big buffer with the entire FPGA bitstream ? When you're in SPL and > >>> you still don't have DRAM running, you cannot create such buffer > >>> anywhere. Thus, what you need to do is to have some sort of code which > >>> loads a bit of the bitstream file at time and feeds it into the FPGA > >>> manager, piece by piece. This should be doable pretty easily, what do > >>> you think ? > >> > >> That's exactly what is being in the mach-socfpga directory. > > > > Um, am I missing it in this patchset ? > > No, you're not missing it, I have not sent it up yet. That support is in > the downstream, but also with the fpga-manager driver re-written. I need > to clean this up before I can send it. OK, thanks :) > >> Yes, but should that code go into mach-socfpga or drivers? > > > > The FPGA manager bits are already in drivers/fpga/ , so that's where the > > improvements should go. If you need some special handling in the SPL, > > that should be in mach-socfpga . In case it's too much change to the > > current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c > > might make sense ... or something like that, possibly even with some > > spl-common.c . > > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can > use to setup the SDRAM. So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't fit into 256kiB, so I think using SPL might be the sensible thing afterall, since you would be able to use arbitrarily-sized U-Boot. Best regards, Marek Vasut
On 11/23/2015 05:20 PM, Marek Vasut wrote: > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote: >> On 11/23/2015 05:03 PM, Marek Vasut wrote: >>> On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote: >>>> On 11/23/2015 04:46 PM, Marek Vasut wrote: >>>>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen wrote: >>>>> [...] >>>>> >>>>>>>>>> The main point is that we need to program the FPGA >>>>>>>>>> during U-Boot booting up with a ~>10 MB rbf file while being >>>>>>>>>> limited to the OCRAM's size. I would like to contain this >>>>>>>>>> ugliness in it's own directory. >>>>>>>>> >>>>>>>>> What's the problem with this ? We already support loading files >>>>>>>>> from storage in SPL, so just compile the FPGA manager into SPL as >>>>>>>>> well and use it. >>>>>>>> >>>>>>>> Ok, let me re-work it all under the c5/a5 directory. Thanks for >>>>>>>> reviewing. >>>>>>> >>>>>>> But you didn't really answer my question -- what is the problem with >>>>>>> the FPGA loader in SPL ? >>>>>> >>>>>> I thought you've already answered your own question. For whatever >>>>>> reason, the downstream A10 is re-doing the FPGA manager just for this >>>>>> purpose. >>>>> >>>>> Could the reason be that the FPGA manager in it's current state expects >>>>> one big buffer with the entire FPGA bitstream ? When you're in SPL and >>>>> you still don't have DRAM running, you cannot create such buffer >>>>> anywhere. Thus, what you need to do is to have some sort of code which >>>>> loads a bit of the bitstream file at time and feeds it into the FPGA >>>>> manager, piece by piece. This should be doable pretty easily, what do >>>>> you think ? >>>> >>>> That's exactly what is being in the mach-socfpga directory. >>> >>> Um, am I missing it in this patchset ? >> >> No, you're not missing it, I have not sent it up yet. That support is in >> the downstream, but also with the fpga-manager driver re-written. I need >> to clean this up before I can send it. > > OK, thanks :) > >>>> Yes, but should that code go into mach-socfpga or drivers? >>> >>> The FPGA manager bits are already in drivers/fpga/ , so that's where the >>> improvements should go. If you need some special handling in the SPL, >>> that should be in mach-socfpga . In case it's too much change to the >>> current SPL, moving the spl.c to spl-gen5.c and creating new spl-gen10.c >>> might make sense ... or something like that, possibly even with some >>> spl-common.c . >> >> Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U-Boot can >> use to setup the SDRAM. > > So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS won't > fit into 256kiB, so I think using SPL might be the sensible thing afterall, > since you would be able to use arbitrarily-sized U-Boot. > I hope Chin Liang can chime here, I know that we have support for NAND, but I haven't been part of that task, so I don't know how it's being done. Dinh
On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote: > On 11/23/2015 05:20 PM, Marek Vasut wrote: > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote: > > > On 11/23/2015 05:03 PM, Marek Vasut wrote: > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote: > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote: > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen > > > > > > wrote: > > > > > > [...] > > > > > > > > > > > > > > > > > The main point is that we need to program the > > > > > > > > > > > FPGA > > > > > > > > > > > during U-Boot booting up with a ~>10 MB rbf file > > > > > > > > > > > while being > > > > > > > > > > > limited to the OCRAM's size. I would like to > > > > > > > > > > > contain this > > > > > > > > > > > ugliness in it's own directory. > > > > > > > > > > > > > > > > > > > > What's the problem with this ? We already support > > > > > > > > > > loading files > > > > > > > > > > from storage in SPL, so just compile the FPGA > > > > > > > > > > manager into SPL as > > > > > > > > > > well and use it. > > > > > > > > > > > > > > > > > > Ok, let me re-work it all under the c5/a5 directory. > > > > > > > > > Thanks for > > > > > > > > > reviewing. > > > > > > > > > > > > > > > > But you didn't really answer my question -- what is the > > > > > > > > problem with > > > > > > > > the FPGA loader in SPL ? > > > > > > > > > > > > > > I thought you've already answered your own question. For > > > > > > > whatever > > > > > > > reason, the downstream A10 is re-doing the FPGA manager > > > > > > > just for this > > > > > > > purpose. > > > > > > > > > > > > Could the reason be that the FPGA manager in it's current > > > > > > state expects > > > > > > one big buffer with the entire FPGA bitstream ? When you're > > > > > > in SPL and > > > > > > you still don't have DRAM running, you cannot create such > > > > > > buffer > > > > > > anywhere. Thus, what you need to do is to have some sort of > > > > > > code which > > > > > > loads a bit of the bitstream file at time and feeds it into > > > > > > the FPGA > > > > > > manager, piece by piece. This should be doable pretty > > > > > > easily, what do > > > > > > you think ? > > > > > > > > > > That's exactly what is being in the mach-socfpga directory. > > > > > > > > Um, am I missing it in this patchset ? > > > > > > No, you're not missing it, I have not sent it up yet. That > > > support is in > > > the downstream, but also with the fpga-manager driver re-written. > > > I need > > > to clean this up before I can send it. > > > > OK, thanks :) > > > > > > > Yes, but should that code go into mach-socfpga or drivers? > > > > > > > > The FPGA manager bits are already in drivers/fpga/ , so that's > > > > where the > > > > improvements should go. If you need some special handling in > > > > the SPL, > > > > that should be in mach-socfpga . In case it's too much change > > > > to the > > > > current SPL, moving the spl.c to spl-gen5.c and creating new > > > > spl-gen10.c > > > > might make sense ... or something like that, possibly even with > > > > some > > > > spl-common.c . > > > > > > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U > > > -Boot can > > > use to setup the SDRAM. > > > > So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS > > won't > > fit into 256kiB, so I think using SPL might be the sensible thing > > afterall, > > since you would be able to use arbitrarily-sized U-Boot. > > > > I hope Chin Liang can chime here, I know that we have support for > NAND, > but I haven't been part of that task, so I don't know how it's being > done. Finally my email is back online :) We do have NAND support but not with UBI and UBIFS. For this support, user can use U-Boot to load arbitrarily-sized U-Boot that run on SDRAM. One of the nice thing of U-Boot over SPL is the console support and ability to troubleshoot. This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV SoC 64kB). Thanks Chin Liang > > Dinh > >
On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote: > On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote: > > On 11/23/2015 05:20 PM, Marek Vasut wrote: > > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote: > > > > On 11/23/2015 05:03 PM, Marek Vasut wrote: > > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote: > > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote: > > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen > > > > > > > wrote: > > > > > > > [...] > > > > > > > > > > > > > > > > > > > The main point is that we need to program the > > > > > > > > > > > > FPGA > > > > > > > > > > > > during U-Boot booting up with a ~>10 MB rbf file > > > > > > > > > > > > while being > > > > > > > > > > > > limited to the OCRAM's size. I would like to > > > > > > > > > > > > contain this > > > > > > > > > > > > ugliness in it's own directory. > > > > > > > > > > > > > > > > > > > > > > What's the problem with this ? We already support > > > > > > > > > > > loading files > > > > > > > > > > > from storage in SPL, so just compile the FPGA > > > > > > > > > > > manager into SPL as > > > > > > > > > > > well and use it. > > > > > > > > > > > > > > > > > > > > Ok, let me re-work it all under the c5/a5 directory. > > > > > > > > > > Thanks for > > > > > > > > > > reviewing. > > > > > > > > > > > > > > > > > > But you didn't really answer my question -- what is the > > > > > > > > > problem with > > > > > > > > > the FPGA loader in SPL ? > > > > > > > > > > > > > > > > I thought you've already answered your own question. For > > > > > > > > whatever > > > > > > > > reason, the downstream A10 is re-doing the FPGA manager > > > > > > > > just for this > > > > > > > > purpose. > > > > > > > > > > > > > > Could the reason be that the FPGA manager in it's current > > > > > > > state expects > > > > > > > one big buffer with the entire FPGA bitstream ? When you're > > > > > > > in SPL and > > > > > > > you still don't have DRAM running, you cannot create such > > > > > > > buffer > > > > > > > anywhere. Thus, what you need to do is to have some sort of > > > > > > > code which > > > > > > > loads a bit of the bitstream file at time and feeds it into > > > > > > > the FPGA > > > > > > > manager, piece by piece. This should be doable pretty > > > > > > > easily, what do > > > > > > > you think ? > > > > > > > > > > > > That's exactly what is being in the mach-socfpga directory. > > > > > > > > > > Um, am I missing it in this patchset ? > > > > > > > > No, you're not missing it, I have not sent it up yet. That > > > > support is in > > > > the downstream, but also with the fpga-manager driver re-written. > > > > I need > > > > to clean this up before I can send it. > > > > > > OK, thanks :) > > > > > > > > > Yes, but should that code go into mach-socfpga or drivers? > > > > > > > > > > The FPGA manager bits are already in drivers/fpga/ , so that's > > > > > where the > > > > > improvements should go. If you need some special handling in > > > > > the SPL, > > > > > that should be in mach-socfpga . In case it's too much change > > > > > to the > > > > > current SPL, moving the spl.c to spl-gen5.c and creating new > > > > > spl-gen10.c > > > > > might make sense ... or something like that, possibly even with > > > > > some > > > > > spl-common.c . > > > > > > > > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U > > > > -Boot can > > > > use to setup the SDRAM. > > > > > > So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS > > > won't > > > fit into 256kiB, so I think using SPL might be the sensible thing > > > afterall, > > > since you would be able to use arbitrarily-sized U-Boot. > > > > I hope Chin Liang can chime here, I know that we have support for > > NAND, > > but I haven't been part of that task, so I don't know how it's being > > done. > > Finally my email is back online :) > > We do have NAND support but not with UBI and UBIFS. I just hope you're not using raw NAND and just hoping it will work. > For this support, user can use U-Boot to load arbitrarily-sized U-Boot > that run on SDRAM. > > One of the nice thing of U-Boot over SPL is the console support and > ability to troubleshoot. > This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV > SoC 64kB). OK, that's not really the point here -- the point is, if you compile enough features into U-Boot, it will be bigger than those 256k. What will you do then ? Best regards, Marek Vasut
Hi Heiko, On Tue, 2015-11-24 at 13:29 +0100, Heiko Schocher wrote: > Hello Marek, Chin Liang See, > > Sorry for digging so late into this topic ... No worries as inputs always appreciated. > > Am 24.11.2015 um 10:31 schrieb Marek Vasut: > > On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote: > > > On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote: > > > > On 11/23/2015 05:20 PM, Marek Vasut wrote: > > > > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen > > > > > wrote: > > > > > > On 11/23/2015 05:03 PM, Marek Vasut wrote: > > > > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen > > > > > > > wrote: > > > > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote: > > > > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh > > > > > > > > > Nguyen > > > > > > > > > wrote: > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > The main point is that we need to program > > > > > > > > > > > > > > the > > > > > > > > > > > > > > FPGA > > > > > > > > > > > > > > during U-Boot booting up with a ~>10 MB rbf > > > > > > > > > > > > > > file > > > > > > > > > > > > > > while being > > > > > > > > > > > > > > limited to the OCRAM's size. I would like > > > > > > > > > > > > > > to > > > > > > > > > > > > > > contain this > > > > > > > > > > > > > > ugliness in it's own directory. > > > > > > > > > > > > > > > > > > > > > > > > > > What's the problem with this ? We already > > > > > > > > > > > > > support > > > > > > > > > > > > > loading files > > > > > > > > > > > > > from storage in SPL, so just compile the FPGA > > > > > > > > > > > > > manager into SPL as > > > > > > > > > > > > > well and use it. > > > > > > > > > > > > > > > > > > > > > > > > Ok, let me re-work it all under the c5/a5 > > > > > > > > > > > > directory. > > > > > > > > > > > > Thanks for > > > > > > > > > > > > reviewing. > > > > > > > > > > > > > > > > > > > > > > But you didn't really answer my question -- what > > > > > > > > > > > is the > > > > > > > > > > > problem with > > > > > > > > > > > the FPGA loader in SPL ? > > > > > > > > > > > > > > > > > > > > I thought you've already answered your own > > > > > > > > > > question. For > > > > > > > > > > whatever > > > > > > > > > > reason, the downstream A10 is re-doing the FPGA > > > > > > > > > > manager > > > > > > > > > > just for this > > > > > > > > > > purpose. > > > > > > > > > > > > > > > > > > Could the reason be that the FPGA manager in it's > > > > > > > > > current > > > > > > > > > state expects > > > > > > > > > one big buffer with the entire FPGA bitstream ? When > > > > > > > > > you're > > > > > > > > > in SPL and > > > > > > > > > you still don't have DRAM running, you cannot create > > > > > > > > > such > > > > > > > > > buffer > > > > > > > > > anywhere. Thus, what you need to do is to have some > > > > > > > > > sort of > > > > > > > > > code which > > > > > > > > > loads a bit of the bitstream file at time and feeds > > > > > > > > > it into > > > > > > > > > the FPGA > > > > > > > > > manager, piece by piece. This should be doable pretty > > > > > > > > > easily, what do > > > > > > > > > you think ? > > > > > > > > > > > > > > > > That's exactly what is being in the mach-socfpga > > > > > > > > directory. > > > > > > > > > > > > > > Um, am I missing it in this patchset ? > > > > > > > > > > > > No, you're not missing it, I have not sent it up yet. That > > > > > > support is in > > > > > > the downstream, but also with the fpga-manager driver re > > > > > > -written. > > > > > > I need > > > > > > to clean this up before I can send it. > > > > > > > > > > OK, thanks :) > > > > > > > > > > > > > Yes, but should that code go into mach-socfpga or > > > > > > > > drivers? > > > > > > > > > > > > > > The FPGA manager bits are already in drivers/fpga/ , so > > > > > > > that's > > > > > > > where the > > > > > > > improvements should go. If you need some special handling > > > > > > > in > > > > > > > the SPL, > > > > > > > that should be in mach-socfpga . In case it's too much > > > > > > > change > > > > > > > to the > > > > > > > current SPL, moving the spl.c to spl-gen5.c and creating > > > > > > > new > > > > > > > spl-gen10.c > > > > > > > might make sense ... or something like that, possibly > > > > > > > even with > > > > > > > some > > > > > > > spl-common.c . > > > > > > > > > > > > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM > > > > > > that U > > > > > > -Boot can > > > > > > use to setup the SDRAM. > > > > > > > > > > So what do I do if I want to boot arria10 from NAND ? UBI and > > > > > UBIFS > > > > > won't > > > > > fit into 256kiB, so I think using SPL might be the sensible > > > > > thing > > > > > afterall, > > > > > since you would be able to use arbitrarily-sized U-Boot. > > > Maybe you can try: > [U-Boot] [patch 0/2] SPL: Lightweight UBI and UBI fastmap support > http://lists.denx.de/pipermail/u-boot/2014-July/183167.html > http://lists.denx.de/pipermail/u-boot/2014-July/183166.html > http://lists.denx.de/pipermail/u-boot/2014-July/183168.html > > Its about < 7k > > I did not found the time yet, looking into it, but it would be nice > to have ;-) > Cool, thanks for sharing on this. It's always nice to have full features implementation for powerful usertogether with light weight implementation when boot time is concern. Thanks Chin Liang > bye, > Heiko > > > > > > > > I hope Chin Liang can chime here, I know that we have support > > > > for > > > > NAND, > > > > but I haven't been part of that task, so I don't know how it's > > > > being > > > > done. > > > > > > Finally my email is back online :) > > > > > > We do have NAND support but not with UBI and UBIFS. > > > > I just hope you're not using raw NAND and just hoping it will work. > > > > > For this support, user can use U-Boot to load arbitrarily-sized U > > > -Boot > > > that run on SDRAM. > > > > > > One of the nice thing of U-Boot over SPL is the console support > > > and > > > ability to troubleshoot. > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > > vs CV > > > SoC 64kB). > > > > OK, that's not really the point here -- the point is, if you > > compile enough > > features into U-Boot, it will be bigger than those 256k. What will > > you do > > then ? > > > > Best regards, > > Marek Vasut > > _______________________________________________ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > >
Hello Marek, Chin Liang See, Sorry for digging so late into this topic ... Am 24.11.2015 um 10:31 schrieb Marek Vasut: > On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote: >> On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote: >>> On 11/23/2015 05:20 PM, Marek Vasut wrote: >>>> On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen wrote: >>>>> On 11/23/2015 05:03 PM, Marek Vasut wrote: >>>>>> On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen wrote: >>>>>>> On 11/23/2015 04:46 PM, Marek Vasut wrote: >>>>>>>> On Monday, November 23, 2015 at 11:32:27 PM, Dinh Nguyen >>>>>>>> wrote: >>>>>>>> [...] >>>>>>>> >>>>>>>>>>>>> The main point is that we need to program the >>>>>>>>>>>>> FPGA >>>>>>>>>>>>> during U-Boot booting up with a ~>10 MB rbf file >>>>>>>>>>>>> while being >>>>>>>>>>>>> limited to the OCRAM's size. I would like to >>>>>>>>>>>>> contain this >>>>>>>>>>>>> ugliness in it's own directory. >>>>>>>>>>>> >>>>>>>>>>>> What's the problem with this ? We already support >>>>>>>>>>>> loading files >>>>>>>>>>>> from storage in SPL, so just compile the FPGA >>>>>>>>>>>> manager into SPL as >>>>>>>>>>>> well and use it. >>>>>>>>>>> >>>>>>>>>>> Ok, let me re-work it all under the c5/a5 directory. >>>>>>>>>>> Thanks for >>>>>>>>>>> reviewing. >>>>>>>>>> >>>>>>>>>> But you didn't really answer my question -- what is the >>>>>>>>>> problem with >>>>>>>>>> the FPGA loader in SPL ? >>>>>>>>> >>>>>>>>> I thought you've already answered your own question. For >>>>>>>>> whatever >>>>>>>>> reason, the downstream A10 is re-doing the FPGA manager >>>>>>>>> just for this >>>>>>>>> purpose. >>>>>>>> >>>>>>>> Could the reason be that the FPGA manager in it's current >>>>>>>> state expects >>>>>>>> one big buffer with the entire FPGA bitstream ? When you're >>>>>>>> in SPL and >>>>>>>> you still don't have DRAM running, you cannot create such >>>>>>>> buffer >>>>>>>> anywhere. Thus, what you need to do is to have some sort of >>>>>>>> code which >>>>>>>> loads a bit of the bitstream file at time and feeds it into >>>>>>>> the FPGA >>>>>>>> manager, piece by piece. This should be doable pretty >>>>>>>> easily, what do >>>>>>>> you think ? >>>>>>> >>>>>>> That's exactly what is being in the mach-socfpga directory. >>>>>> >>>>>> Um, am I missing it in this patchset ? >>>>> >>>>> No, you're not missing it, I have not sent it up yet. That >>>>> support is in >>>>> the downstream, but also with the fpga-manager driver re-written. >>>>> I need >>>>> to clean this up before I can send it. >>>> >>>> OK, thanks :) >>>> >>>>>>> Yes, but should that code go into mach-socfpga or drivers? >>>>>> >>>>>> The FPGA manager bits are already in drivers/fpga/ , so that's >>>>>> where the >>>>>> improvements should go. If you need some special handling in >>>>>> the SPL, >>>>>> that should be in mach-socfpga . In case it's too much change >>>>>> to the >>>>>> current SPL, moving the spl.c to spl-gen5.c and creating new >>>>>> spl-gen10.c >>>>>> might make sense ... or something like that, possibly even with >>>>>> some >>>>>> spl-common.c . >>>>> >>>>> Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that U >>>>> -Boot can >>>>> use to setup the SDRAM. >>>> >>>> So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS >>>> won't >>>> fit into 256kiB, so I think using SPL might be the sensible thing >>>> afterall, >>>> since you would be able to use arbitrarily-sized U-Boot. Maybe you can try: [U-Boot] [patch 0/2] SPL: Lightweight UBI and UBI fastmap support http://lists.denx.de/pipermail/u-boot/2014-July/183167.html http://lists.denx.de/pipermail/u-boot/2014-July/183166.html http://lists.denx.de/pipermail/u-boot/2014-July/183168.html Its about < 7k I did not found the time yet, looking into it, but it would be nice to have ;-) bye, Heiko >>> >>> I hope Chin Liang can chime here, I know that we have support for >>> NAND, >>> but I haven't been part of that task, so I don't know how it's being >>> done. >> >> Finally my email is back online :) >> >> We do have NAND support but not with UBI and UBIFS. > > I just hope you're not using raw NAND and just hoping it will work. > >> For this support, user can use U-Boot to load arbitrarily-sized U-Boot >> that run on SDRAM. >> >> One of the nice thing of U-Boot over SPL is the console support and >> ability to troubleshoot. >> This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV >> SoC 64kB). > > OK, that's not really the point here -- the point is, if you compile enough > features into U-Boot, it will be bigger than those 256k. What will you do > then ? > > Best regards, > Marek Vasut > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot >
Hi Heiko, On Tue, 2015-11-24 at 13:29 +0100, Heiko Schocher wrote: > Hello Marek, Chin Liang See, > > Sorry for digging so late into this topic ... No worries as inputs are welcome any time. > > Am 24.11.2015 um 10:31 schrieb Marek Vasut: > > On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote: > > > On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote: > > > > On 11/23/2015 05:20 PM, Marek Vasut wrote: > > > > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen > > > > > wrote: > > > > > > On 11/23/2015 05:03 PM, Marek Vasut wrote: > > > > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen > > > > > > > wrote: > > > > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote: > > > > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh > > > > > > > > > Nguyen > > > > > > > > > wrote: > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > The main point is that we need to program > > > > > > > > > > > > > > the > > > > > > > > > > > > > > FPGA > > > > > > > > > > > > > > during U-Boot booting up with a ~>10 MB rbf > > > > > > > > > > > > > > file > > > > > > > > > > > > > > while being > > > > > > > > > > > > > > limited to the OCRAM's size. I would like > > > > > > > > > > > > > > to > > > > > > > > > > > > > > contain this > > > > > > > > > > > > > > ugliness in it's own directory. > > > > > > > > > > > > > > > > > > > > > > > > > > What's the problem with this ? We already > > > > > > > > > > > > > support > > > > > > > > > > > > > loading files > > > > > > > > > > > > > from storage in SPL, so just compile the FPGA > > > > > > > > > > > > > manager into SPL as > > > > > > > > > > > > > well and use it. > > > > > > > > > > > > > > > > > > > > > > > > Ok, let me re-work it all under the c5/a5 > > > > > > > > > > > > directory. > > > > > > > > > > > > Thanks for > > > > > > > > > > > > reviewing. > > > > > > > > > > > > > > > > > > > > > > But you didn't really answer my question -- what > > > > > > > > > > > is the > > > > > > > > > > > problem with > > > > > > > > > > > the FPGA loader in SPL ? > > > > > > > > > > > > > > > > > > > > I thought you've already answered your own > > > > > > > > > > question. For > > > > > > > > > > whatever > > > > > > > > > > reason, the downstream A10 is re-doing the FPGA > > > > > > > > > > manager > > > > > > > > > > just for this > > > > > > > > > > purpose. > > > > > > > > > > > > > > > > > > Could the reason be that the FPGA manager in it's > > > > > > > > > current > > > > > > > > > state expects > > > > > > > > > one big buffer with the entire FPGA bitstream ? When > > > > > > > > > you're > > > > > > > > > in SPL and > > > > > > > > > you still don't have DRAM running, you cannot create > > > > > > > > > such > > > > > > > > > buffer > > > > > > > > > anywhere. Thus, what you need to do is to have some > > > > > > > > > sort of > > > > > > > > > code which > > > > > > > > > loads a bit of the bitstream file at time and feeds > > > > > > > > > it into > > > > > > > > > the FPGA > > > > > > > > > manager, piece by piece. This should be doable pretty > > > > > > > > > easily, what do > > > > > > > > > you think ? > > > > > > > > > > > > > > > > That's exactly what is being in the mach-socfpga > > > > > > > > directory. > > > > > > > > > > > > > > Um, am I missing it in this patchset ? > > > > > > > > > > > > No, you're not missing it, I have not sent it up yet. That > > > > > > support is in > > > > > > the downstream, but also with the fpga-manager driver re > > > > > > -written. > > > > > > I need > > > > > > to clean this up before I can send it. > > > > > > > > > > OK, thanks :) > > > > > > > > > > > > > Yes, but should that code go into mach-socfpga or > > > > > > > > drivers? > > > > > > > > > > > > > > The FPGA manager bits are already in drivers/fpga/ , so > > > > > > > that's > > > > > > > where the > > > > > > > improvements should go. If you need some special handling > > > > > > > in > > > > > > > the SPL, > > > > > > > that should be in mach-socfpga . In case it's too much > > > > > > > change > > > > > > > to the > > > > > > > current SPL, moving the spl.c to spl-gen5.c and creating > > > > > > > new > > > > > > > spl-gen10.c > > > > > > > might make sense ... or something like that, possibly > > > > > > > even with > > > > > > > some > > > > > > > spl-common.c . > > > > > > > > > > > > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM > > > > > > that U > > > > > > -Boot can > > > > > > use to setup the SDRAM. > > > > > > > > > > So what do I do if I want to boot arria10 from NAND ? UBI and > > > > > UBIFS > > > > > won't > > > > > fit into 256kiB, so I think using SPL might be the sensible > > > > > thing > > > > > afterall, > > > > > since you would be able to use arbitrarily-sized U-Boot. > > > Maybe you can try: > [U-Boot] [patch 0/2] SPL: Lightweight UBI and UBI fastmap support > http://lists.denx.de/pipermail/u-boot/2014-July/183167.html > http://lists.denx.de/pipermail/u-boot/2014-July/183166.html > http://lists.denx.de/pipermail/u-boot/2014-July/183168.html > > Its about < 7k > > I did not found the time yet, looking into it, but it would be nice > to have ;-) > > bye, > Heiko Cool, thanks for sharing on this. It's always nice to have full features implementation for powerful usertogether with light weight implementation when boot time is concern. Thanks Chin Liang > > > > I hope Chin Liang can chime here, I know that we have support > > > > for > > > > NAND, > > > > but I haven't been part of that task, so I don't know how it's > > > > being > > > > done. > > > > > > Finally my email is back online :) > > > > > > We do have NAND support but not with UBI and UBIFS. > > > > I just hope you're not using raw NAND and just hoping it will work. > > > > > For this support, user can use U-Boot to load arbitrarily-sized U > > > -Boot > > > that run on SDRAM. > > > > > > One of the nice thing of U-Boot over SPL is the console support > > > and > > > ability to troubleshoot. > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > > vs CV > > > SoC 64kB). > > > > OK, that's not really the point here -- the point is, if you > > compile enough > > features into U-Boot, it will be bigger than those 256k. What will > > you do > > then ? > > > > Best regards, > > Marek Vasut > > _______________________________________________ > > U-Boot mailing list > > U-Boot@lists.denx.de > > http://lists.denx.de/mailman/listinfo/u-boot > > >
Hi! > > > > So what do I do if I want to boot arria10 from NAND ? UBI and UBIFS > > > > won't > > > > fit into 256kiB, so I think using SPL might be the sensible thing > > > > afterall, > > > > since you would be able to use arbitrarily-sized U-Boot. > > > > > > I hope Chin Liang can chime here, I know that we have support for > > > NAND, > > > but I haven't been part of that task, so I don't know how it's being > > > done. > > > > Finally my email is back online :) > > > > We do have NAND support but not with UBI and UBIFS. > > I just hope you're not using raw NAND and just hoping it will work. HERE: > > For this support, user can use U-Boot to load arbitrarily-sized U-Boot > > that run on SDRAM. ... > > One of the nice thing of U-Boot over SPL is the console support and > > ability to troubleshoot. > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB vs CV > > SoC 64kB). > > OK, that's not really the point here -- the point is, if you compile enough > features into U-Boot, it will be bigger than those 256k. What will you do > then ? You'll compile small U-Boot, and use it to load larger U-Boot, as he said in the mark "HERE" above. And yes, I guess that makes sense, and yes, we should finally make loading U-Boot from U-Boot oficially supported, at least on Socfpga. Pavel
Hi Marek, On Tue, 2015-11-24 at 10:31 +0100, Marek Vasut wrote: > On Tuesday, November 24, 2015 at 04:17:34 AM, Chin Liang See wrote: > > On Mon, 2015-11-23 at 17:25 -0600, Dinh Nguyen wrote: > > > On 11/23/2015 05:20 PM, Marek Vasut wrote: > > > > On Tuesday, November 24, 2015 at 12:04:10 AM, Dinh Nguyen > > > > wrote: > > > > > On 11/23/2015 05:03 PM, Marek Vasut wrote: > > > > > > On Monday, November 23, 2015 at 11:50:15 PM, Dinh Nguyen > > > > > > wrote: > > > > > > > On 11/23/2015 04:46 PM, Marek Vasut wrote: > > > > > > > > On Monday, November 23, 2015 at 11:32:27 PM, Dinh > > > > > > > > Nguyen > > > > > > > > wrote: > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > The main point is that we need to program the > > > > > > > > > > > > > FPGA > > > > > > > > > > > > > during U-Boot booting up with a ~>10 MB rbf > > > > > > > > > > > > > file > > > > > > > > > > > > > while being > > > > > > > > > > > > > limited to the OCRAM's size. I would like to > > > > > > > > > > > > > contain this > > > > > > > > > > > > > ugliness in it's own directory. > > > > > > > > > > > > > > > > > > > > > > > > What's the problem with this ? We already > > > > > > > > > > > > support > > > > > > > > > > > > loading files > > > > > > > > > > > > from storage in SPL, so just compile the FPGA > > > > > > > > > > > > manager into SPL as > > > > > > > > > > > > well and use it. > > > > > > > > > > > > > > > > > > > > > > Ok, let me re-work it all under the c5/a5 > > > > > > > > > > > directory. > > > > > > > > > > > Thanks for > > > > > > > > > > > reviewing. > > > > > > > > > > > > > > > > > > > > But you didn't really answer my question -- what is > > > > > > > > > > the > > > > > > > > > > problem with > > > > > > > > > > the FPGA loader in SPL ? > > > > > > > > > > > > > > > > > > I thought you've already answered your own question. > > > > > > > > > For > > > > > > > > > whatever > > > > > > > > > reason, the downstream A10 is re-doing the FPGA > > > > > > > > > manager > > > > > > > > > just for this > > > > > > > > > purpose. > > > > > > > > > > > > > > > > Could the reason be that the FPGA manager in it's > > > > > > > > current > > > > > > > > state expects > > > > > > > > one big buffer with the entire FPGA bitstream ? When > > > > > > > > you're > > > > > > > > in SPL and > > > > > > > > you still don't have DRAM running, you cannot create > > > > > > > > such > > > > > > > > buffer > > > > > > > > anywhere. Thus, what you need to do is to have some > > > > > > > > sort of > > > > > > > > code which > > > > > > > > loads a bit of the bitstream file at time and feeds it > > > > > > > > into > > > > > > > > the FPGA > > > > > > > > manager, piece by piece. This should be doable pretty > > > > > > > > easily, what do > > > > > > > > you think ? > > > > > > > > > > > > > > That's exactly what is being in the mach-socfpga > > > > > > > directory. > > > > > > > > > > > > Um, am I missing it in this patchset ? > > > > > > > > > > No, you're not missing it, I have not sent it up yet. That > > > > > support is in > > > > > the downstream, but also with the fpga-manager driver re > > > > > -written. > > > > > I need > > > > > to clean this up before I can send it. > > > > > > > > OK, thanks :) > > > > > > > > > > > Yes, but should that code go into mach-socfpga or > > > > > > > drivers? > > > > > > > > > > > > The FPGA manager bits are already in drivers/fpga/ , so > > > > > > that's > > > > > > where the > > > > > > improvements should go. If you need some special handling > > > > > > in > > > > > > the SPL, > > > > > > that should be in mach-socfpga . In case it's too much > > > > > > change > > > > > > to the > > > > > > current SPL, moving the spl.c to spl-gen5.c and creating > > > > > > new > > > > > > spl-gen10.c > > > > > > might make sense ... or something like that, possibly even > > > > > > with > > > > > > some > > > > > > spl-common.c . > > > > > > > > > > Ok. BTW, Arria10 is not using SPL. It has 256K of OCRAM that > > > > > U > > > > > -Boot can > > > > > use to setup the SDRAM. > > > > > > > > So what do I do if I want to boot arria10 from NAND ? UBI and > > > > UBIFS > > > > won't > > > > fit into 256kiB, so I think using SPL might be the sensible > > > > thing > > > > afterall, > > > > since you would be able to use arbitrarily-sized U-Boot. > > > > > > I hope Chin Liang can chime here, I know that we have support for > > > NAND, > > > but I haven't been part of that task, so I don't know how it's > > > being > > > done. > > > > Finally my email is back online :) > > > > We do have NAND support but not with UBI and UBIFS. > > I just hope you're not using raw NAND and just hoping it will work. > > > For this support, user can use U-Boot to load arbitrarily-sized U > > -Boot > > that run on SDRAM. > > > > One of the nice thing of U-Boot over SPL is the console support and > > ability to troubleshoot. > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > vs CV > > SoC 64kB). > > OK, that's not really the point here -- the point is, if you compile > enough > features into U-Boot, it will be bigger than those 256k. What will > you do > then ? For this case, we will have 4 boot stages where a minimal U-Boot that run on OCRAM to load a larger U-Boot which will run on SDRAM. For better explanation, here are the events for this 4 boot stages. 1. BootROM load minimal U-Boot to OCRAM 2. Minimal U-Boot initialize all the critical HW such as clocks, DDR 3. Minimal U-Boot load larger U-Boot to SDRAM 4. Larger U-Boot will then load Linux 5. Linux boot Thanks Chin Liang > > Best regards, > Marek Vasut
Hi Pavel, On Tue, 2015-11-24 at 14:31 +0100, Pavel Machek wrote: > Hi! > > > > > > So what do I do if I want to boot arria10 from NAND ? UBI and > > > > > UBIFS > > > > > won't > > > > > fit into 256kiB, so I think using SPL might be the sensible > > > > > thing > > > > > afterall, > > > > > since you would be able to use arbitrarily-sized U-Boot. > > > > > > > > I hope Chin Liang can chime here, I know that we have support > > > > for > > > > NAND, > > > > but I haven't been part of that task, so I don't know how it's > > > > being > > > > done. > > > > > > Finally my email is back online :) > > > > > > We do have NAND support but not with UBI and UBIFS. > > > > I just hope you're not using raw NAND and just hoping it will work. > > HERE: > > > > For this support, user can use U-Boot to load arbitrarily-sized U > > > -Boot > > > that run on SDRAM. > > ... > > > > One of the nice thing of U-Boot over SPL is the console support > > > and > > > ability to troubleshoot. > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > > vs CV > > > SoC 64kB). > > > > OK, that's not really the point here -- the point is, if you > > compile enough > > features into U-Boot, it will be bigger than those 256k. What will > > you do > > then ? > > You'll compile small U-Boot, and use it to load larger U-Boot, as he > said in the mark "HERE" above. > > And yes, I guess that makes sense, and yes, we should finally make > loading U-Boot from U-Boot oficially supported, at least on Socfpga. > Yup, you got it :) Thanks Chin Liang > > Pavel
On Tuesday, November 24, 2015 at 02:36:13 PM, Chin Liang See wrote: > Hi Pavel, > > On Tue, 2015-11-24 at 14:31 +0100, Pavel Machek wrote: > > Hi! > > > > > > > > So what do I do if I want to boot arria10 from NAND ? UBI and > > > > > > UBIFS > > > > > > won't > > > > > > fit into 256kiB, so I think using SPL might be the sensible > > > > > > thing > > > > > > afterall, > > > > > > since you would be able to use arbitrarily-sized U-Boot. > > > > > > > > > > I hope Chin Liang can chime here, I know that we have support > > > > > for > > > > > NAND, > > > > > but I haven't been part of that task, so I don't know how it's > > > > > being > > > > > done. > > > > > > > > Finally my email is back online :) > > > > > > > > We do have NAND support but not with UBI and UBIFS. > > > > > > I just hope you're not using raw NAND and just hoping it will work. > > > > HERE: > > > > For this support, user can use U-Boot to load arbitrarily-sized U > > > > -Boot > > > > that run on SDRAM. > > > > ... > > > > > > One of the nice thing of U-Boot over SPL is the console support > > > > and > > > > ability to troubleshoot. > > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > > > vs CV > > > > SoC 64kB). > > > > > > OK, that's not really the point here -- the point is, if you > > > compile enough > > > features into U-Boot, it will be bigger than those 256k. What will > > > you do > > > then ? > > > > You'll compile small U-Boot, and use it to load larger U-Boot, as he > > said in the mark "HERE" above. > > > > And yes, I guess that makes sense, and yes, we should finally make > > loading U-Boot from U-Boot oficially supported, at least on Socfpga. > > Yup, you got it :) > Thanks So why exactly don't we use SPL instead ? The purpose of SPL is to do exactly this without the extra cruft which is part of U-Boot and the unnecessary overhead of the full U-Boot. And you don't need to hack U-Boot to support loading U-Boot. Best regards, Marek Vasut
On Tuesday, November 24, 2015 at 02:34:11 PM, Chin Liang See wrote: > Hi Marek, [...] > > > For this support, user can use U-Boot to load arbitrarily-sized U > > > -Boot > > > that run on SDRAM. > > > > > > One of the nice thing of U-Boot over SPL is the console support and > > > ability to troubleshoot. > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > > vs CV > > > SoC 64kB). > > > > OK, that's not really the point here -- the point is, if you compile > > enough > > features into U-Boot, it will be bigger than those 256k. What will > > you do > > then ? > > For this case, we will have 4 boot stages where a minimal U-Boot that > run on OCRAM to load a larger U-Boot which will run on SDRAM. For > better explanation, here are the events for this 4 boot stages. > > 1. BootROM load minimal U-Boot to OCRAM > 2. Minimal U-Boot initialize all the critical HW such as clocks, DDR > 3. Minimal U-Boot load larger U-Boot to SDRAM > 4. Larger U-Boot will then load Linux > 5. Linux boot Well replace the "minimal U-Boot" with SPL, that should be much simpler task to implement. Best regards, Marek Vasut
Hi! > > > > > One of the nice thing of U-Boot over SPL is the console support > > > > > and > > > > > ability to troubleshoot. > > > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > > > > vs CV > > > > > SoC 64kB). > > > > > > > > OK, that's not really the point here -- the point is, if you > > > > compile enough > > > > features into U-Boot, it will be bigger than those 256k. What will > > > > you do > > > > then ? > > > > > > You'll compile small U-Boot, and use it to load larger U-Boot, as he > > > said in the mark "HERE" above. > > > > > > And yes, I guess that makes sense, and yes, we should finally make > > > loading U-Boot from U-Boot oficially supported, at least on Socfpga. > > > > Yup, you got it :) > > Thanks > > So why exactly don't we use SPL instead ? The purpose of SPL is to do exactly > this without the extra cruft which is part of U-Boot and the unnecessary > overhead of the full U-Boot. And you don't need to hack U-Boot to support > loading U-Boot. You don't need to hack anything, it just works today. And yes, U-Boot is easier to work with, because it has commandline, etc. In ideal world, U-Boot SPL would disappear. You'd just compile small "U-Boot 1" and bigger "U-Boot 2". Lets get there... No need for arbitrary limitations like "Full U-Boot can't initialize sdram" or "U-Boot SPL can't have command line". Pavel
On Tuesday, November 24, 2015 at 03:01:09 PM, Pavel Machek wrote: > Hi! Hi! > > > > > > One of the nice thing of U-Boot over SPL is the console support > > > > > > and > > > > > > ability to troubleshoot. > > > > > > This is possible with Arria 10 SoC as we have larger OCRAM (256kB > > > > > > vs CV > > > > > > SoC 64kB). > > > > > > > > > > OK, that's not really the point here -- the point is, if you > > > > > compile enough > > > > > features into U-Boot, it will be bigger than those 256k. What will > > > > > you do > > > > > then ? > > > > > > > > You'll compile small U-Boot, and use it to load larger U-Boot, as he > > > > said in the mark "HERE" above. > > > > > > > > And yes, I guess that makes sense, and yes, we should finally make > > > > loading U-Boot from U-Boot oficially supported, at least on Socfpga. > > > > > > Yup, you got it :) > > > Thanks > > > > So why exactly don't we use SPL instead ? The purpose of SPL is to do > > exactly this without the extra cruft which is part of U-Boot and the > > unnecessary overhead of the full U-Boot. And you don't need to hack > > U-Boot to support loading U-Boot. > > You don't need to hack anything, it just works today. > > And yes, U-Boot is easier to work with, because it has commandline, > etc. I do not necessarily need this overhead. > In ideal world, U-Boot SPL would disappear. You'd just compile small > "U-Boot 1" and bigger "U-Boot 2". Lets get there... No need for > arbitrary limitations like "Full U-Boot can't initialize sdram" or > "U-Boot SPL can't have command line". This can be done by converging SPL to normal U-Boot, but that's not gonna happen instantaneously. Best regards, Marek Vasut
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 --- a/arch/arm/mach-socfpga/Makefile +++ b/arch/arm/mach-socfpga/Makefile @@ -6,15 +6,18 @@ # # SPDX-License-Identifier: GPL-2.0+ # - +ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y) obj-y += misc.o timer.o reset_manager.o system_manager.o clock_manager.o \ fpga_manager.o scan_manager.o obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o - # QTS-generated config file wrappers obj-y += wrap_pll_config.o obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \ wrap_sdram_config.o +else +obj-y += arria10/ +endif + CFLAGS_wrap_iocsr_config.o += -I$(srctree)/board/$(BOARDDIR) CFLAGS_wrap_pinmux_config.o += -I$(srctree)/board/$(BOARDDIR) CFLAGS_wrap_pll_config.o += -I$(srctree)/board/$(BOARDDIR) diff --git a/arch/arm/mach-socfpga/arria10/Makefile b/arch/arm/mach-socfpga/arria10/Makefile new file mode 100644 index 0000000..f5e4b7d --- /dev/null +++ b/arch/arm/mach-socfpga/arria10/Makefile @@ -0,0 +1,7 @@ +# +# Copyright (C) 2015 Altera Corporation <www.altera.com> +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := misc_a10.o reset_manager_a10.o sdram_a10.o