From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: sig-arm@lists.ipfire.org Subject: Re: IPFire on Utilite Date: Wed, 20 Nov 2013 12:22:29 +0100 Message-ID: <1384946549.6453.10.camel@rice-oxley.tremer.info> In-Reply-To: <528B6300.9020107@compulab.co.il> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8373309713300629428==" List-Id: --===============8373309713300629428== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Morning, On Tue, 2013-11-19 at 15:09 +0200, Igor Grinberg wrote: > Hi Michael, >=20 > On 11/18/13 13:52, Michael Tremer wrote: > > Hello, > >=20 > > 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). > >=20 > > This is what I get: > >=20 > > CM-FX6 # run boot_ipfire > > mmc2 is current device > > reading boot.scr > >=20 > > 312 bytes read > > ## Executing script at 13800000 > > reading zImage-ipfire-multi > >=20 > > 3264944 bytes read > > reading uInit-ipfire-multi > >=20 > > 1971259 bytes read > > reading board.dtb > >=20 > > 22996 bytes read > > ## Loading init Ramdisk from Legacy Image at 11800000 ... > > Image Name: =20 > > Image Type: ARM Linux RAMDisk Image (lzma compressed) > > Data Size: 1971195 Bytes =3D 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 > >=20 > > Starting kernel ... > >=20 > > Uncompressing Linux... done, booting the kernel. > >=20 > > Error: unrecognized/unsupported machine ID (r1 =3D 0x000010b1). > >=20 > > Available machine support: > >=20 > > 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 > >=20 > > Please check your kernel config and/or bootloader. > >=20 > > ---- > >=20 > > 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. >=20 > Hmmm, I remember this worked and also Fedora guys did not complain > on this one. I will investigate what happened here and fix. >=20 > 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. >=20 > 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. >=20 > >=20 > > As a wild guess, I tried to disable ATAGS that it won't have the chance > > to fall back, but that got me nowhere: > >=20 > > ## 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: =20 > > Image Type: ARM Linux RAMDisk Image (lzma compressed) > > Data Size: 1971469 Bytes =3D 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 > >=20 > > Starting kernel ... > > Uncompressing Linux... done, booting the kernel. > > no ATAGS support: can't continue > >=20 > > 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. >=20 > Well, it should pass the DT if you give the bootz command a third argument > (which is the DT blob address). >=20 > >=20 > > 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. >=20 > I will look into this shortly. >=20 > >=20 > > 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 ne= w U-Boot=20 > >>>> 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? > >=20 > > I will send you this in private in a minute. > >=20 > >>> 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).=20 > >=20 > > Indeed would getting all your code upstream make it much more easy for > > the distributors to provide support for Utilite. > >=20 > > Best, > > -Michael > >=20 > >=20 >=20 --===============8373309713300629428==--