ArchlinuxARM on Raspberry Pi


146 posts   Page 3 of 6   1, 2, 3, 4, 5, 6
by pepedog » Tue Jan 31, 2012 6:59 pm
Interesting stuff. If we had some way of finding out hard is XX% quicker than soft.

Back to memory issue, I wrote to Dom, it appears the blob that brings up the system via the GPU decides what ram is allocated, it's called start.elf

Dom sent me another to try, first tip is don't rename it start.efl - it won't boot. Now I have 224M to play with.

There is another blob that is midway, but Dom said a new one is being written that hands back unused memory.
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by liamfraser280 » Tue Jan 31, 2012 9:46 pm
Sounds good pepedog.

Are you hosting the torrent tracker yourself? The myplugbox site looks like it is probably your own?

If so what software are you using :) ?

Cheers,

Liam.
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by pepedog » Tue Jan 31, 2012 11:15 pm
Yes, http://myplugbox.com/ is one of my servers, this one is a dockstar.

Apache (yes, I know a little heavy), transmission is seeding, and rivettracker for tracking. Also postfix, dovecot, minidlna, and other things running.
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by Chromatix » Wed Feb 01, 2012 12:37 pm
I will run some tests on my TrimSlice.  This has a considerably newer version of ARM than the R-Pi, but it has the advantage of being available and I have got both softfp and hardfloat environments running on it (simultaneously - chroot is fun).

They both use the slightly older 4.5.x series of GCC, which Phoronix appears to show running better than 4.6.x.  A quick look at it's output makes me wince at the inefficiency, but GCC has never done very well with RISC architectures, and the hardfloat is very obviously much cleaner than the softfp or softfloat.

The Cortex-A9 in the TrimSlice is an OoO core, so should if anything be *less* sensitive to suboptimal code than the ARM11 core.  In particular the penalty for moving data from VFP to integer core and back - a common feature of softfp code - may be less.

I have already determined that Clang/LLVM 2.8 doesn't seem to support hardfloat properly - it produces identical code for a trivial FP function as for softfp.  Maybe this is improved in the latest version.
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by pepedog » Wed Feb 01, 2012 2:07 pm
Raspberry Pi as a PVR

I just built tvheadend.
Rasberry Pi with Pinnacle 72e, tuned and just recorded a show, supplied indoor 5 inch aerial gave a choppy signal, but it works.

Slightly added to kernel for adding dib0700 modules

Must try minidlna to see if it streams
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by Chromatix » Wed Feb 01, 2012 4:20 pm
Wrote a quick benchmark, which sums a few hundred million dot-products without (explicitly) hitting RAM.  The dot-product is in it's own function:

float dotProduct(vec2 a, vec2 b)

{

return a.x * b.x + a.y * b.y;

}

Four 32-bit floats can be passed in registers for all ABIs - just different registers.  With the hard ABI, the above function should compile to exactly three instructions:

fmul s0,s0,s2

fmac s0,s1,s3

bx lr

In practice GCC compiles it to five or six instructions depending on whether fast-math is specified.  The extra instructions are trivial and redundant.  No matter...

When inlining the above function is allowed, the function call overhead disappears (very significant with softfp) and additionally a loop-invariant optimisation becomes available in the test function (significant to all ABIs).

In softfloat mode, the finished binary is bloated by a complete set of AEABI FP routines, even though only a few are actually used.  The size of these routines reflects the amount of work required to replace each VFP instruction using the integer core.

Most striking however are the performance differences:

softfloat no-inline: 75s

softfloat inline: 55s

softfp no-inline: 14.5s

softfp inline: 5.5s

hardfloat no-inline: TBD

hardfloat inline: TBD

That's a tenfold difference between softfloat and softfp when the function call overhead is elided, and a fivefold difference even with softfp's artificial handicap.
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by Chromatix » Wed Feb 01, 2012 8:28 pm
Adding more numbers:

hardfloat no-inline: 8.8s

hardfloat inline: 5.5s (as expected, identical to softfp inline)

Thumb1 softfloat no-inline: 77.7s

Thumb1 softfloat inline: 65s

In Thumb mode, ARM11 cannot use the VFP at all - this also means that Thumb mode is incompatible with hardfloat as far as Linux' dynamic linker is concerned, even if no FP arguments are passed around at all.  The difference in performance versus ARM mode is still quite large, considering how much time is spent in library routines implementing the FP operations.

The 5.7s difference between hardfloat and softfp corresponds to a 16-cycle difference per call - on a Cortex-A9.  That's pretty big, and likely to be at least slightly bigger still on the simpler and narrower ARM11 core.

(NB: while the numbers were generated on Cortex-A9 hardware, the code was built as if for the ARM1176JZF-S in the R-Pi.  Hence the reference to Thumb1 instead of Thumb2, which *can* use the VFP directly and participate in a hardfloat environment.)
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by Chromatix » Thu Feb 02, 2012 6:13 pm
Also good news: Clang/LLVM 3.0 *do* support hardfloat mode.
The key to knowledge is not to rely on people to teach you it.
User avatar
Posts: 430
Joined: Mon Jan 02, 2012 7:00 pm
Location: Helsinki
by pepedog » Sat Feb 18, 2012 9:33 pm
I released another arch rootfs. In the form of a zipped dd this time.

This one has 224Mb for system, uses 26Mb to prompt

http://myplugbox.com/rpi-archl.....12.torrent
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by pepedog » Sun Feb 19, 2012 6:53 pm
Oh, no, hold fire downloading, going to rebuild with other requested features.
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by Benedict White » Mon Feb 20, 2012 1:20 am
pepedog said:


Oh, no, hold fire downloading, going to rebuild with other requested features.


Keep up the good work.
Posts: 225
Joined: Sat Dec 24, 2011 12:24 am
by pepedog » Sat Mar 03, 2012 12:36 am
And it"s all back, I woke at 830 and missed out.
Anyway, a new archlinuxarm rootfs is in existence, will be appearing on downloads page soon, featuring a L2 cache kernel.
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by Jessie » Sat Mar 03, 2012 4:39 am
@pepedog Is there any reason why PlugUI wouldn't work on the R-Pi?  I'm looking at writing a nice tutorial and possibly a video on getting a NAS going with Arch on the Pi.  I don't have a R-Pi, but I am currently overhauling my NAS setup with a PogoPlug series 4 with Arch.  I will of course test it all out when I get an R-Pi.
Click my website link under my avitar for the RetroPie 2.3 guide in progress.
User avatar
Forum Moderator
Forum Moderator
Posts: 1599
Joined: Fri Nov 04, 2011 7:40 pm
Location: C/S CO USA
by pepedog » Sat Mar 03, 2012 10:06 am
I haven"t tried plugui in a while, I"m 100% certain it will work, written by one of our guys in python. The guy is not actually in a python, nor with python organisation, but code is in python language.
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by liamfraser280 » Sat Mar 03, 2012 3:08 pm
Hi Pepedog!

Noticed you were around on the forums and thought I'd just let you know that I've emailed you with regards to your ArchLinux image in case you hadn't seen it yet!

Cheers,

Liam.
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by pepedog » Sat Mar 03, 2012 6:43 pm
Thanks Liam
Dave
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by maribu » Tue Mar 06, 2012 12:49 pm
Hi, there!

Has someone else tried to boot the official Image via qemu?

I tried it this way: I copied all files from the boot Partition and started qemu with the following command:

qemu-system-arm -M versatilepb -cpu arm1136-r2 -hda archlinuxarm-01-03-2012.img -kernel kernel.img -m 192 -append "root=/dev/sda2"

But I only get a black screen. If I use the same image, but a different kernel (also a raspberry pi kernel), the system boots fine.

I would prefer to boot with the arch-kernel. Has someone an idea what to do?

Thanks,

Marian
User avatar
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm
by grumpyoldgit » Tue Mar 06, 2012 1:40 pm
I've raised this in another thread. I can get it up and running but still have a couple of issues. And no, before you ask, I have no understanding of what I am doing. I'm just following other people's instructions and advice!

http://www.raspberrypi.org/for.....m-and-qemu
User avatar
Posts: 1454
Joined: Thu Jan 05, 2012 12:20 pm
by pepedog » Tue Mar 06, 2012 1:49 pm
I think you have to have

-append "enable_l2cache=1"

or maybe

-append "kernel.l2cache=1"

1st one lives on config.txt on real rpi, but think format is different if in cmdline.txt (2nd one a guess)

That's the only diff between kernels, if you got it you must state it, if you haven't you must not state it, or boot fails.

I don't have qemu to test.
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by maribu » Tue Mar 06, 2012 6:18 pm
Thanks Grumpyoldgit and pepedog!

@ pepedog: I tried with this command line, but it doesn't work. But with the "-append" command you specify kernel parameter. I think enabling the L2-Cache would be an option for qemu, not the kernel. I haven't found an option to tell qemu to enable the L2 cache in the manual of qemu or via google. Maybe it isn't even the cpu emulated by qemu which isn't supported by this kernel. Actually I think it is a good thing that the Raspberry Pi kernel of Arch does not support hardware which is not in the Pi.

@Grumpyoldgit: I already found this thread. Actually I found the kernel image with which I can boot my sd-card via qemu there. But I thought I may get more information in this thread.

Thanks for your help,

Marian
User avatar
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm
by maribu » Mon Mar 12, 2012 5:48 pm
Hello to everybody!

I'm still not giving up trying to boot Arch Linux on qemu with the original Raspberry Pi Kernel. First I thought it could be some driver missing, because qemu does not emulate exactly the same hardware the Raspberry Pi has. But booting with this kernel doesn't even show a kernel panic - the screen just remains black. I tried it again with the Arch Linux kernel for the Pogo Plug (or something like that) which uses the same instruction set as the Raspberry Pi (ARM v6) with the same result: Screen remains black.

Looking in the manual ("man qemu") I found out that the "-kernel" switch of qemu is expecting a bzImage of the kernel. In the PKGBUILD of the Arch Linux kernel for the Raspberry Pi I found following command:

/usr/bin/python2 imagetool-uncompressed.py

I'm not an expert, but does this mean the Kernel is not compressed and qemu doesn't boot because it is expecting an compressed Image? If so, would it be possible to "re-pack" the original kernel in an compressed image so I can boot it with qemu and even can load the kernel modules within the Arch Linux filesystem?

I just started to compile the kernel. This just take bloody ages, especially in an emulated environment. If I'm able to generate an image bootable with qemu I'll be back an tell you.

Thanks for reading,

Marian
User avatar
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm
by maribu » Tue Mar 13, 2012 6:35 am
OK, here is what I found out so far:

According to this "imagetool-uncompressed.py" is a tool do pack the uncompressed image (located after compiling the kernel in "arch/arm/boot/Image") for the Raspberry Pi hardware. This Python script generates the file "first32k.bin" and generates out "arch/arm/boot/Image" and "first32k.bin" the new Raspberry Pi kernel which is located at "arch/arm/boot/kernel.img".

So as far as I can see, all we have to do to get a qemu-Version of the Raspberry Pi Kernel is to generate a zImage by "make bzImage". I did so and because I already compiled the kernel over night it just had to repack the kernel which tooks only 5 minutes. But even with this image qemu still does not boot the kernel (screen remains black).

For now I'm out of ideas. Is there something I didn't see?

Thanks for your help,

Marian
User avatar
Posts: 143
Joined: Mon Feb 13, 2012 9:56 pm
by boley » Tue Apr 17, 2012 3:37 am
New Build

Just thought it might be nice to give a happy update to this thread.
Posts: 48
Joined: Wed Nov 30, 2011 9:50 pm
by pepedog » Tue Apr 17, 2012 7:04 am
Yes, main changes (apart from packages being updated, but I still did rootfs a few weeks back and time marches on) -

Kernel and firmware packaged, when BCM Dom makes a change it's all painlessly taken care of.

I am running rootfs off hard drive, and using am old 32Mb card for the /boot firmware, not quite enough room. To upgrade firmware I have to delete all but the txt files and kernel.img, move kernel.img for the duration, perform upgrade and move kernel back. Hopefully not to many people won't be a cheapskate like me.
Posts: 979
Joined: Fri Oct 07, 2011 9:55 am
by dom » Wed Apr 18, 2012 3:40 pm
Looks like the update to latest version removes the cmdline.txt (and config.txt).

This has the negative effect that the GPU bootloader doesn't append the extra arguments (e.g. framebuffer width/height, serial number, mac address)

This results in 800x480 framebuffer console.

Creating a suitable cmdline.txt fixes it:

echo "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait" >/boot/cmdline.txt

@pepedog - can you fix this?
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4042
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge