Re: News on Utilite?

Re: News on Utilite?

[Michael Tremer]

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

Hello Ben,

On Thu, 2014-01-09 at 13:41 +0100, Benjamin Schweikert wrote:
> Hi everyone,
> 
> is there any progress with this wonderful piece of Hardware during the
> christmas vacations?

I wish I had good news for you, but unfortunately there has not been any
progress at all regarding Utilite support. However, there have been huge
advancements towards the unified ARM kernel and for the 2.15 release in
general.

I am currently stuck that the version of uboot Compulab provided us with
is malfunctioning so that I can not boot the IPFire kernel. I also got
no response on why my unit won't start uboot from SD card.

As there is currently no spare time so that I cannot look into those
things. So, our plans to support the device with 2.15 are somewhat
frozen by now.

> - Is there any difference with the new version of u-boot from
> Compulab?

No.

> - Did someone try the wandaboard kernel from stevee?

Stevee did and Arne is working to support all the other devices we had
extra kernel for in the past. So this is the new unified kernel.

> If there is a real chance to get the fire running on this HW I would
> buy one and would give support as good as possible. What do you think
> michael?

I guess the hardware is very great for use as a router with IPFire.
Unfortunately, I cannot guarantee that IPFire will support it - we don't
support it right now and possibly never will.

-Michael

Re: News on Utilite?

[Christer Solskogen]

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

On Sun, Jan 12, 2014 at 6:49 PM, Michael Tremer
<michael.tremer(a)ipfire.org> wrote:
> Hello Ben,

> I am currently stuck that the version of uboot Compulab provided us with
> is malfunctioning so that I can not boot the IPFire kernel. I also got
> no response on why my unit won't start uboot from SD card.
>

Tried upgrading uboot?
http://www.utilite-computer.com/wiki/index.php/U-Boot_Update

I have no trouble with SD cards after update.


-- 
chs,

Re: News on Utilite?

[Michael Tremer]

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

Hey Christer,

I think you pointed me to this earlier. I did not upgrade to this
version yet, because the Compulab guys think that my unit has got a
little bit of a defect in the firmware; a race-condition that makes it
unable to execute uboot from SD card.

So I need to flash it to the internal flash and if anything goes wrong
with that, I might brick the device.

The version I got from Compulab (Nov 14, cm-fx6-u-boot-0.90
+tools-mx6q-2gb) is not equivalent to the version in the image you
linked (Nov 21). Also my version comes with some "tools" (I have no clue
which).

-Michael

P.S. I CCed Compulab and hope that they will be able to help.

On Sun, 2014-01-12 at 19:33 +0100, Christer Solskogen wrote:
> On Sun, Jan 12, 2014 at 6:49 PM, Michael Tremer
> <michael.tremer(a)ipfire.org> wrote:
> > Hello Ben,
> 
> > I am currently stuck that the version of uboot Compulab provided us with
> > is malfunctioning so that I can not boot the IPFire kernel. I also got
> > no response on why my unit won't start uboot from SD card.
> >
> 
> Tried upgrading uboot?
> http://www.utilite-computer.com/wiki/index.php/U-Boot_Update
> 
> I have no trouble with SD cards after update.
> 
> 

Re: News on Utilite?

[Christer Solskogen]

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

On Sun, Jan 12, 2014 at 6:49 PM, Michael Tremer
<michael.tremer(a)ipfire.org> wrote:

> I wish I had good news for you, but unfortunately there has not been any
> progress at all regarding Utilite support. However, there have been huge
> advancements towards the unified ARM kernel and for the 2.15 release in
> general.
>

If IPFire would provide binaries for armv7 - you could, in theory, use
the kernel from archlinux.
CompuLab provides their own kernel source at
https://gitorious.org/utilite which arch uses. So you can also cross
compile the kernel if you like.

-- 
chs

Re: News on Utilite?

[Michael Tremer]

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

On Mon, 2014-01-13 at 09:57 +0100, Christer Solskogen wrote:
> On Sun, Jan 12, 2014 at 6:49 PM, Michael Tremer
> <michael.tremer(a)ipfire.org> wrote:
> 
> > I wish I had good news for you, but unfortunately there has not been any
> > progress at all regarding Utilite support. However, there have been huge
> > advancements towards the unified ARM kernel and for the 2.15 release in
> > general.
> >
> 
> If IPFire would provide binaries for armv7 - you could, in theory, use
> the kernel from archlinux.
> CompuLab provides their own kernel source at
> https://gitorious.org/utilite which arch uses. So you can also cross
> compile the kernel if you like.

Unfortunately we cannot do that.

IPFire is built from source and there is a reason for it: We want to be
able to control what is enabled and what not. Especially in the kernel,
there is lots of stuff that we don't need and other stuff that we do
need, but which is often not enabled in the mainstream distributions.

This is for example networking features or very strong hardening which
is not very suitable on a desktop system. We apply grsecurity and more
things and we have our own hardened compiler.

Therefore we require the sources and we need to compile them ourselves.

Other distributions take arbitrary kernel images they found on they
Internet and bundle them with their userland and then claim to support a
certain board. But there are never updates, the kernel differs a lot
from the original distribution kernel, you never know if someone added
some malware - or added some patches that make the system insecure or
unstable - and there are so many other issues...

We simply cannot do this.

But currently, the kernel is not the issue here. I am confident that it
will run decently on the board. It just cannot be booted right now. And
that is a problem caused by uboot.

-Michael

Re: News on Utilite?

[Igor Grinberg]

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

Hi Michael,

On 01/12/14 21:03, Michael Tremer wrote:
> Hey Christer,
> 
> I think you pointed me to this earlier. I did not upgrade to this
> version yet, because the Compulab guys think that my unit has got a
> little bit of a defect in the firmware; a race-condition that makes it
> unable to execute uboot from SD card.
> 
> So I need to flash it to the internal flash and if anything goes wrong
> with that, I might brick the device.
> 
> The version I got from Compulab (Nov 14, cm-fx6-u-boot-0.90
> +tools-mx6q-2gb) is not equivalent to the version in the image you
> linked (Nov 21). Also my version comes with some "tools" (I have no clue
> which).

0.90 U-Boot version does not include the SD card voltage fix.

You should try the update procedure pointed by Christer.
It is done with a script utility that I wrote.
Although, several prerequisites are required:
1) The SPI flash has to be accessible via the MTD framework
2) Tools: diff, grep, sed, hexdump, dd, flash_erase.

The Ubuntu image and Linux kernel released by Compulab meet the
requirements above, so can be used for the U-Boot update procedure.

The update can also be done from U-Boot console, but has more
place for a mistake.

You can always contact me if you have problems with the update.

Good luck!

> 
> -Michael
> 
> P.S. I CCed Compulab and hope that they will be able to help.
> 
> On Sun, 2014-01-12 at 19:33 +0100, Christer Solskogen wrote:
>> On Sun, Jan 12, 2014 at 6:49 PM, Michael Tremer
>> <michael.tremer(a)ipfire.org> wrote:
>>> Hello Ben,
>>
>>> I am currently stuck that the version of uboot Compulab provided us with
>>> is malfunctioning so that I can not boot the IPFire kernel. I also got
>>> no response on why my unit won't start uboot from SD card.
>>>
>>
>> Tried upgrading uboot?
>> http://www.utilite-computer.com/wiki/index.php/U-Boot_Update
>>
>> I have no trouble with SD cards after update.
>>
>>
> 
> 

-- 
Regards,
Igor.

Re: News on Utilite?

[Michael Tremer]

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

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

----

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;


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

So, please can you look into this and find out if there is a way to get
my device booting u-boot from SD card?

-Michael

Re: News on Utilite?

[Christer Solskogen]

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

On Wed, Jan 15, 2014 at 4:19 PM, Michael Tremer
<michael.tremer(a)ipfire.org> wrote:
>
> So, please can you look into this and find out if there is a way to get
> my device booting u-boot from SD card?
>

How did you get uboot on the SD card? jas-mx (from the utilite from)
created a uboot that I was able to boot.
http://www.utilite-computer.com/forum/viewtopic.php?f=66&t=1465&sid=29ef9727c1b68fcbde3c285b559bc01e


-- 
chs,

Re: News on Utilite?

[Igor Grinberg]

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

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.

Re: News on Utilite?

[Michael Tremer]

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

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

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.

Is there any chance to make this change permanent or to change the
firmware on the SoC to fix the bug? 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.
I assume that only u-boot can influence this. The same kernel image
boots fine on Wandboard (with a recent version of u-boot).

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.

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

-Michael

Re: News on Utilite?

[Michael Tremer]

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

Hey Christer,

I used the following command with the imx image:

  dd if=<image file>.imx of=/dev/sdc bs=1k seek=1

That's it and it boots with the workaround that Igor posted today.

-Michael

On Thu, 2014-01-16 at 09:49 +0100, Christer Solskogen wrote:
> On Wed, Jan 15, 2014 at 4:19 PM, Michael Tremer
> <michael.tremer(a)ipfire.org> wrote:
> >
> > So, please can you look into this and find out if there is a way to get
> > my device booting u-boot from SD card?
> >
> 
> How did you get uboot on the SD card? jas-mx (from the utilite from)
> created a uboot that I was able to boot.
> http://www.utilite-computer.com/forum/viewtopic.php?f=66&t=1465&sid=29ef9727c1b68fcbde3c285b559bc01e
> 
> 

Re: News on Utilite?

[Igor Grinberg]

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

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.

Re: News on Utilite?

[Michael Tremer]

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

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

Re: News on Utilite?

[Igor Grinberg]

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