Re: Questions regarding armhf port for Raspberry Pi
On Fri, Mar 23, 2012 at 3:21 AM, Wookey wrote:
> The set of packages you install and the set of packages linked-against
> will be the same, except for static linking, and I beleive that to be
> very rare, quite possibly non-existent in a base install. So I don't
> think this issue meaningfully changes your problem-size.
>
I came across something that should help significantly with the problem of
determining if there is ARMv7 code leakage into my recompiled armhf
packages that should be ARMv6 pure.
Basically, I can use the 'readelf -A' command to determine when a v6
executable has been linked against a v7 static library, thus causing
contamination of v7 code into my packages.
It seems to work as follows. Below, in my armhf v6 chroot environment I
compiled the hello.c program using my rebuilt v6 gcc and linked it against
the rebuilt v6 standard C libraries. As shown below 'readelf -A' does
indeed properly report the resulting binary as pure v6 code.
———
$ cat hello.c
#include
int main()
{
printf("Hello world.\n");
return 0;
}
$ gcc -c hello.c
$ gcc -o hello hello.o
$ readelf -A hello
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed
$
———
Below, I went outside my chroot environment and simply linked the same v6
hello.o file created above with the standard armhf v7 standard C library.
Indeed, the resulting binary is now flagged as being v7. Because the v6
object file was linked against a v7 library, the binary is now flagged as
being v7 code.
———
$ gcc -o hello hello.o
$ readelf -A hello
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "7-A"
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: VFPv3-D16
Tag_ABI_PCS_wchar_t: 4
Tag_ABI_FP_denormal: Needed
Tag_ABI_FP_exceptions: Needed
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_align_needed: 8-byte
Tag_ABI_align_preserved: 8-byte, except leaf SP
Tag_ABI_enum_size: int
Tag_ABI_HardFP_use: SP and DP
Tag_ABI_VFP_args: VFP registers
Tag_DIV_use: Not allowed
$
———
The result of this means that it should be fairly straight forward to
create a filter for every v6 armhf package created for the Raspberry Pi
platform to flag and reject packages that have been contaminated with v7
code. This still doesn't tell me the exact source of the contamination
(ie. which library caused the problem), but that shouldn't be too difficult
to find out. This may also serve to filter out any v7 binaries caused by
v7 assembly instructions or unexpected manipulation of the gcc options to
produce v7 code (but I have to test this out).
Although I haven't yet created an automated test script, I was able to
manually use 'readelf -A' to determine that a number of the binaries I
created as I recompiled packages have v7 code leaking into them. I was
able to fix this by going back and correcting the libraries they link
against to be v6 code and then verified the newly created packages were
pure v6 code.
Unless there is something I'm overlooking, I should now be able to
recompile armhf packages for ARMv6+VFP and be reasonably confident they
will run on the Raspberry Pi platform without actually having to smoketest
every package. Of course, they'll all be tested in the end on the actual
platform, but this should aid my build process.
Is there anything I'm overlooking here?
Mike
Re: ARM kernel cross compilation issues for iMX53
On Mon, Mar 26, 2012 at 7:48 PM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > I am using u-boot checked out from git a few minutes > ago, plus a set of 9 patches to enable sata support from > http://lists.denx.de/pipermail/u-boot/2012-February/118523.html > > Len, I also used those patches and they worked for me. To get things going, I also had to apply the patch at the following link as well: https://raw.github.com/RobertCNelson/Bootloader-Builder/master/patches/0003-net-eth.c-fix-eth_write_hwaddr-to-use-dev-enetaddr-a.patch Were you able to examine the u-boot and kernel image I posted earlier today in this thread? I realize you want to build your own (I did as well), but if you can verify those files work for you I can then walk you through building exact copies of those binaries in either a cross development environment under Ubuntu or on the iMX53 itself. Mike
Re: ARM kernel cross compilation issues for iMX53
On Mon, Mar 26, 2012 at 10:48:16PM -0400, Lennart Sorensen wrote:
> I am still trying to get the debian kernel build to do something.
>
> This isn't doing much yet:
>
> MX53LOCO U-Boot > setenv bootargs root=/dev/sda1 rw rootwait
> console=ttymxc0,${baudrate}
> MX53LOCO U-Boot > sata init
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part
> SATA Device Info:
> S/N: 5SV6CHMY
> Product model number: ST9160310AS
> Firmware version: 0303
> Capacity: 312581808 sectors
> MX53LOCO U-Boot > ext2load sata 0:1 ${loadaddr} /boot/uImage-3.2.0-2-mx5
> Loading file "/boot/uImage-3.2.0-2-mx5" from sata device 0:1 (hda1)
> 1979872 bytes read
> MX53LOCO U-Boot > ext2load sata 0:1 0x7100 /boot/uInitrd-3.2.0-2-mx5
> Loading file "/boot/uInitrd-3.2.0-2-mx5" from sata device 0:1 (hda1)
> 4312970 bytes read
> MX53LOCO U-Boot > bootm ${loadaddr} 0x7100
> ## Booting kernel from Legacy Image at 7080 ...
>Image Name: uImage
>Image Type: ARM Linux Kernel Image (uncompressed)
>Data Size:1979808 Bytes = 1.9 MiB
>Load Address: 7080
>Entry Point: 7080
>Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 7100 ...
>Image Name: uImage
>Image Type: ARM Linux RAMDisk Image (uncompressed)
>Data Size:4312906 Bytes = 4.1 MiB
>Load Address: 7100
>Entry Point: 7100
>Verifying Checksum ... OK
>XIP Kernel Image ... OK
> OK
>
> Starting kernel ...
>
> And that's it.
>
> I am using u-boot checked out from git a few minutes
> ago, plus a set of 9 patches to enable sata support from
> http://lists.denx.de/pipermail/u-boot/2012-February/118523.html
>
> I guess I might have used mkimage incorrectly. I will have to try
> flash-kernel.
On the other hand using the ubuntu 2.6.35 kernel like this works fine:
MX53LOCO U-Boot > setenv bootargs root=/dev/sda1 rw rootwait
video=mxcdi0fb:RGB24,1080P60
MX53LOCO U-Boot > set bootargs ${bootargs} root=/dev/sda1 rw rootwait
MX53LOCO U-Boot > sata init
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part
SATA Device Info:
S/N: 5SV6CHMY
Product model number: ST9160310AS
Firmware version: 0303
Capacity: 312581808 sectors
MX53LOCO U-Boot > mmc read 0 ${loadaddr} 0x800 0x1800
MMC read: dev # 0, block # 1887436800, count 2048 ... MMC: block number
0x70800800 exceeds max(0x75c000)
0 blocks read: ERROR
MX53LOCO U-Boot > mmc read ${loadaddr} 0x800 0x1800;
MMC read: dev # 0, block # 2048, count 6144 ... 6144 blocks read: OK
MX53LOCO U-Boot > bootm
## Booting kernel from Legacy Image at 7080 ...
Image Name: Linux-2.6.35.3-744-g27fdf7b
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:2967420 Bytes = 2.8 MiB
Load Address: 70008000
Entry Point: 70008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Linux version 2.6.35.3-744-g27fdf7b (r80115@bluebell) (gcc version 4.4.4
(4.4.4_09.06.2010) ) #1 PREEMPT Thu Jan 27 15:10:16 CST 2011
CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[snip]
I wonder if the fact the load address of the uImage is slightly different
could be a problem. Hmm. I seem to have used 7080 rather than
70008000.
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120327025512.gs10...@caffeine.csclub.uwaterloo.ca
Re: ARM kernel cross compilation issues for iMX53
On Mon, Mar 26, 2012 at 04:40:53PM -0700, Mike Thompson wrote:
> I now have a functioning Debian Linux 3.2.12 kernel with the armhf runtime
> on my iMX53 Quick Start Board. Attached below is a link to a compressed
> tar file containing the Debian packages to install a custom version of the
> kernel and a working u-boot compatible with the kernel. Also included are
> notes and a boot directory containing the uImage and uInitrd that should
> help with bootstrapping your own armhf installation on an iMX53 Quick Start
> Board.
>
> http://home.comcast.net/~michael.p.thompson/mx5/debian_linux_3.2.12_mx5.tar.gz
>
> Please not that the kernel provided is quite minimal and I can only vouch
> that the serial port, ethernet, SATA interface and SD interface are
> working. If you get VGA, USB and other peripherals works, please let me
> know.
>
> I would like to thank everyone in this thread for providing clues along the
> way that ultimately allowed me to get to a running system. Hopefully this
> collection of files will be useful to other people trying to get a recent
> Linux kernel and armhf runtime functioning on an iMX53 Quick Start Board.
> Let me know if you have any questions.
I am still trying to get the debian kernel build to do something.
This isn't doing much yet:
MX53LOCO U-Boot > setenv bootargs root=/dev/sda1 rw rootwait
console=ttymxc0,${baudrate}
MX53LOCO U-Boot > sata init
AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part
SATA Device Info:
S/N: 5SV6CHMY
Product model number: ST9160310AS
Firmware version: 0303
Capacity: 312581808 sectors
MX53LOCO U-Boot > ext2load sata 0:1 ${loadaddr} /boot/uImage-3.2.0-2-mx5
Loading file "/boot/uImage-3.2.0-2-mx5" from sata device 0:1 (hda1)
1979872 bytes read
MX53LOCO U-Boot > ext2load sata 0:1 0x7100 /boot/uInitrd-3.2.0-2-mx5
Loading file "/boot/uInitrd-3.2.0-2-mx5" from sata device 0:1 (hda1)
4312970 bytes read
MX53LOCO U-Boot > bootm ${loadaddr} 0x7100
## Booting kernel from Legacy Image at 7080 ...
Image Name: uImage
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:1979808 Bytes = 1.9 MiB
Load Address: 7080
Entry Point: 7080
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 7100 ...
Image Name: uImage
Image Type: ARM Linux RAMDisk Image (uncompressed)
Data Size:4312906 Bytes = 4.1 MiB
Load Address: 7100
Entry Point: 7100
Verifying Checksum ... OK
XIP Kernel Image ... OK
OK
Starting kernel ...
And that's it.
I am using u-boot checked out from git a few minutes
ago, plus a set of 9 patches to enable sata support from
http://lists.denx.de/pipermail/u-boot/2012-February/118523.html
I guess I might have used mkimage incorrectly. I will have to try
flash-kernel.
--
Len Sorensen
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20120327024816.gr10...@caffeine.csclub.uwaterloo.ca
Re: ARM kernel cross compilation issues for iMX53
I now have a functioning Debian Linux 3.2.12 kernel with the armhf runtime on my iMX53 Quick Start Board. Attached below is a link to a compressed tar file containing the Debian packages to install a custom version of the kernel and a working u-boot compatible with the kernel. Also included are notes and a boot directory containing the uImage and uInitrd that should help with bootstrapping your own armhf installation on an iMX53 Quick Start Board. http://home.comcast.net/~michael.p.thompson/mx5/debian_linux_3.2.12_mx5.tar.gz Please not that the kernel provided is quite minimal and I can only vouch that the serial port, ethernet, SATA interface and SD interface are working. If you get VGA, USB and other peripherals works, please let me know. I would like to thank everyone in this thread for providing clues along the way that ultimately allowed me to get to a running system. Hopefully this collection of files will be useful to other people trying to get a recent Linux kernel and armhf runtime functioning on an iMX53 Quick Start Board. Let me know if you have any questions. Mike Thompson
Re: ARM kernel cross compilation issues for iMX53
On Mon, Mar 26, 2012 at 02:03:23PM +0200, Hector Oron wrote: > Yes, Debian armhf kernel supports i.MX53 LOCO boards. That's good to know. > Configure u-boot as described at (make sure partition is <1GB), I > usually use 100MB > < http://blog.einval.com/2011/09/05#armhf_buildds > > > Install debian kernel package for mx5. Make sure initramfs is > generated. Run later flash-kernel (>=3.0~rc.4) to generate > uImage/uInitrd. Oh I just did the mkimage steps manually. I am so used to uboot that I didn't even think of looking for a tool to do it. I better check that flash-kernel doesn't use some magic options that I missed. > Being mainline kernel, expect few things to work, at least SATA, > serial and MMC/SD support is there. I probably need a newer u-boot or something. I am poking at that now. If MMC/SD and SATA and serial work, then I should be OK for now. Graphics would be nice, but not essential and would of course need USB as well in that case. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120326141617.gq10...@caffeine.csclub.uwaterloo.ca
Re: Getting Debian running on an EfikaMX Smartbook
On Sat, 24 Mar 2012 21:50:50 +0100 Martin Lucina wrote: > It says there, right in the first post: > > "NOTE: No 2D/3D drivers have been included, as I'm in the process of > converting these to multiarch and setting up the repository for easier > download via apt-get. Stay tuned." Right you are, my message was unclear, I meant 2D accelerated drivers (for video playback,etc). Using fbdev works just fine for unaccelerated 2D graphics. > Can you please confirm whether or not the image > "efikamx-armhf-20120226.img" is supposed to boot out of the box on the > Smartbook? Yes that's the one. > I understand that there would be work and time required to get display > drivers into the mainline; that's fine. But presumably at least the > pre-built image above can actually be used to boot a Smartbook today? yes. > As for the installer script, I only need that if I want to > rebuild/customize your image from scratch, right? or to install to the internal ssd, yes. > Yes, thanks, you've certainly reassured me -- apologies if my original post > was somewhat ranty, I just had the feeling I had purchased another random > embedded thingy with two-year old software on it I could do nothing about > :-) no need to apologize, ARM has only just started to gain consumer attention and some things are a bit rough and experimental, though I believe in 2-3 years time it will be as common to buy an ARM-based laptop as it is for a x86 one (fingers crossed) :) -- Konstantinos Margaritis -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120326162105.ccd1d7c927714ec1ac9ce...@genesi-usa.com
Re: ARM kernel cross compilation issues for iMX53
Hello, 2012/3/25 Lennart Sorensen : > On Mon, Mar 19, 2012 at 04:13:22PM +, Steve McIntyre wrote: >> They're fine for us. I started using the Freescale 2.6.35 kernel, then >> moved over to mainline with 3.2.0. Networking and SATA work fine >> there, but USB is still not quite there yet... > Are you using Debian's 3.2.0-2-mx5 kernel, or building your own from > scratch? > > I have been trying to boot the 3.2.0-2-mx5 kernel on the mx53 QSB, > and no luck so far. > > The kernel config says IMX53LOCO=y, which to me means the kernel should > support this board. Yes, Debian armhf kernel supports i.MX53 LOCO boards. Configure u-boot as described at (make sure partition is <1GB), I usually use 100MB < http://blog.einval.com/2011/09/05#armhf_buildds > Install debian kernel package for mx5. Make sure initramfs is generated. Run later flash-kernel (>=3.0~rc.4) to generate uImage/uInitrd. Being mainline kernel, expect few things to work, at least SATA, serial and MMC/SD support is there. Cheers, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caodfweh_kjw1o3m45j3by_50v72rf6iv9ifklut2wrv963b...@mail.gmail.com
Re: ARM kernel cross compilation issues for iMX53
Lennart Sorensen wrote (ao): > Well so far I don't even get any kernel messages at boot, which isn't > a good start. Try with the bootparameters 'earlyprintk' (and maybe 'keep_bootcon'). For earlyprintk you need CONFIG_EARLY_PRINTK=y Sander -- Humilis IT Services and Solutions http://www.humilis.net -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120326063324.ga7...@attic.humilis.net
