On Mon, 23 Mar 2015 16:15:56 -0500 Rivera Jose-B46482 <german.riv...@freescale.com> wrote:
> > -----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. ok, for that case, when time comes for u-boot to do some DPAA2 networking arrives (i.e., we shouldn't have to be loading firmware at board boot-time), then we should load a minimal DPL for the number of singular, non-virtual/switch, etc., interfaces for that board just to tftp: this shouldn't be a big DPL at all, and its time complexity is fixed. > > > 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? I see: there's a udelay(500) in mc_send_command(), which is too high, too, IMO, but I'm not that familiar with the h/w: How long does the shortest command take? > > > 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? Why waste 0.9ms of boot time when there's no need? It already takes the boards *way* too long to boot, and now I'm understanding mc_send_command's delay should probably be adjusted, too. > 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? I don't know MC h/w: what's the shortest boot time given a standard simple "DPL"?: A small fraction of that. Kim _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot