From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Grinberg <grinberg@compulab.co.il> To: sig-arm@lists.ipfire.org Subject: Re: News on Utilite? Date: Thu, 16 Jan 2014 13:26:25 +0200 Message-ID: <52D7C1E1.5060000@compulab.co.il> In-Reply-To: <1389868260.19959.90.camel@rice-oxley.tremer.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5468043654857262209==" List-Id: <sig-arm.lists.ipfire.org> --===============5468043654857262209== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On 01/16/14 12:31, Michael Tremer wrote: > Hey, > > On Thu, 2014-01-16 at 11:57 +0200, Igor Grinberg wrote: >>> So, indeed this works. The bootloader from the SD finally starts. >> >> I'm glad to here that and the fact it is 2013.10 with some changes! > > I got that from the Utilite forums from the thread I pointed you to > earlier. > >>> Is there any chance to make this change permanent or to change the >>> firmware on the SoC to fix the bug? >> >> Hmm... not really. > > Does that mean it is not possible at all or just not possible because I > don't have the tools and firmware? Well, this is theoretically possible by burning fuses, but I really disregard this way, as it is not revert-able. > >> You can add some kind of logic to the environment and >> make the SPI flash U-Boot run those commands automatically >> once it discovers an SD card with another U-Boot on it... >> >> Usually, you need this workaround only to test the new U-Boot >> and after you know it is good, you just flash it onto the SPI flash. > > Yes. But as a distributor it would be nice to provide an SD card image > that people just need to download, flash on to their SD cards, put in > the card and boot. > Everyone can do this and there is no chance that you brick your device. Right. This is the expected way. I don't see why this would not work... The bug has been fixed and only a small amount of early Utilite units is affected, so users should just plug the SD card and play... If there will be a several users affected by the bug, they should contact CompuLab and get a solution for the problem. > >>>> Well, as our bootz command has been designed, the above should not >>>> have an impact on the DT boot, as bootz should write 0xffffffff instead >>>> of mach type, while bootm will preserve the mach type. >>>> This way it should allow both zImage and uImage boot via bootz and bootm >>>> respectively. >>> >>> Indeed this is the way it should be. The kernel however falls back to >>> the ATAGS mode and won't use the device tree file that is passed. >> >> This is strange... >> Still, I don't think the problem is mach type... >> To check this, you can use my U-Boot (tagged +tools) >> and use the machtype command to set what ever mach type you like >> (e.g. 0xffffffff). Then boot Linux to see if it helps... > > Well, as I now have more recent version of u-boot, I can confirm that > the message is gone and the system seems to use the device tree file. > However, the kernel does not boot up and there is no other console > output, but still the original error is gone. > > I tried to set machtype which had no effect. This confirms, that the DT problem is somewhere else - not in the mach type mismatch. > >> May be the DT blob is not placed in the correct location or something? > > It is because as you can see from the logs I posted, u-boot loads it, > verifies it and moves it to an other place. So I assume this is fine. > > Do you know any other distribution that boots the device with DT? You > mentioned Fedora, but I could not find any evidence that Utilite is > supported nor could I found an image to test. Well, Fedora 20 haven't made it with Utilite in time... > >>> I assume that only u-boot can influence this. The same kernel image >>> boots fine on Wandboard (with a recent version of u-boot). >> >> I think kernel configuration can also influence this. >> It's a pity, I can't work on this right now... > > I can work on the kernel, but I have no skills to get the SD card boot > issue fixed. I think, I've lost you here... What do you mean the SD card boot issue? The workaround does the job, no? > >>> BTW: Did you see the post of the Wandboard team to split u-boot and >>> provide an SPL for their boards on http://wandboard.org/ (Dec 26th >>> 2013)? Maybe there is a chance to add your hardware to the SPL as well. >> >> Well, that's the plan in the ~near future... >> Nikita is going to work on mainline U-Boot support including SPL. > > That's great news. I hope you will keep us up to date on this. > > -Michael > > -- Regards, Igor. --===============5468043654857262209==--