Re: IPFire on Utilite

[Michael Tremer <michael.tremer@ipfire.org>]

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