From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar Gala Date: Wed, 27 Jul 2011 07:20:51 -0500 Subject: [U-Boot] __fsl_ddr_set_lawbar: ERROR (ctrl #0, intrlv=0) In-Reply-To: <20110726092351.4BCCB138EED4@gemini.denx.de> References: <20110725081833.6964E138EECD@gemini.denx.de> <20110725175756.D2BD8138EED4@gemini.denx.de> <20110726092351.4BCCB138EED4@gemini.denx.de> Message-ID: <17E34909-A735-4920-9980-059D95535774@kernel.crashing.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 Jul 26, 2011, at 4:23 AM, Wolfgang Denk wrote: > Dear Kumar Gala, > > In message you wrote: >> >> Do you know if this board has any real reset on a FPGA or CPLD or >> something like that. > > There is no such faeature on that board, nor on any of a number of > other 85xx boards I have access to. > >> The problem on the 8555/8541 is the reset you are trigger is just a core >> reset and not one of the full SoC. If there is a board level means I >> would suggest trying to utilize it instead. If not this might be >> painful & problematic as you'll have to slowly make sure we are >> 'resetting' each SoC block properly. > > Is this also the cause why the Linux reboot ommand does not work? Probably. > If so, I wonder what has changed, because this used to be working in > older versions of the kernel? I did not attampt a full git bisect, > but from some old images I still found it appears it must have been > broken between 2.6.16 ("reboot" in Linux works fine) and 2.6.27 > ("reboot" does not work any more) - so probably this was part of the > arch/ppc => arch/powerpc rework. Possible, its a pretty fragile reset solution so one (or a thousand) of a million things could be the issue. > Is there any specific reason we don't use the good old approach of > triggering an unhandled machine check exception? Hmm, when did we do that? I've got no issues with it if it causes HRESET_REQ to be signaled on the older devices. On MPC8548 and greater we provided a means for software to causes HRESET_REQ to be asserted. So if an unhandled mcheck will do this sounds good to me. - k