On 01/16/14 11:20, Michael Tremer wrote:
> Hello Igor,
> 
> On Thu, 2014-01-16 at 10:50 +0200, Igor Grinberg wrote:
>> Hi Michael,
>>
>> On 01/15/14 17:19, Michael Tremer wrote:
>>> Hello guys,
>>>

[...]


>> I'd like you to try the below workaround for your problem.
>> It will not make the Boot ROM boot from SD card on power on,
>> but it can enable you to test the U-Boot on the SD card as
>> the Boot ROM will try to boot from SD card on warm reset.
>> It will still report the boot from SPI NOR, as this information
>> is read from another location which is not affected by the
>> workaround below.
>>
>> In U-Boot console write:
>> mw 20d8040 3042 && mw 20d8044 10000000 && reset
>>
>> I'd like to here if this works for you.
> 
> Indeed this works:
> 
> usdhc1 clock  : 198000000Hz
> usdhc2 clock  : 198000000Hz
> usdhc3 clock  : 198000000Hz
> usdhc4 clock  : 198000000Hz
> nfc clock     : 11000000Hz
> Board: CM-FX6:[ POR ]
> Boot Device: SPI NOR
> I2C:   ready
> RAM Configuration:
> Bank #0: 10000000  1 GB
> Bank #1: 80000000  1 GB
> NAND:  No NAND device found!!!
> 0 MiB
> MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2
> JEDEC ID: 0xbf:0x25:0x41
> Reading SPI NOR flash 0xc0000 [0x2000 bytes] -> ram 0x17e030e0
> SUCCESS
> 
> In:    serial
> Out:   serial
> Err:   serial
> Net:   got MAC address from IIM: 00:00:00:00:00:00
> FEC0
> Hit any key to stop autoboot:  0 
> CM-FX6 # mw 20d8040 3042; mw 20d8044 10000000
> CM-FX6 # reset
> resetting ...
> 
> 
> U-Boot 2013.10-00009-gda9c0af-dirty (Nov 26 2013 - 21:17:35)
> 
> CPU:   Freescale i.MX6Q rev1.2 at 792 MHz
> Reset cause: POR
> Board: Utilite
> DRAM:  2 GiB
> MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC
> Hit any key to stop autoboot:  0 
> 
> 
> 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!

> 
> Is there any chance to make this change permanent or to change the
> firmware on the SoC to fix the bug?

Hmm... not really.
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.

> I sent you the serial number of my
> device in November (I think), so you can verify if my unit was
> manufactured before that date.
> 
>>> Why do I need to re-compile u-boot? Your version passes a board id to
>>> the kernel and it appears that the kernel won't boot with the device
>>> tree file that was passed to it.
>>>
>>> Possibly, this can be solved by this change:
>>>
>>> [root(a)hokey u-boot]# git diff
>>> diff --git a/board/compulab/cm_fx6/cm_fx6.c b/board/compulab/cm_fx6/cm_fx6.c
>>> index f46980d..91ffcdf 100644
>>> --- a/board/compulab/cm_fx6/cm_fx6.c
>>> +++ b/board/compulab/cm_fx6/cm_fx6.c
>>> @@ -805,7 +805,7 @@ int board_init(void)
>>>         setup_boot_device();
>>>  
>>>         /* board id for linux */
>>> -       gd->bd->bi_arch_number = MACH_TYPE_CM_FX6;
>>> +       //gd->bd->bi_arch_number = MACH_TYPE_CM_FX6;
>>>  
>>>         /* address of boot parameters */
>>>         gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
>>>
>>>
>>
>> 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...

May be the DT blob is not placed in the correct location or something?

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

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


-- 
Regards,
Igor.