From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Sun, 10 Mar 2013 23:03:52 +0100 Subject: [U-Boot] [PATCH V2] Add Boundary Devices Nitrogen6X boards In-Reply-To: <513CB3F2.6080604@boundarydevices.com> References: <1362873856-14785-1-git-send-email-eric.nelson@boundarydevices.com> <20130310075948.035BA200642@gemini.denx.de> <513CA21E.1040608@boundarydevices.com> <20130310154511.C066D2010CD@gemini.denx.de> <513CB3F2.6080604@boundarydevices.com> Message-ID: <20130310220352.ED5432010CD@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Eric, In message <513CB3F2.6080604@boundarydevices.com> you wrote: > > What we don't have is auto-detection and implementing this logic > requires that we execute code outside of DDR (i.e. through SPL > in internal RAM). Correct. > There's no question that a (more) universal binary would be helpful, > but in practice, checking the DDR parts isn't that different from > double-checking the CPU variant populated on a board. I'm not sure what you want to tell me here. The thing is that you don't want to maintain a dozen of different configurations, resulting in a number of different, incompatible binary images, and you and your users will always live in fear they might install the wrong image and brick a system (OK, when you can boot from SDCard or similar recovery will be less painful, but you still suffer from the maintenance efforts). > Troy's attempt at handling the CPU portion of things was nacked, I don't remember this. But I guess the reason was in the implementation, not in the idea? > which is what prompted me to this architecture of multiple CPU > configurations. But this doesn't scale. > > This is wrong then and needs to be fixed. get_ram_size() should be > > used before relocation into RAM. > > Either you or I are missing something. In any case I'm missing time to provide longer explanations... > As it stands, there is no "execute before relocation into RAM". > The CPU's ROM boot loader processes the settings in the DCD > (essentially a set of register writes) and then copies the > U-Boot code into DDR for execution. I understand this, and I'm trying to point out that this is an approach that is not useful in cases like yours where you have to support a large number of different configurations. I probably should point out that with such a setup you MUST NOT use get_ram_size(), as it will write and modify the memory you are executing from, so depending on a number of things it may happily crash your system. get_ram_size() has always to be used before running any code from the RAM that is going to be tested. > The only way to change this is to use a first level loader that > executes code within the internal RAM so the setup can be > conditional. Correct. In your situation this is the approach that shouldbe taken. > Are you saying that submissions of board files that don't > support SPL will be nacked, or only boards that want to > support multiple memory configurations without SPL? Please note that I did not NAK anything. I'm just trying to point out deficiencies (and in my opinion prety major deficiencies) in the submitted code, and to provide suggestions how to fix these. In my experience, it is easier to get such fixes done before the code goes into mainline - once it's in, both your own motivation and any backing you can get from management levels for the required efforts for such a rework will be in a much poorer state. So I'm just aking suggestions. Do you by chancew feel you heard me use that sweet, innocent tone of voice before? Well, then I can stop here :-) Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de What is research but a blind date with knowledge? -- Will Harvey