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 10:50:13 +0200
Message-ID: <52D79D45.4070301@compulab.co.il>
In-Reply-To: <1389799141.19959.69.camel@rice-oxley.tremer.info>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============3119621088444309174=="
List-Id: <sig-arm.lists.ipfire.org>

--===============3119621088444309174==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Hi Michael,

On 01/15/14 17:19, Michael Tremer wrote:
> Hello guys,
> 
> thank you for writing back. As you said, I updated u-boot on my unit to
> version 2009.08-cm-fx6-0.91+tools (Nov 19 2013). The issue remains the
> same that I cannot boot an other u-boot from SD card which is what I
> need to find out why the kernel is not booting properly.
> 
> First, let's talk about the u-boot SD card issue:
> 
> U-Boot 2009.08-cm-fx6-0.91+tools (Nov 19 2013 - 14:56:48)
> 
> CPU: Freescale i.MX6 family TO6.4 at 792 MHz
> Temperature:   39 C, calibration data 0x5b152a69
> mx6q pll1: 792MHz
> mx6q pll2: 528MHz
> mx6q pll3: 480MHz
> mx6q pll8: 50MHz
> ipg clock     : 66000000Hz
> ipg per clock : 66000000Hz
> uart clock    : 80000000Hz
> cspi clock    : 60000000Hz
> ahb clock     : 132000000Hz
> axi clock   : 264000000Hz
> emi_slow clock: 29333333Hz
> ddr clock     : 528000000Hz
> usdhc1 clock  : 198000000Hz
> usdhc2 clock  : 198000000Hz
> usdhc3 clock  : 198000000Hz
> usdhc4 clock  : 198000000Hz
> nfc clock     : 11000000Hz
> Board: CM-FX6:[ WDOG ]
> 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 #   
> 
> That is the output of the bootloader inside the SPI. It says:
> 
>   Boot Device: SPI NOR
> 
> I believe that this should be "SD" card.
> 
> On the utilite forums, there is a thread where people have exactly the
> same problem:
> http://www.utilite-computer.com/forum/viewtopic.php?f=66&t=1465

I see...
I suspect that you are affected by SD card start up hardware bug
which was found on the early Utilite units.
It has been fixed on all units that came out of CompuLab since
the bug discovery. I currently can't remember the exact dates.

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.

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

> But as long as I cannot test it am not too sure about how the kernel
> behaves.

Please, try the workaround.


-- 
Regards,
Igor.

--===============3119621088444309174==--