On Tue, Jan 26, 2016 at 10:58:47AM +0800, Peng Fan wrote: > On Mon, Jan 25, 2016 at 09:45:47PM -0500, Tom Rini wrote: > >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 > > Oh. Thanks for explanation. > > >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. > > Yeah. I mean not embedded dtb into SPL/U-Boot, just let it be sperate file.
Can you explain how this would work, or the use case for it? We can't always assume we're reading u-boot.img off FAT for example. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot