On Tue, Dec 03, 2013 at 08:01:26PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 10:26 Tue 03 Dec , Sascha Hauer wrote: > > BTW Please don't top-post. > > > > On Mon, Dec 02, 2013 at 09:13:31AM +0000, John Parker wrote: > > > Hi again > > > > > > So now my problem is that I really could do with the LED and UBIFS stuff that happened since February. > > > > > > Should I try to fix mx25 in the latest code, or undo the problematic commit? > > > > Well preferably you should fix the latest code and send a patch to make > > it work again ;) However, that could become tricky. For doing so the > > patch to enable the debug UART early may become useful. With this you > > can use putc_ll and puthex_ll in early code. > > > > I did some investigation. What happens here is really strange. First I > > added a missing instruction cache invalidation. That alone doesn't fix > > the problem. Inserting a nop fixes booting for me, see the attached > > patch. If I move the nop up in the code it still works. If I move it > > down, then the board does not work. I have no idea what's happening here > > :( > > could be that the sdram controler need times to stabelized and that you miss a > delay for this I thought about this aswell, but I don't believe that a single nop could make such a reproducable difference. I tried all this with JTAG debugging aswell which should make all timing issues vanish. 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
