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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
