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?

> 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.

> >> 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.

> 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.

> > 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.

> > 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