Hi Simon, Tom,
I assume the approach you are taking is also valuable for the i2c:
omap24xx patch serie:
http://lists.denx.de/pipermail/u-boot/2016-January/241676.html
What are your recommendation about the pending patches ?
Should i send back only the one not taking care of the DM conversion and
send another serie later ?
I have seen some work ongoing on this topic on the u-boot-fdt tree on
the spl-working branch.
Is there a more accurate place to follow this work ?
Best Regards
Christophe
On 26/01/2016 02:55, 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.
Regards,
Peng.
Thus we should be able to support more than one board with a single
U-Boot image. Of course this is not a perfect solution (e.g. it is
inefficient since the DTs are likely to be largely the same) but it
should be a good first step.
I'm going to try this out with sunxi initially and plan to get some
patches out by the end of the week.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
