ArchlinuxARM on Raspberry Pi


146 posts   Page 2 of 6   1, 2, 3, 4, 5, 6
by pepedog » Fri Jan 27, 2012 9:41 pm
Finally, rootfs on hard drive is working
Bluetooth keyboard and mouse too.
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by liamfraser280 » Fri Jan 27, 2012 9:44 pm
Great work,

Congratulations mate!

I take it you have an Alpha board? What happens when you do a restart (i.e init 6). Asked a question on the forums but no one is sure. Does it just restart like your typical Linux box?

Cheers,

Liam.
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by pepedog » Fri Jan 27, 2012 11:45 pm
reboot and halt work as expected, didn't with old blob

dd if=/dev/zero of=testfile bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 60.35 s, 17.4 MB/s

hdparm -Tt /dev/sda1

/dev/sda1:
Timing cached reads:   318 MB in  2.00 seconds = 159.00 MB/sec
Timing buffered disk reads:  60 MB in  3.00 seconds =  20.00 MB/sec
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by liz » Fri Jan 27, 2012 11:53 pm
pepedog said:


Finally, rootfs on hard drive is working
Bluetooth keyboard and mouse too.


Brilliant - well done!
--
Head of Comms, Raspberry Pi Foundation
User avatar
Raspberry Pi Foundation Employee & Forum Moderator
Raspberry Pi Foundation Employee & Forum Moderator
Posts: 4153
Joined: Thu Jul 28, 2011 7:22 pm
by banshee » Sat Jan 28, 2012 1:46 am
pepedog said:


reboot and halt work as expected, didn't with old blob

dd if=/dev/zero of=testfile bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 60.35 s, 17.4 MB/s

hdparm -Tt /dev/sda1

/dev/sda1:
Timing cached reads:   318 MB in  2.00 seconds = 159.00 MB/sec
Timing buffered disk reads:  60 MB in  3.00 seconds =  20.00 MB/sec



Oooh, that's so sexy...
Posts: 3
Joined: Tue Jan 24, 2012 7:58 pm
by liamfraser280 » Sat Jan 28, 2012 9:14 am
Thanks for the reboot/halt info.

banshee said:


Oooh, that's so sexy...


+1 :D
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by pepedog » Sun Jan 29, 2012 3:54 pm
Back to the 5th post in this thread, where I posted a script-

Well I played with my script here, and got to point where I wanted to revert to what I had (it worked for me).

So I copy the script from the 5th post, it don't run, did the forum software change things.

For instance, did I write cyl instead of cylinder?

Anyway, I now have a packaged kernel, and a new rootfs to follow shortly, but then again I want to poke around kernel more
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by pepedog » Mon Jan 30, 2012 6:31 pm
The first time I have created a torrent or run a tracker.

I have a new rootfs here

http://myplugbox.com/rprootfs-.....gz.torrent

Please seed and give comments

password for root is root.

I see video has reserved a lot more ram (ouch)


# free
total       used       free     shared    buffers     cached
Mem:        124992     108640      16352          0       6192      77432
-/+ buffers/cache:      25016      99976
Swap:            0          0          0


Previous version had 70 meg more available
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by liamfraser280 » Mon Jan 30, 2012 8:04 pm
Wow that is a lot of ram for the video to take :/

Is this the 'final' kernel? If so I hope this can be changed. I'll start downloading now. Will only be able to seed at night though!
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by pepedog » Mon Jan 30, 2012 8:15 pm
I doubt it will be the final kernel, not all modules I like built.

Would like to know where the memory has gone too.
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by liamfraser280 » Mon Jan 30, 2012 8:16 pm
I was just thinking... surely that figure can't be right? How are the 128mb versions ever going to work well with the gpu taking up 70 meg.

Maybe you should ask a kernel dev about this?
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by spennig » Mon Jan 30, 2012 8:18 pm
Anyone managed to download any bytes at all? Transmission keeps sitting at zero for me.
User avatar
Posts: 84
Joined: Mon Aug 29, 2011 11:34 am
Location: New Forest
by liamfraser280 » Mon Jan 30, 2012 8:19 pm
Same here!

I guess we should just give the tracker some time.
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by spennig » Mon Jan 30, 2012 8:33 pm
hardy hit post than it springs into life   ...
User avatar
Posts: 84
Joined: Mon Aug 29, 2011 11:34 am
Location: New Forest
by pepedog » Mon Jan 30, 2012 9:17 pm
I had to scrabble to adjust firewall, the server is a dockstar on a static ip address.
All should be good now.
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by Chromatix » Mon Jan 30, 2012 9:18 pm
pepedog said:


I doubt it will be the final kernel, not all modules I like built.

Would like to know where the memory has gone too.


Looks to me as though it's all filecache - ie. not used by the video at all.  As soon as something needs to really use that memory, the kernel will make room for it.
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 » Mon Jan 30, 2012 9:19 pm
I was just thinking... surely that figure can"t be right? How are the 128mb versions ever going to work well with the gpu taking up 70 meg.

Maybe you should ask a kernel dev about this?

Im hoping someone will ask Dom
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by liamfraser280 » Mon Jan 30, 2012 9:22 pm
That root fs is flying down now :) . Will be seeding all night for those who want a poke around.
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by jamesh » Mon Jan 30, 2012 9:58 pm
Liam Fraser said:


I was just thinking... surely that figure can't be right? How are the 128mb versions ever going to work well with the gpu taking up 70 meg.

Maybe you should ask a kernel dev about this?


The minimum the GPU needs is around 44MB - otherwise things just don't work very well. You can use less....but it's not advisable. If you don't use a camera, you don't need much more than the 44MB.
Volunteer at the Raspberry Pi Foundation, helper at Picademy September, October, November 2014.
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 12372
Joined: Sat Jul 30, 2011 7:41 pm
by liamfraser280 » Mon Jan 30, 2012 10:25 pm
Ahh that's not too bad.

256 - 44 = 212mb

I have a debian minimal install that is about 12mb without X so that's 200mb.

Add light window manager such as openbox and X, you have about 170mb to play with.

That's plenty, especially if you get friendly with terminal apps :)
Posts: 354
Joined: Tue Oct 04, 2011 6:53 pm
by Chromatix » Mon Jan 30, 2012 11:25 pm
Something that concerns me: looking at a disassembly of libm.so, I don't see any VFP instructions.  This strongly suggests that you've built this in softfloat mode (which assumes no VFP) rather than softfp (which is ABI-compatible with softfloat but uses VFP).

I understand that hardfp mode (which would be ideal) might be tricky because of the closed-source GPU libraries, but can we at least have softfp?
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 » Tue Jan 31, 2012 1:47 am
Chromatix said:


Something that concerns me: looking at a disassembly of libm.so, I don't see any VFP instructions.  This strongly suggests that you've built this in softfloat mode (which assumes no VFP) rather than softfp (which is ABI-compatible with softfloat but uses VFP).

I understand that hardfp mode (which would be ideal) might be tricky because of the closed-source GPU libraries, but can we at least have softfp?


I put your question to our builder. I nagged him a few months ago about this, he said then that we would need to know how much performance increase would there be to make it worthwhile. You have to remember no one on archlinuxarm is paid to work on it, relying on donations for servers (web) and hardware (plugs), and builder is what he has bought himself. If we had web server space, and he helped with setup then I could do the same myself for this hardware.

Here is his response, some colourful parts edited-


He's right, v5 is completely softfloat (not softfp at all) because the RPi is the first device in this unique position, in-between class of devices that no one directly supports.

I don't intend to provide any softfp packages for vfp in the repo anytime soon because 1. I don't have any hardware to actually build them on, and 2. the build system is not equipped to handle split packages like that. If he wants to build a package softfp vfp, it's not like we're holding a gun to his head telling him he can't.

Sometime in the future I am going to be looking into a NEON separation in the v7h repo, and the same techniques could be applied to v5 with a v6 vfp sub-variant. But doing that requires significant additions to the build system to keep everything up to date and send builds to the correct builders.

Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by Chromatix » Tue Jan 31, 2012 1:24 pm
It has to be said, the R-Pi is essentially at the top end of the pre-ARMv7 performance heap.  So it won't run v7 code and the core isn't as wide, but is otherwise remarkably similar in configuration to, say, a Tegra2 (but with only one core).

Prior to v7, putting a VFP in an ARM was not so often done.  So softfloat makes sense for generic builds.

Fortunately, the R-Pi is really cheap, so getting him hardware to test on shouldn't be very difficult - once it is released of course!  Meanwhile, softfp (and indeed hardfloat) code will run on noVFP hardware, just so long as the emulation support is in the kernel.

The performance difference is likely to be quite significant for FP-heavy workloads, but I'm not sure where it stands compared to the difference between softfp and hardfloat.  I might be able to test it on my TrimSlice, since it appears to be happy enough running v6-hardfloat code.
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 » Tue Jan 31, 2012 2:08 pm
Arch had soft and hard v7 repos, soft was dropped.
Here is comparison on trimslice of Ubuntu soft against arch hard
http://www.phoronix.com/scan.p.....#038;num=1
According to them, arch might be slower?
Posts: 986
Joined: Fri Oct 07, 2011 9:55 am
by Chromatix » Tue Jan 31, 2012 4:35 pm
Looks like some things are faster and some slower in that comparison.  The main difference that could account for this is the compiler version, although it is possible that ARM versus Thumb2 (it not being clear which of these is predominantly used by each distro) also makes a difference.  On the R-Pi, Thumb2 is not available, only the older and much less capable Thumb, so this difference would be even greater if relevant.

The only major difference between softfp and hardfloat is that in hardfloat, arguments can be passed in VFP registers, while in softfp they must be moved to integer registers (or RAM) even if they start off in and are then processed in VFP registers.  Eliminating this excess data movement should be a pure win.  (Also, recompiling an individual library for this ABI, to fit in with a distro that uses it, should be easy unless there is ABI-dependent assembly involved.)

The difference between softfloat and softfp is that in the former, integer-based routines are used for manipulating floating-point values, while in the latter the VFP unit is normally used instead.  These two maintain a common ABI, so individual libraries and applications can use either one interchangeably, just with different levels of efficiency on different hardware.

On VFP hardware, softfp and hardfloat should always be faster than softfloat, for software that uses FP a lot.  There should be nil difference for integer-only applications such as data compression or cryptography, so use benchmarks based on those two areas as calibration for other platform details.
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