> From: Grant Likely > Sent: Monday, June 27, 2011 3:24 PM > > Our AMPs (remote processors) have a variety of boot mechanisms that vary > > across the different SoCs (yes, TI likes HW diversity). In some cases, the > > boot address is more like an entry point and that comes from the firmware, > > so it is not a static attribute of a driver. Correct me if I misunderstood > > your question. > > More to the point, I would expect the boot_address to be a property of > the rproc instance because it represents the configuration of the > remote processor. It seems odd that the caller of ->start would know > better than the rproc driver about the entry point of the processor. > > g. Yes, in many cases the boot_address will be defined by the HW. However, we have processors that are "soft" - the boot_address comes from the particular firmware being loaded and can (will) be different with each firmware image. We factored out the firmware loader to be device-independent (in remoteproc.c) so it's not repeated in each device-specific implementation like omap_remoteproc.c and davinci_remoteproc.c. In the cases where the HW dictates what happens, the start() method should just ignore the boot_address. Mark -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
