Re: IPFire on Utilite

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

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