Re: News on Utilite?

[Igor Grinberg <grinberg@compulab.co.il>]

[-- Attachment #1: Type: text/plain, Size: 4089 bytes --]

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.