> -----Original Message-----
> From: Kim Phillips [mailto:kim.phill...@freescale.com]
> Sent: Monday, March 23, 2015 3:34 PM
> To: Rivera Jose-B46482
> Cc: Sun York-R58495; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware
> loading for new boot architecture
>
> On Mon, 23 Mar 2015 15:06:11 -0500
> Rivera Jose-B46482 <german.riv...@freescale.com> wrote:
>
> > > From: Kim Phillips [mailto:kim.phill...@freescale.com]
> > > Sent: Thursday, March 19, 2015 12:53 PM
> > >
> > > On Thu, 19 Mar 2015 09:45:45 -0700
> > > York Sun <york...@freescale.com> wrote:
> > >
> > > > From: "J. German Rivera" <german.riv...@freescale.com>
> > > >
> > > > Changed MC firmware loading to comply with the new MC boot
> > > architecture.
> > > > Flush D-cache hierarchy after loading MC images. Add environment
> > > > variables "mcboottimeout" for MC boot timeout in milliseconds,
> > > > "mcmemsize" for MC DRAM block size. Check MC boot status before
> > > > calling flib functions.
> > >
> > > Can we just assign actual and/or optimal values for 'mcboottimeout'
> > > and 'mcmemsize' instead of making them environment variables?
> > >
> > Having environment variables gives us the flexibility if these values
> > need to be changed for a given customer configuration. The actual
>
> what defines a 'customer configuration,' and how does that manifest
> itself at u-boot boot time?
A DPL (data path layout - a device-tree-like structure describing
The DPAA2 objects created at boot time and their connections)
> Is it the amount of time it takes to load
> (and execute?) firmare?
Yes, bigger DPLs take longer to process by the MC.
> Why isn't customer-specific firmware being
> loaded via linux? All u-boot needs is basic networking, pretty static
> setup: fixed numbers for both memsize & timeout.
This is not customer-specific firmware. What is customer-specific is just the
DPL.
In order to have networking in u-boot, we need to load the MC firmware in
u-boot,
For cases in which the target system has only DPAA2-based network interfaces.
>
> > boot time of the MC and the amount of memory needed by the MC is
> > dependent on how big/complex is the DPL used. Also, the memory needed
> > by the MC needs to account for how much memory is needed for AIOP
> > programs, which may depend on how big/complex they are.
>
> ok, that helps (modulo not knowing what 'DPL' is), but still, the massive
> customer configurations should be being loaded via linux'
> firmware loading infrastructure: u-boot should be using a static image
> for u-boot's needs.
>
> > > > +static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
> > > > + u32 reg_gsr;
> > > > + u32 mc_fw_boot_status;
> > > > + unsigned long timeout_ms = get_mc_boot_timeout_ms();
> > > > + struct mc_ccsr_registers __iomem *mc_ccsr_regs =
> > > > +MC_CCSR_BASE_ADDR;
> > > > +
> > > > + dmb();
> > > > + debug("Polling mc_ccsr_regs->reg_gsr ...\n");
> > > > + assert(timeout_ms > 0);
> > > > + for (;;) {
> > > > + udelay(1000); /* throttle polling */
> > >
> > > does this really need to be a whole 1ms?
> >
> > It is unlikely that the MC fw will boot in less than 1 ms.
>
> is wait_for_mc() only called for the boot command, or all commands?
>
> > So, checking more frequently than 1 ms is not necessary.
>
> yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on
> this.
>
How significant is to save 0.9ms of the whole boot time?
As the comment in the code says, the intent was to throttle down the polling,
to reduce traffic on the system bus due to polling. This traffic competes with
the MC itself accessing the system bus, as it boots. Having the polling traffic
get
in the way of the MC traffic may increase the MC boot time. Too small delay
between polls may cause the MC boot time to increase more than the .9ms you
are concerned of wasting in the delay.
What value would you suggest to use for the delay instead 1000ms?
> Kim
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
