Re: [PATCH v2 1/8] ARM: phytec-som-imx6: Add low cost variant for imx6dl phycore

[Sascha Hauer <s.hauer@pengutronix.de>]

On Thu, Jul 11, 2019 at 12:07:08PM +0200, Stefan Riedmüller wrote:
> Hi Sascha,
> 
> > Hi Stefan,
> > 
> > On Wed, Jul 10, 2019 at 01:17:28PM +0200, Stefan Riedmueller wrote:
> > >   PHYTEC_ENTRY(start_phytec_phycore_imx6dl_som_nand_256mb, imx6dl_phytec_phycore_som_nand, SZ_256M, true);
> > > +PHYTEC_ENTRY(start_phytec_phycore_imx6dl_som_lc_nand_256mb, imx6dl_phytec_phycore_som_lc_nand, SZ_256M, true);
> > >   PHYTEC_ENTRY(start_phytec_phycore_imx6dl_som_nand_1gib, imx6dl_phytec_phycore_som_nand, SZ_1G, true);
> > >   PHYTEC_ENTRY(start_phytec_phycore_imx6dl_som_emmc_1gib, imx6dl_phytec_phycore_som_emmc, SZ_1G, true);
> > > +PHYTEC_ENTRY(start_phytec_phycore_imx6dl_som_lc_emmc_1gib, imx6dl_phytec_phycore_som_lc_emmc, SZ_1G, true);
> > >   PHYTEC_ENTRY(start_phytec_phycore_imx6q_som_nand_1gib, imx6q_phytec_phycore_som_nand, SZ_1G, true);
> > >   PHYTEC_ENTRY(start_phytec_phycore_imx6qp_som_nand_1gib, imx6qp_phytec_phycore_som_nand, SZ_1G, true);
> > >   PHYTEC_ENTRY(start_phytec_phycore_imx6q_som_emmc_1gib, imx6q_phytec_phycore_som_emmc, SZ_1G, true);
> > 
> > I am a bit worried that with this series the combinatoric explosion of
> > the Phytec boards goes into another round. For some reason the lowcost
> > NAND version has 256MiB SDRAM and the eMMC version has 1GiB SDRAM. I
> > guess different combinations are not supported because you haven't
> > produced them yet, but they might appear sooner or later. Even now it is
> > really hard to pick a board from the shelf and find the right barebox
> > binary for it. Do you have any ideas/plans to improve this?
> 
> I agree and I don't like the amount of images much either. We already had
> some discussions here about this but did not find a satisfying solution yet.
> 
> > 
> > It seems all boards have EEPROMs. Wouldn't it be an option to store some
> > information there?
> 
> The problem here is that the EEPROM is an option and there are SOMs out
> there which do not have it (people try to save money where ever they can).
> There are plans to make use of the EEPROM but they probably won't affect the
> i.MX 6 for reasons I just mentioned.

Perhaps we can put defaults for some values into Kconfig and overwrite
these values from the EEPROM if it exists. The Kconfig values could be
sane defaults to be used when the EEPROM is empty or doesn't exist.
Those who don't have an EEPROM must adjust the Kconfig settings then.

> 
> > 
> > Another point is: Do we really need image variants for eMMC and NAND? In
> > the end the drivers detect automatically if one or the other is equipped
> > on the board.
> 
> There is also a problem here as both options share some pins. So pinmuxing
> would still be something to take care of.

Oh, I see. MX6QDL_PAD_SD4_CMD and MX6QDL_PAD_SD4_CLK are shared between
NAND and eMMC. I thought that both devices are present in the device
tree and thus don't have any conflicting pins. That is wrong of course.

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox