From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Fri, 14 Dec 2012 14:52:31 -0700 Subject: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically In-Reply-To: <50CB8ED1.7020503@ti.com> References: <1355354590-10023-1-git-send-email-swarren@wwwdotorg.org> <50C918A5.6090207@wwwdotorg.org> <20121213102950.17EC320120D@gemini.denx.de> <50CA1BB8.4000704@wwwdotorg.org> <20121213203604.1DD9F201213@gemini.denx.de> <50CA3E7A.8020407@wwwdotorg.org> <50CA4056.8060900@ti.com> <50CA437F.7060704@wwwdotorg.org> <50CB8ED1.7020503@ti.com> Message-ID: <50CB9F9F.5010402@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/14/2012 01:40 PM, Tom Rini wrote: > On 12/13/12 16:51, Simon Glass wrote: > > [snip] >>>> And from there we can move on and say "On ${SoC} we get a >>>> device tree (that we can't quite parse as we don't have >>>> enough resources) AND $some-data (OMDATA or an abbreviated >>>> device tree or $whatever), lets translate that into something >>>> we can make use of very early rather than a hard-coded >>>> initial console location" >>> >>> It seems like you're saying that once we have dynamic serial >>> port assignment working based on DT, you'll be fine using >>> ODMDATA to initialize the early console, but not before then? >>> If so, I'm having a hard time understanding why enabling the >>> DT-based support blocks using ODMDATA, since the code would be >>> pretty orthogonal. > >> Yes well dynamic console selection sounds find to me, ODMDATA or >> otherwise. To me it is a Tegra feature that should be supported >> as such. Perhaps we can allow the FDT console alias to specify >> "odmdata" to mean that, and/or (as you suggest I think) set the >> console to USE_ODMDATA, which then selects >> CONFIG_SYS_NS16550_COMx accordingly. > > There's two parts to it. One part is that sure, Tegra and only > Tegra has ODMDATA. But on am33xx if we poke the i2c eeprom (on > platforms that do the eeprom) we can then know ... And I bet other > SoCs have other tricks for this or that. So it's not just tegra > that can tell us the initial console is $here or $there if we just > ...something. That's certainly true. I personally view the method of retrieving this kind of information as part of an SoC's boot architecture, or as part of a board's design. As you have mentioned above, different SoCs/boards already have mechanisms to represent/determine this information. These mechanisms are already in-place and defined by the SoC or board designers. > The other part is, take a look at the Allwinner thread from a week > or so ago. We really need to define how we want early board > specific data to come in because if we start saying we'll accept > per-SoC solutions we'll be drowning in them in short time. We want > to say here's our preferred way to pass this information in. I don't understand why you think U-Boot is in a position to mandate that the existing solutions that are already in place are incorrect, and must be replaced with some alternative.