From: Chee, Tien Fong <tien.fong.chee@intel.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 09/19] arm: socfpga: Add drivers for programing FPGA from flash
Date: Thu, 28 Sep 2017 15:14:09 +0000 [thread overview]
Message-ID: <1506611647.3589.70.camel@intel.com> (raw)
In-Reply-To: <f3aa8bfb-0439-8b2d-1929-a73ef3deefd8@denx.de>
On Rab, 2017-09-27 at 11:23 +0200, Marek Vasut wrote:
> On 09/27/2017 11:13 AM, Chee, Tien Fong wrote:
> >
> > On Sel, 2017-09-26 at 12:39 +0200, Marek Vasut wrote:
> > >
> > > On 09/26/2017 11:52 AM, Chee, Tien Fong wrote:
> > > >
> > > >
> > > > On Isn, 2017-09-25 at 11:14 +0200, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 09/25/2017 10:40 AM, tien.fong.chee at intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Tien Fong Chee <tien.fong.chee@intel.com>
> > > > > >
> > > > > > These drivers handle FPGA program operation from flash
> > > > > > loading
> > > > > > RBF to memory and then to program FPGA.
> > > > > >
> > > > > > Signed-off-by: Tien Fong Chee <tien.fong.chee@intel.com>
> > > [...]
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > +const char *get_cff_devpart(const void *fdt, int *len)
> > > > > > +{
> > > > > > + const char *cff_devpart = NULL;
> > > > > > + const char *cell;
> > > > > > + int nodeoffset;
> > > > > > + nodeoffset = fdtdec_next_compatible(fdt, 0,
> > > > > > + COMPAT_ALTERA_SOCFPGA_FPGA0);
> > > > > > +
> > > > > > + cell = fdt_getprop(fdt, nodeoffset,
> > > > > > "bitstream_devpart",
> > > > > > len);
> > > > > > +
> > > > > > + if (cell)
> > > > > > + cff_devpart = cell;
> > > > > > +
> > > > > > + return cff_devpart;
> > > > > > +}
> > > > > Take a look at splash*.c , I believe that can be reworked
> > > > > into
> > > > > generic
> > > > > firmware loader , which you could then use here.
> > > > >
> > > > the devpart is hard coded in splash*.c. The function here is
> > > > getting
> > > > devpart info from DTS. So, is there any similar function in
> > > > splash*.c?
> > > > May be you can share more about your idea.
> > > The generic loader could use some work of course ...
> > >
> > Sorry, i am still confusing. Allow me to ask you more:
> > 1. Is the generic firmware loader already exists in splash*.c?
> No
>
> >
> > 2. Are you talking about get_cff_devpart or whole fpga laodfs?
> > 3. You want me integrate get_cff_devpart function into splash*.c?
> > 4. Are you means to hard code the devpart instead providing dynamic
> > devpart described in DTS?
> I am talking about factoring out generic firmware loader from
> splash*c ,
> since it already contains most of the parts for such a thing.
>
> >
> > Current implementation are located in spl_board_init func
> > (arcg/arm/mach-socfpga/spl.c). Based on boot device such as mmc,
> > nand
> > and QSPI, then reading some info from DTS, setting dev and
> > partition
> > with generic fs functions, and reading with generic fs function
> > before
> > programming RBF into FPGA. All these are in patch 19.
> That's what splash*c also does, so adding separate parallel
> implementation of the same functionality is a no-no.
>
After reading through splash*c, i found there are two functions bear a
close similarity to.
1st function -->
In /common/splash.c :
static struct splash_location default_splash_locations[] = {
{
.name = "sf",
.storage = SPLASH_STORAGE_SF,
.flags = SPLASH_STORAGE_RAW,
.offset = 0x0,
},
{
.name = "mmc_fs",
.storage = SPLASH_STORAGE_MMC,
.flags = SPLASH_STORAGE_FS,
.devpart = "0:1",
},
{
.name = "usb_fs",
.storage = SPLASH_STORAGE_USB,
.flags = SPLASH_STORAGE_FS,
.devpart = "0:1",
},
{
.name = "sata_fs",
.storage = SPLASH_STORAGE_SATA,
.flags = SPLASH_STORAGE_FS,
.devpart = "0:1",
},
};
In my /arch/arm/mach-socfpga/spl.c (spl_board_init(void))
bootdev.boot_device = spl_boot_device();
if (BOOT_DEVICE_MMC1 == bootdev.boot_device) {
struct mmc *mmc = NULL;
int err = 0;
spl_mmc_find_device(&mmc, bootdev.boot_device);
err = mmc_init(mmc);
if (err) {
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf("spl: mmc init failed with error: %d\n",
err);
#endif
}
fpga_fsinfo.dev_part = (char *)get_cff_devpart(gd-
>fdt_blob,
&len);
fpga_fsinfo.filename = (char *)get_cff_filename(gd-
>fdt_blob,
&len,
PERIPH_
RBF);
fpga_fsinfo.interface = "mmc";
fpga_fsinfo.fstype = FS_TYPE_FAT;
} else {
printf("Invalid boot device!\n");
return;
}
/* Program peripheral RBF */
if (fpga_fsinfo.filename && fpga_fsinfo.dev_part && (len > 0))
rval = fpga_fsload(0, buffer, BSIZE, &fpga_fsinfo);
In /common/splash.c, dev_Part and flash type everything are hard coded
in struct splash_location. In my spl.c, flash type are determined on
run time and dev_part are retrived from DTS, and then assigned to
struct fpga_fsinfo. Please note that this is in SPL, mmc need to be
initialized 1st before loading raw file into memory. In SPL, raw file
are coppied to OCRAM chunk by chunk, but In u-boot it would normally
done in one big chunk to DRAM. This would be handled by fpga loadfs.
So, you want me hard code everthing like in splash.c?
2nd function -->
In /common/splash_source.c
static int splash_select_fs_dev(struct splash_location *location)
{
int res;
switch (location->storage) {
case SPLASH_STORAGE_MMC:
res = fs_set_blk_dev("mmc", location->devpart,
FS_TYPE_ANY);
break;
case SPLASH_STORAGE_USB:
res = fs_set_blk_dev("usb", location->devpart,
FS_TYPE_ANY);
break;
case SPLASH_STORAGE_SATA:
res = fs_set_blk_dev("sata", location->devpart,
FS_TYPE_ANY);
break;
case SPLASH_STORAGE_NAND:
if (location->ubivol != NULL)
res = fs_set_blk_dev("ubi", NULL,
FS_TYPE_UBIFS);
else
res = -ENODEV;
break;
default:
printf("Error: unsupported location storage.\n");
return -ENODEV;
}
if (res)
printf("Error: could not access storage.\n");
return res;
}
In my /drivers/fpga/socfpga_arria10.c
static int flash_read(struct flash_info *flashinfo,
u32 size_read,
u32 *buffer_ptr)
{
size_t ret = EEXIST;
loff_t actread = 0;
if (fs_set_blk_dev(flashinfo->interface, flashinfo->dev_part,
flashinfo->fstype))
return FPGA_FAIL;
ret = fs_read(flashinfo->filename,
(u32) buffer_ptr, flashinfo->flash_offset,
size_read, &actread);
if (ret || actread != size_read) {
printf("Failed to read %s from flash %d ",
flashinfo->filename,
ret);
printf("!= %d.\n", size_read);
return -EPERM;
} else
ret = actread;
return ret;
}
Some attributes like flash type is determined on run time and and
dev_part is retrieved from DTS, so every infos driver need to know are
assinged into struct flashinfo and passed to fs_set_blk_dev as
arguments. I found that function in splash_source.c some like flash
type are getting from env variable, but we are still in SPL phase,
those env variable is not set up yet. So, i think that is very
ineffcient to factor out them as common.
If you want me create a generic firmware loader which is generic enough
loading content for all components like flashes, FPGA, splash ....etc,
i don't think that is effient enough, as fpga loadfs has different
handling in both SPL and U-boot like copying raw into memory.
It would be good you can direct point me out which functions have
similirity and how to factor them out as common.
Thanks a lot.
> >
> > Thanks.
> > >
> > > [...]
>
next prev parent reply other threads:[~2017-09-28 15:14 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-25 8:39 [U-Boot] [PATCH v2 00/19] Add FPGA, SDRAM, SPL loads U-boot & booting to console tien.fong.chee at intel.com
2017-09-25 8:39 ` [U-Boot] [PATCH v2 01/19] ARM: socfpga: add bindings doc for arria10 fpga manager tien.fong.chee at intel.com
2017-09-25 8:59 ` Marek Vasut
2017-09-25 8:39 ` [U-Boot] [PATCH v2 02/19] doc: dtbinding: Description on FPGA RBF properties at Arria 10 FPGA manager tien.fong.chee at intel.com
2017-09-25 9:00 ` Marek Vasut
2017-09-26 8:54 ` Chee, Tien Fong
2017-09-26 10:30 ` Marek Vasut
2017-09-27 3:12 ` Chee, Tien Fong
2017-09-27 8:29 ` Marek Vasut
2017-09-28 2:49 ` Chee, Tien Fong
2017-09-25 9:01 ` Marek Vasut
2017-09-26 8:32 ` Chee, Tien Fong
2017-09-25 8:39 ` [U-Boot] [PATCH v2 03/19] dts: Add FPGA bitstream properties to Arria 10 DTS tien.fong.chee at intel.com
2017-09-25 8:40 ` [U-Boot] [PATCH v2 04/19] arm: socfpga: Add Arria 10 SoCFPGA programming interface tien.fong.chee at intel.com
2017-09-25 9:03 ` Marek Vasut
2017-09-29 7:42 ` Chee, Tien Fong
2017-09-25 8:40 ` [U-Boot] [PATCH v2 05/19] arm: socfpga: Enhance FPGA program write rbf data with size >= 4 bytes tien.fong.chee at intel.com
2017-09-25 9:08 ` Marek Vasut
2017-09-25 8:40 ` [U-Boot] [PATCH v2 06/19] dts: Enable fpga-mgr node build for Arria 10 SPL tien.fong.chee at intel.com
2017-09-25 8:40 ` [U-Boot] [PATCH v2 07/19] fdt: Add compatible strings for Arria 10 tien.fong.chee at intel.com
2017-09-25 9:08 ` Marek Vasut
2017-12-10 19:34 ` Simon Glass
2017-09-25 8:40 ` [U-Boot] [PATCH v2 08/19] fs: Enable generic filesystems interface support in SPL tien.fong.chee at intel.com
2017-09-25 9:09 ` Marek Vasut
2017-10-09 4:47 ` Simon Glass
2017-09-25 8:40 ` [U-Boot] [PATCH v2 09/19] arm: socfpga: Add drivers for programing FPGA from flash tien.fong.chee at intel.com
2017-09-25 9:14 ` Marek Vasut
2017-09-26 8:30 ` Chee, Tien Fong
2017-09-26 10:32 ` Marek Vasut
2017-09-27 6:05 ` Chee, Tien Fong
2017-09-27 8:30 ` Marek Vasut
2017-09-28 2:45 ` Chee, Tien Fong
2017-09-26 9:52 ` Chee, Tien Fong
2017-09-26 10:39 ` Marek Vasut
2017-09-27 9:13 ` Chee, Tien Fong
2017-09-27 9:23 ` Marek Vasut
2017-09-28 15:14 ` Chee, Tien Fong [this message]
2017-09-28 15:18 ` Marek Vasut
2017-10-09 4:47 ` Simon Glass
2017-09-25 8:40 ` [U-Boot] [PATCH v2 10/19] arm: socfpga: Rename the gen5 sdram driver to more specific name tien.fong.chee at intel.com
2017-09-25 9:15 ` Marek Vasut
2017-09-26 8:23 ` Chee, Tien Fong
2017-09-26 10:33 ` Marek Vasut
2017-09-27 5:06 ` Chee, Tien Fong
2017-09-25 8:40 ` [U-Boot] [PATCH v2 11/19] arm: socfpga: Add DRAM bank size initialization function tien.fong.chee at intel.com
2017-09-25 9:15 ` Marek Vasut
2017-09-26 8:20 ` Chee, Tien Fong
2017-09-26 10:33 ` Marek Vasut
2017-10-02 10:01 ` Chee, Tien Fong
2017-10-02 10:04 ` Marek Vasut
2017-10-02 10:06 ` Chee, Tien Fong
2017-10-03 3:30 ` Ley Foon Tan
2017-09-25 8:40 ` [U-Boot] [PATCH v2 12/19] arm: socfpga: Add DDR driver for Arria 10 tien.fong.chee at intel.com
2017-09-25 9:19 ` Marek Vasut
2017-09-26 8:20 ` Chee, Tien Fong
2017-09-26 10:35 ` Marek Vasut
2017-09-27 4:55 ` Chee, Tien Fong
2017-09-25 8:40 ` [U-Boot] [PATCH v2 13/19] configs: Add DDR Kconfig support " tien.fong.chee at intel.com
2017-09-25 8:40 ` [U-Boot] [PATCH v2 14/19] arm: socfpga: Enable build for DDR " tien.fong.chee at intel.com
2017-09-25 9:20 ` Marek Vasut
2017-09-26 5:06 ` Chee, Tien Fong
2017-09-25 8:40 ` [U-Boot] [PATCH v2 15/19] arm: socfpga: Add support to memory allocation in SPL tien.fong.chee at intel.com
2017-09-25 9:21 ` Marek Vasut
2017-09-26 5:06 ` Chee, Tien Fong
2017-09-26 10:37 ` Marek Vasut
2017-09-27 5:43 ` Chee, Tien Fong
2017-09-27 8:32 ` Marek Vasut
2017-09-28 2:48 ` Chee, Tien Fong
2017-09-25 8:40 ` [U-Boot] [PATCH v2 16/19] arm: socfpga: Enhance Intel SoCFPGA program header to support Arria 10 tien.fong.chee at intel.com
2017-09-25 9:23 ` Marek Vasut
2017-09-26 4:42 ` Chee, Tien Fong
2017-09-26 10:37 ` Marek Vasut
2017-09-27 3:30 ` Chee, Tien Fong
2017-09-27 8:33 ` Marek Vasut
2017-09-28 2:46 ` Chee, Tien Fong
2017-09-25 8:40 ` [U-Boot] [PATCH v2 17/19] arm: socfpga: Adding clock frequency info for U-boot tien.fong.chee at intel.com
2017-09-25 9:23 ` Marek Vasut
2017-09-26 4:32 ` Chee, Tien Fong
2017-09-27 3:24 ` Chee, Tien Fong
2017-10-02 10:04 ` Chee, Tien Fong
2017-10-02 10:10 ` Marek Vasut
2017-10-02 10:25 ` Chee, Tien Fong
2017-09-25 8:40 ` [U-Boot] [PATCH v2 18/19] arm: socfpga: Adding SoCFPGA info for both SPL and U-boot tien.fong.chee at intel.com
2017-09-25 8:40 ` [U-Boot] [PATCH v2 19/19] arm: socfpga: Enable SPL loading U-boot to DDR and booting U-boot tien.fong.chee at intel.com
2017-09-25 9:24 ` Marek Vasut
2017-09-26 4:31 ` Chee, Tien Fong
2017-09-26 10:38 ` Marek Vasut
2017-09-27 3:14 ` Chee, Tien Fong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1506611647.3589.70.camel@intel.com \
--to=tien.fong.chee@intel.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox