On Tue, Jan 26, 2016 at 09:55:43AM +0800, Peng Fan wrote: > Hi Simon, > > On Mon, Jan 25, 2016 at 06:11:24PM -0700, Simon Glass wrote: > >+Hans > > > >Hi Tom, > > > >On 21 January 2016 at 05:24, Tom Rini <tr...@konsulko.com> wrote: > >> On Wed, Jan 20, 2016 at 07:46:15PM -0700, Simon Glass wrote: > >>> +Mugunthan, Tom > >>> > >>> On 17 January 2016 at 03:56, Christophe Ricard > >>> <christophe.ric...@gmail.com> wrote: > >>> > Convert omap3_spi driver to DM and keep compatibility with previous > >>> > mode. > >>> > > >>> > Signed-off-by: Christophe Ricard <christophe-h.ric...@st.com> > >>> > --- > >>> > > >>> > drivers/spi/Kconfig | 6 + > >>> > drivers/spi/omap3_spi.c | 439 > >>> > ++++++++++++++++++++++++++++++++++++++++++------ > >>> > drivers/spi/omap3_spi.h | 14 +- > >>> > 3 files changed, 402 insertions(+), 57 deletions(-) > >>> > >>> This is a pretty painful conversion, with lots of #ifdefs. I think it > >>> would be possible to use a common pointer type and reduce this. > >>> > >>> But perhaps it does not matter - how long must we be in the state of > >>> supporting legacy SPI? Can we convert all TI boards to driver model? > >> > >> We _really_ need some way to support more than one board per binary > >> before we can move everything to DM only. > >> > >> I think we can kind of do this today if we stick to using platform data > >> for everything that's board-specific rather than SoC-defined. What we > >> talked about at ELCE was auto-generating the pdata from the device tree, > >> I think. > > > >We discussed this on IRC but since that doesn't exist as far as the > >mailing list is concerned... > > > >The current plan is: > > > >- Adjust build system to optionally build a u-boot.img in FIT format > >that includes the U-Boot binary and >1 device tree files > >- Adjust SPL to load this > >- Add a way for SPL to determine which device tree to select (by > >calling a board-specific function) > >- Have SPL pass this selected device tree to U-Boot when it starts > > Can dtb be sperated from the final u-boot.img, if using SPL? > I mean let SPL load the u-boot.img and the dtb to correct DRAM address. > And the dtb is shared with linux kernel.
This sounds similar, but different. The problem I'm asking to be solved is that at the starting point, there are no DTBs on the hardware. But we can in software easily and reliable tell which of say 3 boards we are on. At that point, we need to make sure that both SPL and then U-Boot know which board they are on. And if in U-Boot we use the DT to pass in all data, it has to be correct. It sounds to me like you're describing the case where the HW has the dtb stored at a known location and you just don't need it embedded within SPL/U-Boot. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
