IPFire on Utilite

IPFire on Utilite

[Michael Tremer]

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

Hello Igor,

although this email is directed to you, I am CC'ing our Special Interest
Group ARM mailing list for archiving purposes.

As you know, we are currently working on rebasing IPFire on Linux 3.10
and we are introducing a multiplatform kernel which is supposed to run
on a lot of ARM boards including Utilite.

We made progress and solved some very hard to solve grsecurity-related
issues in association with Brad, so that we currently have a kernel
which boots on a Wandboard Quad - also based on the same Freescale SoC
you are using. Some patches for supporting Utilite are already included,
so that I have very high hopes, that this kernel will already boot on
that hardware as well.

The Utilite I have got, unfortunately comes with an old version of
u-boot, which does not support the bootz command that is required to
easily boot a multiplatform kernel.
Could you please provide the sources so that we can build a version of
u-boot with our requirements? It would also be great if this is a more
recent one (don't know if there is development going on behind closed
doors).

I also think I remember that Utilite will run the bootloader it can find
on the micro SD card, if I don't confuse this with an other device. So
that if I want to replace/test my own version of u-boot I don't need to
flash the internal one. I cannot find the documentation about this
matter any more and I would like to know where the u-boot image needs to
be placed in order to be executed.

Thank you very much for your help.

-Michael

P.S. Please subscribe to our SIG-ARM mailing list to stay tuned and in
order to reply to this email.

http://lists.ipfire.org/mailman/listinfo/sig-arm

RE: IPFire on Utilite

[Igor Vaisbein]

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

Hello Michael,

I am glad to hear that you are making progress with support for i.MX6 devices.
We already have done some work for multi-platform kernel support so I do believe that most things are already in place.

I am copying Igor Grinberg, our Linux team leader. He will support you with the necessary U-boot materials and documentation.

Looking forward to further developments.

Best Regards,
Igor.

-----Original Message-----
From: Michael Tremer [mailto:michael.tremer(a)ipfire.org] 
Sent: Wednesday, November 13, 2013 12:59 AM
To: Igor Vaisbein
Cc: sig-arm(a)lists.ipfire.org
Subject: IPFire on Utilite

Hello Igor,

although this email is directed to you, I am CC'ing our Special Interest Group ARM mailing list for archiving purposes.

As you know, we are currently working on rebasing IPFire on Linux 3.10 and we are introducing a multiplatform kernel which is supposed to run on a lot of ARM boards including Utilite.

We made progress and solved some very hard to solve grsecurity-related issues in association with Brad, so that we currently have a kernel which boots on a Wandboard Quad - also based on the same Freescale SoC you are using. Some patches for supporting Utilite are already included, so that I have very high hopes, that this kernel will already boot on that hardware as well.

The Utilite I have got, unfortunately comes with an old version of u-boot, which does not support the bootz command that is required to easily boot a multiplatform kernel.
Could you please provide the sources so that we can build a version of u-boot with our requirements? It would also be great if this is a more recent one (don't know if there is development going on behind closed doors).

I also think I remember that Utilite will run the bootloader it can find on the micro SD card, if I don't confuse this with an other device. So that if I want to replace/test my own version of u-boot I don't need to flash the internal one. I cannot find the documentation about this matter any more and I would like to know where the u-boot image needs to be placed in order to be executed.

Thank you very much for your help.

-Michael

P.S. Please subscribe to our SIG-ARM mailing list to stay tuned and in order to reply to this email.

http://lists.ipfire.org/mailman/listinfo/sig-arm

Re: IPFire on Utilite

[Igor Grinberg]

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

Hi Michael,

On 11/13/13 14:04, Igor Vaisbein wrote:
> Hello Michael,
> 
> I am glad to hear that you are making progress with support for i.MX6
> devices. We already have done some work for multi-platform kernel
> support so I do believe that most things are already in place.
> 
> I am copying Igor Grinberg, our Linux team leader. He will support
> you with the necessary U-boot materials and documentation.
> 
> Looking forward to further developments.
> 
> Best Regards, Igor.
> 
> -----Original Message----- From: Michael Tremer
> [mailto:michael.tremer(a)ipfire.org] Sent: Wednesday, November 13, 2013
> 12:59 AM To: Igor Vaisbein Cc: sig-arm(a)lists.ipfire.org Subject:
> IPFire on Utilite
> 
> Hello Igor,
> 
> although this email is directed to you, I am CC'ing our Special
> Interest Group ARM mailing list for archiving purposes.
> 
> As you know, we are currently working on rebasing IPFire on Linux
> 3.10 and we are introducing a multiplatform kernel which is supposed
> to run on a lot of ARM boards including Utilite.

This is good to hear!
There is a patchm adding basic support for Utilite,
pending merge in the next merge window:

http://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=commit;h=95f7e8a387c84c3b4e07e1579daefbb61bc1096b

> 
> We made progress and solved some very hard to solve
> grsecurity-related issues in association with Brad, so that we
> currently have a kernel which boots on a Wandboard Quad - also based
> on the same Freescale SoC you are using. Some patches for supporting
> Utilite are already included, so that I have very high hopes, that
> this kernel will already boot on that hardware as well.

That would be great!

> 
> The Utilite I have got, unfortunately comes with an old version of
> u-boot, which does not support the bootz command that is required to
> easily boot a multiplatform kernel. Could you please provide the
> sources so that we can build a version of u-boot with our
> requirements? It would also be great if this is a more recent one
> (don't know if there is development going on behind closed doors).

Our U-Boot for Utilite (cm-fx6) has the bootz command supported
starting from version v2009.08-cm-fx6-0.90. The binary is attached.
Here is the update procedure for SPI flash:

1) Get the new binary into the RAM:
  TFTP commands: tftp 10800000 cm-fx6-u-boot
  MMC  commands: mmc dev 2 && mmc rescan && fatload mmc 2 10800000 cm-fx6-u-boot

2) Do not power off Utilite during the next step! Erase and program U-Boot into
   the SPI flash:
  sf probe 0:0 && sf erase 0 40000 && sf write 10800000 0 40000

3) Once the above operation has finished, reset the Utilite and the new U-Boot 
   will boot.

I've uploaded the U-Boot sources to the Utilite gitorious project:
https://gitorious.org/utilite

Have a nice hacking!

> 
> I also think I remember that Utilite will run the bootloader it can
> find on the micro SD card, if I don't confuse this with an other
> device. So that if I want to replace/test my own version of u-boot I
> don't need to flash the internal one. I cannot find the documentation
> about this matter any more and I would like to know where the u-boot
> image needs to be placed in order to be executed.

Well, the following dd command can be used for placing the U-Boot binary
onto an SD card:

  dd if=$UBOOTSRCFILE of=$SDCARDDEVFILE bs=1K seek=1 skip=1


-- 
Regards,
Igor.

[-- Attachment #2: cm-fx6-u-boot-0.90tools-mx6q-2gb --]
[-- Type: application/octet-stream, Size: 252904 bytes --]

Re: IPFire on Utilite

[Michael Tremer]

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

Hi,

On Thu, 2013-11-14 at 17:10 +0200, Igor Grinberg wrote:
> Hi Michael,
> 
> On 11/13/13 14:04, Igor Vaisbein wrote:
> > Hello Michael,
> > 
> > I am glad to hear that you are making progress with support for i.MX6
> > devices. We already have done some work for multi-platform kernel
> > support so I do believe that most things are already in place.
> > 
> > I am copying Igor Grinberg, our Linux team leader. He will support
> > you with the necessary U-boot materials and documentation.
> > 
> > Looking forward to further developments.
> > 
> > Best Regards, Igor.
> > 
> > -----Original Message----- From: Michael Tremer
> > [mailto:michael.tremer(a)ipfire.org] Sent: Wednesday, November 13, 2013
> > 12:59 AM To: Igor Vaisbein Cc: sig-arm(a)lists.ipfire.org Subject:
> > IPFire on Utilite
> > 
> > Hello Igor,
> > 
> > although this email is directed to you, I am CC'ing our Special
> > Interest Group ARM mailing list for archiving purposes.
> > 
> > As you know, we are currently working on rebasing IPFire on Linux
> > 3.10 and we are introducing a multiplatform kernel which is supposed
> > to run on a lot of ARM boards including Utilite.
> 
> This is good to hear!
> There is a patchm adding basic support for Utilite,
> pending merge in the next merge window:
> 
> http://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=commit;h=95f7e8a387c84c3b4e07e1579daefbb61bc1096b

yes, this patch already has been imported with slight modifications for
kernel 3.10.

> > We made progress and solved some very hard to solve
> > grsecurity-related issues in association with Brad, so that we
> > currently have a kernel which boots on a Wandboard Quad - also based
> > on the same Freescale SoC you are using. Some patches for supporting
> > Utilite are already included, so that I have very high hopes, that
> > this kernel will already boot on that hardware as well.
> 
> That would be great!

Unfortunately, this is not the case, but I will figure this out later...
Give me a couple of days for that.

If you know about anything that could cause trouble in 3.10 or if there
are huge parts missing, please drop me a note :)

> > The Utilite I have got, unfortunately comes with an old version of
> > u-boot, which does not support the bootz command that is required to
> > easily boot a multiplatform kernel. Could you please provide the
> > sources so that we can build a version of u-boot with our
> > requirements? It would also be great if this is a more recent one
> > (don't know if there is development going on behind closed doors).
> 
> Our U-Boot for Utilite (cm-fx6) has the bootz command supported
> starting from version v2009.08-cm-fx6-0.90. The binary is attached.
> Here is the update procedure for SPI flash:
> 
> 1) Get the new binary into the RAM:
>   TFTP commands: tftp 10800000 cm-fx6-u-boot
>   MMC  commands: mmc dev 2 && mmc rescan && fatload mmc 2 10800000 cm-fx6-u-boot
> 
> 2) Do not power off Utilite during the next step! Erase and program U-Boot into
>    the SPI flash:
>   sf probe 0:0 && sf erase 0 40000 && sf write 10800000 0 40000
> 
> 3) Once the above operation has finished, reset the Utilite and the new U-Boot 
>    will boot.
> 
> I've uploaded the U-Boot sources to the Utilite gitorious project:
> https://gitorious.org/utilite
> 
> Have a nice hacking!

I flashed this version of u-boot to my device and it works fine. I tried
to boot it from sdcard, but that did not work with the command you
provided below. Possibly this should start after the first and not
second block (with size of 512 bytes), but I skipped searching for the
problem and decided to flash u-boot instead.

Also, thank you for the source code. Are there any plans to get all your
modifications upstream or is it intentional to remain with the version
from 2009?

> 
> > 
> > I also think I remember that Utilite will run the bootloader it can
> > find on the micro SD card, if I don't confuse this with an other
> > device. So that if I want to replace/test my own version of u-boot I
> > don't need to flash the internal one. I cannot find the documentation
> > about this matter any more and I would like to know where the u-boot
> > image needs to be placed in order to be executed.
> 
> Well, the following dd command can be used for placing the U-Boot binary
> onto an SD card:
> 
>   dd if=$UBOOTSRCFILE of=$SDCARDDEVFILE bs=1K seek=1 skip=1
> 
> 

-Michael

Re: IPFire on Utilite

[Michael Tremer]

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

Hello,

so, I still got some issues that I need to resolve, but all together
it's not looking that bad.
I am trying to boot a version of our kernel which boots on the Wandboard
with the quad-core CPU (i.e. the very same SoC).

This is what I get:

CM-FX6 # run boot_ipfire
mmc2 is current device
reading boot.scr

312 bytes read
## Executing script at 13800000
reading zImage-ipfire-multi

3264944 bytes read
reading uInit-ipfire-multi

1971259 bytes read
reading board.dtb

22996 bytes read
## Loading init Ramdisk from Legacy Image at 11800000 ...
   Image Name:   
   Image Type:   ARM Linux RAMDisk Image (lzma compressed)
   Data Size:    1971195 Bytes =  1.9 MB
   Load Address: 00000000
   Entry Point:  00000000
## Flattened Device Tree blob at 12800000
   Booting using the fdt blob at 0x12800000
   Loading Ramdisk to 4fe1e000, end 4ffff3fb ... OK
   Loading Device Tree to 107f7000, end 107ff9d3 ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x000010b1).

Available machine support:

ID (hex)	NAME
ffffffff	Generic DT based system
ffffffff	Freescale i.MX6 Quad/DualLite (Device Tree)
ffffffff	Freescale i.MX51 (Device Tree Support)
ffffffff	Freescale i.MX53 (Device Tree Support)
ffffffff	Generic OMAP5 (Flattened Device Tree)
ffffffff	Generic OMAP4 (Flattened Device Tree)
ffffffff	Generic AM33XX (Flattened Device Tree)
ffffffff	Generic OMAP3-GP (Flattened Device Tree)
ffffffff	Generic OMAP3 (Flattened Device Tree)
0000060a	OMAP3 Beagle Board
0000091a	OMAP3 Devkit8000
00000667	OMAP LDP board
000006ed	OMAP Logic 3530 LV SOM board
00000882	Logic OMAP3 Torpedo board
00000706	Gumstix Overo
000005ff	OMAP3 EVM
000006e1	Pandora Handheld Console
00000472	OMAP3430 3430SDP board
00000dc2	Nokia RM-696 board
00000c94	Nokia RM-680 board
000007a3	Nokia RX-51 board
000009a0	OMAP Zoom3 board
000007af	OMAP Zoom2 board
000009a1	OMAP 3630SDP board
00000cda	Compulab CM-T3730
00000925	Compulab CM-T35
00000abe	Compulab CM-T3517
00000a9d	IGEP OMAP3 module
00000928	IGEP v2 board
00000959	OMAP3 touchbook Board
00000870	OMAP4430 4430SDP board
00000ae7	OMAP4 Panda board
00000898	OMAP3517/AM3517 EVM
00000b74	AM3517/05 CRANEBOARD
00000aa2	OMAP3 STALKER
00000bbc	ti8148evm
00000af0	ti8168evm
ffffffff	ARM-Versatile Express
000008e0	ARM-Versatile Express

Please check your kernel config and/or bootloader.

----

Clearly the device tree file is loaded and usable (printed it to the
terminal with fdt addr 0xXXXX; fdt print), but it is not properly passed
to the kernel which tries to fall back to ATAGS boot mode then.

As a wild guess, I tried to disable ATAGS that it won't have the chance
to fall back, but that got me nowhere:

## Executing script at 13800000
reading zImage-ipfire-multi
3263712 bytes read
reading uInit-ipfire-multi
1971533 bytes read
reading board.dtb
22996 bytes read
## Loading init Ramdisk from Legacy Image at 11800000 ...
   Image Name:   
   Image Type:   ARM Linux RAMDisk Image (lzma compressed)
   Data Size:    1971469 Bytes =  1.9 MB
   Load Address: 00000000
   Entry Point:  00000000
## Flattened Device Tree blob at 12800000
   Booting using the fdt blob at 0x12800000
   Loading Ramdisk to 4fe1e000, end 4ffff50d ... OK
   Loading Device Tree to 107f7000, end 107ff9d3 ... OK

Starting kernel ...
Uncompressing Linux... done, booting the kernel.
no ATAGS support: can't continue

So, I suspect that there is something wrong with the device tree support
in u-boot and that u-boot still passes the machine ID, which I could not
disable.

I did not try to change the u-boot configuration and try to boot that
version, because if that image won't boot I might brick the device. I
can do this after we resolved the u-boot-booting-from-sd-card issue, but
I am sure that you might already have an idea.

On Sun, 2013-11-17 at 13:55 +0200, Igor Grinberg wrote:
> >>> The Utilite I have got, unfortunately comes with an old version of
> >>> u-boot, which does not support the bootz command that is required to
> >>> easily boot a multiplatform kernel. Could you please provide the
> >>> sources so that we can build a version of u-boot with our
> >>> requirements? It would also be great if this is a more recent one
> >>> (don't know if there is development going on behind closed doors).
> >>
> >> Our U-Boot for Utilite (cm-fx6) has the bootz command supported
> >> starting from version v2009.08-cm-fx6-0.90. The binary is attached.
> >> Here is the update procedure for SPI flash:
> >>
> >> 1) Get the new binary into the RAM:
> >>   TFTP commands: tftp 10800000 cm-fx6-u-boot
> >>   MMC  commands: mmc dev 2 && mmc rescan && fatload mmc 2 10800000 cm-fx6-u-boot
> >>
> >> 2) Do not power off Utilite during the next step! Erase and program U-Boot into
> >>    the SPI flash:
> >>   sf probe 0:0 && sf erase 0 40000 && sf write 10800000 0 40000
> >>
> >> 3) Once the above operation has finished, reset the Utilite and the new U-Boot 
> >>    will boot.
> >>
> >> I've uploaded the U-Boot sources to the Utilite gitorious project:
> >> https://gitorious.org/utilite
> >>
> >> Have a nice hacking!
> > 
> > I flashed this version of u-boot to my device and it works fine. I tried
> > to boot it from sdcard, but that did not work with the command you
> > provided below. Possibly this should start after the first and not
> > second block (with size of 512 bytes), but I skipped searching for the
> > problem and decided to flash u-boot instead.
> 
> The command below is the correct one.
> I suspect some other problem...
> Several early units had a hardware race during the boot ROM start up
> and it affected the boot capabilities of those units.
> This was fixed in all later units, but I'd like to check if this is
> the case with your Utilite.
> Can you please provide me the content of the white sticker
> on the bottom of the Utilite?

I will send you this in private in a minute.

> > Also, thank you for the source code. Are there any plans to get all your
> > modifications upstream or is it intentional to remain with the version
> > from 2009?
> 
> Well, yes, we plan to upstream the Utilite (cm-fx6) U-Boot (and kernel)
> support, but this will take us some time, so meanwhile we stick to 2009
> (which is the one used in Freescale BSP). 

Indeed would getting all your code upstream make it much more easy for
the distributors to provide support for Utilite.

Best,
-Michael

Re: IPFire on Utilite

[Igor Grinberg]

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

Hi Michael,

On 11/18/13 13:52, Michael Tremer wrote:
> Hello,
> 
> so, I still got some issues that I need to resolve, but all together
> it's not looking that bad.
> I am trying to boot a version of our kernel which boots on the Wandboard
> with the quad-core CPU (i.e. the very same SoC).
> 
> This is what I get:
> 
> CM-FX6 # run boot_ipfire
> mmc2 is current device
> reading boot.scr
> 
> 312 bytes read
> ## Executing script at 13800000
> reading zImage-ipfire-multi
> 
> 3264944 bytes read
> reading uInit-ipfire-multi
> 
> 1971259 bytes read
> reading board.dtb
> 
> 22996 bytes read
> ## Loading init Ramdisk from Legacy Image at 11800000 ...
>    Image Name:   
>    Image Type:   ARM Linux RAMDisk Image (lzma compressed)
>    Data Size:    1971195 Bytes =  1.9 MB
>    Load Address: 00000000
>    Entry Point:  00000000
> ## Flattened Device Tree blob at 12800000
>    Booting using the fdt blob at 0x12800000
>    Loading Ramdisk to 4fe1e000, end 4ffff3fb ... OK
>    Loading Device Tree to 107f7000, end 107ff9d3 ... OK
> 
> Starting kernel ...
> 
> Uncompressing Linux... done, booting the kernel.
> 
> Error: unrecognized/unsupported machine ID (r1 = 0x000010b1).
> 
> Available machine support:
> 
> ID (hex)	NAME
> ffffffff	Generic DT based system
> ffffffff	Freescale i.MX6 Quad/DualLite (Device Tree)
> ffffffff	Freescale i.MX51 (Device Tree Support)
> ffffffff	Freescale i.MX53 (Device Tree Support)
> ffffffff	Generic OMAP5 (Flattened Device Tree)
> ffffffff	Generic OMAP4 (Flattened Device Tree)
> ffffffff	Generic AM33XX (Flattened Device Tree)
> ffffffff	Generic OMAP3-GP (Flattened Device Tree)
> ffffffff	Generic OMAP3 (Flattened Device Tree)
> 0000060a	OMAP3 Beagle Board
> 0000091a	OMAP3 Devkit8000
> 00000667	OMAP LDP board
> 000006ed	OMAP Logic 3530 LV SOM board
> 00000882	Logic OMAP3 Torpedo board
> 00000706	Gumstix Overo
> 000005ff	OMAP3 EVM
> 000006e1	Pandora Handheld Console
> 00000472	OMAP3430 3430SDP board
> 00000dc2	Nokia RM-696 board
> 00000c94	Nokia RM-680 board
> 000007a3	Nokia RX-51 board
> 000009a0	OMAP Zoom3 board
> 000007af	OMAP Zoom2 board
> 000009a1	OMAP 3630SDP board
> 00000cda	Compulab CM-T3730
> 00000925	Compulab CM-T35
> 00000abe	Compulab CM-T3517
> 00000a9d	IGEP OMAP3 module
> 00000928	IGEP v2 board
> 00000959	OMAP3 touchbook Board
> 00000870	OMAP4430 4430SDP board
> 00000ae7	OMAP4 Panda board
> 00000898	OMAP3517/AM3517 EVM
> 00000b74	AM3517/05 CRANEBOARD
> 00000aa2	OMAP3 STALKER
> 00000bbc	ti8148evm
> 00000af0	ti8168evm
> ffffffff	ARM-Versatile Express
> 000008e0	ARM-Versatile Express
> 
> Please check your kernel config and/or bootloader.
> 
> ----
> 
> Clearly the device tree file is loaded and usable (printed it to the
> terminal with fdt addr 0xXXXX; fdt print), but it is not properly passed
> to the kernel which tries to fall back to ATAGS boot mode then.

Hmmm, I remember this worked and also Fedora guys did not complain
on this one. I will investigate what happened here and fix.

Meanwhile, I think your U-Boot binary has support for my development tools.
You can check this in the U-Boot version: it should have "+tools" appended.

If so, try running the *machtype* command with ffffffff parameter:
machtype ffffffff
and then try the normal boot as above.

> 
> As a wild guess, I tried to disable ATAGS that it won't have the chance
> to fall back, but that got me nowhere:
> 
> ## Executing script at 13800000
> reading zImage-ipfire-multi
> 3263712 bytes read
> reading uInit-ipfire-multi
> 1971533 bytes read
> reading board.dtb
> 22996 bytes read
> ## Loading init Ramdisk from Legacy Image at 11800000 ...
>    Image Name:   
>    Image Type:   ARM Linux RAMDisk Image (lzma compressed)
>    Data Size:    1971469 Bytes =  1.9 MB
>    Load Address: 00000000
>    Entry Point:  00000000
> ## Flattened Device Tree blob at 12800000
>    Booting using the fdt blob at 0x12800000
>    Loading Ramdisk to 4fe1e000, end 4ffff50d ... OK
>    Loading Device Tree to 107f7000, end 107ff9d3 ... OK
> 
> Starting kernel ...
> Uncompressing Linux... done, booting the kernel.
> no ATAGS support: can't continue
> 
> So, I suspect that there is something wrong with the device tree support
> in u-boot and that u-boot still passes the machine ID, which I could not
> disable.

Well, it should pass the DT if you give the bootz command a third argument
(which is the DT blob address).

> 
> I did not try to change the u-boot configuration and try to boot that
> version, because if that image won't boot I might brick the device. I
> can do this after we resolved the u-boot-booting-from-sd-card issue, but
> I am sure that you might already have an idea.

I will look into this shortly.

> 
> On Sun, 2013-11-17 at 13:55 +0200, Igor Grinberg wrote:
>>>>> The Utilite I have got, unfortunately comes with an old version of
>>>>> u-boot, which does not support the bootz command that is required to
>>>>> easily boot a multiplatform kernel. Could you please provide the
>>>>> sources so that we can build a version of u-boot with our
>>>>> requirements? It would also be great if this is a more recent one
>>>>> (don't know if there is development going on behind closed doors).
>>>>
>>>> Our U-Boot for Utilite (cm-fx6) has the bootz command supported
>>>> starting from version v2009.08-cm-fx6-0.90. The binary is attached.
>>>> Here is the update procedure for SPI flash:
>>>>
>>>> 1) Get the new binary into the RAM:
>>>>   TFTP commands: tftp 10800000 cm-fx6-u-boot
>>>>   MMC  commands: mmc dev 2 && mmc rescan && fatload mmc 2 10800000 cm-fx6-u-boot
>>>>
>>>> 2) Do not power off Utilite during the next step! Erase and program U-Boot into
>>>>    the SPI flash:
>>>>   sf probe 0:0 && sf erase 0 40000 && sf write 10800000 0 40000
>>>>
>>>> 3) Once the above operation has finished, reset the Utilite and the new U-Boot 
>>>>    will boot.
>>>>
>>>> I've uploaded the U-Boot sources to the Utilite gitorious project:
>>>> https://gitorious.org/utilite
>>>>
>>>> Have a nice hacking!
>>>
>>> I flashed this version of u-boot to my device and it works fine. I tried
>>> to boot it from sdcard, but that did not work with the command you
>>> provided below. Possibly this should start after the first and not
>>> second block (with size of 512 bytes), but I skipped searching for the
>>> problem and decided to flash u-boot instead.
>>
>> The command below is the correct one.
>> I suspect some other problem...
>> Several early units had a hardware race during the boot ROM start up
>> and it affected the boot capabilities of those units.
>> This was fixed in all later units, but I'd like to check if this is
>> the case with your Utilite.
>> Can you please provide me the content of the white sticker
>> on the bottom of the Utilite?
> 
> I will send you this in private in a minute.
> 
>>> Also, thank you for the source code. Are there any plans to get all your
>>> modifications upstream or is it intentional to remain with the version
>>> from 2009?
>>
>> Well, yes, we plan to upstream the Utilite (cm-fx6) U-Boot (and kernel)
>> support, but this will take us some time, so meanwhile we stick to 2009
>> (which is the one used in Freescale BSP). 
> 
> Indeed would getting all your code upstream make it much more easy for
> the distributors to provide support for Utilite.
> 
> Best,
> -Michael
> 
> 

-- 
Regards,
Igor.

Re: IPFire on Utilite

[Michael Tremer]

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

Morning,

On Tue, 2013-11-19 at 15:09 +0200, Igor Grinberg wrote:
> Hi Michael,
> 
> On 11/18/13 13:52, Michael Tremer wrote:
> > Hello,
> > 
> > so, I still got some issues that I need to resolve, but all together
> > it's not looking that bad.
> > I am trying to boot a version of our kernel which boots on the Wandboard
> > with the quad-core CPU (i.e. the very same SoC).
> > 
> > This is what I get:
> > 
> > CM-FX6 # run boot_ipfire
> > mmc2 is current device
> > reading boot.scr
> > 
> > 312 bytes read
> > ## Executing script at 13800000
> > reading zImage-ipfire-multi
> > 
> > 3264944 bytes read
> > reading uInit-ipfire-multi
> > 
> > 1971259 bytes read
> > reading board.dtb
> > 
> > 22996 bytes read
> > ## Loading init Ramdisk from Legacy Image at 11800000 ...
> >    Image Name:   
> >    Image Type:   ARM Linux RAMDisk Image (lzma compressed)
> >    Data Size:    1971195 Bytes =  1.9 MB
> >    Load Address: 00000000
> >    Entry Point:  00000000
> > ## Flattened Device Tree blob at 12800000
> >    Booting using the fdt blob at 0x12800000
> >    Loading Ramdisk to 4fe1e000, end 4ffff3fb ... OK
> >    Loading Device Tree to 107f7000, end 107ff9d3 ... OK
> > 
> > Starting kernel ...
> > 
> > Uncompressing Linux... done, booting the kernel.
> > 
> > Error: unrecognized/unsupported machine ID (r1 = 0x000010b1).
> > 
> > Available machine support:
> > 
> > ID (hex)	NAME
> > ffffffff	Generic DT based system
> > ffffffff	Freescale i.MX6 Quad/DualLite (Device Tree)
> > ffffffff	Freescale i.MX51 (Device Tree Support)
> > ffffffff	Freescale i.MX53 (Device Tree Support)
> > ffffffff	Generic OMAP5 (Flattened Device Tree)
> > ffffffff	Generic OMAP4 (Flattened Device Tree)
> > ffffffff	Generic AM33XX (Flattened Device Tree)
> > ffffffff	Generic OMAP3-GP (Flattened Device Tree)
> > ffffffff	Generic OMAP3 (Flattened Device Tree)
> > 0000060a	OMAP3 Beagle Board
> > 0000091a	OMAP3 Devkit8000
> > 00000667	OMAP LDP board
> > 000006ed	OMAP Logic 3530 LV SOM board
> > 00000882	Logic OMAP3 Torpedo board
> > 00000706	Gumstix Overo
> > 000005ff	OMAP3 EVM
> > 000006e1	Pandora Handheld Console
> > 00000472	OMAP3430 3430SDP board
> > 00000dc2	Nokia RM-696 board
> > 00000c94	Nokia RM-680 board
> > 000007a3	Nokia RX-51 board
> > 000009a0	OMAP Zoom3 board
> > 000007af	OMAP Zoom2 board
> > 000009a1	OMAP 3630SDP board
> > 00000cda	Compulab CM-T3730
> > 00000925	Compulab CM-T35
> > 00000abe	Compulab CM-T3517
> > 00000a9d	IGEP OMAP3 module
> > 00000928	IGEP v2 board
> > 00000959	OMAP3 touchbook Board
> > 00000870	OMAP4430 4430SDP board
> > 00000ae7	OMAP4 Panda board
> > 00000898	OMAP3517/AM3517 EVM
> > 00000b74	AM3517/05 CRANEBOARD
> > 00000aa2	OMAP3 STALKER
> > 00000bbc	ti8148evm
> > 00000af0	ti8168evm
> > ffffffff	ARM-Versatile Express
> > 000008e0	ARM-Versatile Express
> > 
> > Please check your kernel config and/or bootloader.
> > 
> > ----
> > 
> > Clearly the device tree file is loaded and usable (printed it to the
> > terminal with fdt addr 0xXXXX; fdt print), but it is not properly passed
> > to the kernel which tries to fall back to ATAGS boot mode then.
> 
> Hmmm, I remember this worked and also Fedora guys did not complain
> on this one. I will investigate what happened here and fix.
> 
> Meanwhile, I think your U-Boot binary has support for my development tools.
> You can check this in the U-Boot version: it should have "+tools" appended.
> 
> If so, try running the *machtype* command with ffffffff parameter:
> machtype ffffffff
> and then try the normal boot as above.

Thank you very much for this hint. I checked it out and unfortunately,
it is not working. The kernel still gets no DT passed and refuses to
boot.

*Exactly* the same kernel boots on a Wandboard Quad (with DT) and
therefore I think that our kernel is fine.

However, I *am* reading the DT file from the SD card and I am passing
the memory address it was loaded to to the bootz command. I checked this
twice and changed the addresses, but that didn't help either.

U-Boot recognized that there is a DT file available and copies it to an
other address. Hence I guess that everything is loaded fine.

> 
> > 
> > As a wild guess, I tried to disable ATAGS that it won't have the chance
> > to fall back, but that got me nowhere:
> > 
> > ## Executing script at 13800000
> > reading zImage-ipfire-multi
> > 3263712 bytes read
> > reading uInit-ipfire-multi
> > 1971533 bytes read
> > reading board.dtb
> > 22996 bytes read
> > ## Loading init Ramdisk from Legacy Image at 11800000 ...
> >    Image Name:   
> >    Image Type:   ARM Linux RAMDisk Image (lzma compressed)
> >    Data Size:    1971469 Bytes =  1.9 MB
> >    Load Address: 00000000
> >    Entry Point:  00000000
> > ## Flattened Device Tree blob at 12800000
> >    Booting using the fdt blob at 0x12800000
> >    Loading Ramdisk to 4fe1e000, end 4ffff50d ... OK
> >    Loading Device Tree to 107f7000, end 107ff9d3 ... OK
> > 
> > Starting kernel ...
> > Uncompressing Linux... done, booting the kernel.
> > no ATAGS support: can't continue
> > 
> > So, I suspect that there is something wrong with the device tree support
> > in u-boot and that u-boot still passes the machine ID, which I could not
> > disable.
> 
> Well, it should pass the DT if you give the bootz command a third argument
> (which is the DT blob address).
> 
> > 
> > I did not try to change the u-boot configuration and try to boot that
> > version, because if that image won't boot I might brick the device. I
> > can do this after we resolved the u-boot-booting-from-sd-card issue, but
> > I am sure that you might already have an idea.
> 
> I will look into this shortly.
> 
> > 
> > On Sun, 2013-11-17 at 13:55 +0200, Igor Grinberg wrote:
> >>>>> The Utilite I have got, unfortunately comes with an old version of
> >>>>> u-boot, which does not support the bootz command that is required to
> >>>>> easily boot a multiplatform kernel. Could you please provide the
> >>>>> sources so that we can build a version of u-boot with our
> >>>>> requirements? It would also be great if this is a more recent one
> >>>>> (don't know if there is development going on behind closed doors).
> >>>>
> >>>> Our U-Boot for Utilite (cm-fx6) has the bootz command supported
> >>>> starting from version v2009.08-cm-fx6-0.90. The binary is attached.
> >>>> Here is the update procedure for SPI flash:
> >>>>
> >>>> 1) Get the new binary into the RAM:
> >>>>   TFTP commands: tftp 10800000 cm-fx6-u-boot
> >>>>   MMC  commands: mmc dev 2 && mmc rescan && fatload mmc 2 10800000 cm-fx6-u-boot
> >>>>
> >>>> 2) Do not power off Utilite during the next step! Erase and program U-Boot into
> >>>>    the SPI flash:
> >>>>   sf probe 0:0 && sf erase 0 40000 && sf write 10800000 0 40000
> >>>>
> >>>> 3) Once the above operation has finished, reset the Utilite and the new U-Boot 
> >>>>    will boot.
> >>>>
> >>>> I've uploaded the U-Boot sources to the Utilite gitorious project:
> >>>> https://gitorious.org/utilite
> >>>>
> >>>> Have a nice hacking!
> >>>
> >>> I flashed this version of u-boot to my device and it works fine. I tried
> >>> to boot it from sdcard, but that did not work with the command you
> >>> provided below. Possibly this should start after the first and not
> >>> second block (with size of 512 bytes), but I skipped searching for the
> >>> problem and decided to flash u-boot instead.
> >>
> >> The command below is the correct one.
> >> I suspect some other problem...
> >> Several early units had a hardware race during the boot ROM start up
> >> and it affected the boot capabilities of those units.
> >> This was fixed in all later units, but I'd like to check if this is
> >> the case with your Utilite.
> >> Can you please provide me the content of the white sticker
> >> on the bottom of the Utilite?
> > 
> > I will send you this in private in a minute.
> > 
> >>> Also, thank you for the source code. Are there any plans to get all your
> >>> modifications upstream or is it intentional to remain with the version
> >>> from 2009?
> >>
> >> Well, yes, we plan to upstream the Utilite (cm-fx6) U-Boot (and kernel)
> >> support, but this will take us some time, so meanwhile we stick to 2009
> >> (which is the one used in Freescale BSP). 
> > 
> > Indeed would getting all your code upstream make it much more easy for
> > the distributors to provide support for Utilite.
> > 
> > Best,
> > -Michael
> > 
> > 
>