From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hlSnN-0000v7-79 for barebox@lists.infradead.org; Thu, 11 Jul 2019 06:43:10 +0000 Date: Thu, 11 Jul 2019 08:43:07 +0200 From: Sascha Hauer Message-ID: <20190711064307.lbnenmog7qwbzu3a@pengutronix.de> References: <1562757455-445159-1-git-send-email-s.riedmueller@phytec.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1562757455-445159-1-git-send-email-s.riedmueller@phytec.de> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "barebox" Errors-To: barebox-bounces+u.kleine-koenig=pengutronix.de@lists.infradead.org Subject: Re: [PATCH v2 1/8] ARM: phytec-som-imx6: Add low cost variant for imx6dl phycore To: Stefan Riedmueller Cc: barebox@lists.infradead.org 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? It seems all boards have EEPROMs. Wouldn't it be an option to store some information there? 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. Let's go crazy now. How about a QR code on the board with a link that describes which hardware (SoC variant, amount of memory, NAND/eMMC) I am looking at? Anyway, applied, thanks. It would just be nice to see some improvements here. 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