[OFFICIAL] RaspberryPi: The 25$ PC

This forum is for topics specific to the Raspberry Pi and Arch Linux ARM

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby sironitomas » Fri Mar 02, 2012 1:00 am

$this->bbcode_second_pass_quote('pepedog', 'W')orks great, fbdev fine, no acceleration yet, no sound via alsa as no driver, openmax has to be used.
Arch rootfs made and will be available soon.


Great! Pardon my ignorance, but why can't the sound (and video) driver be taken from another distro like Fedora?
sironitomas
 
Posts: 12
Joined: Sun Jul 17, 2011 3:23 am

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby pepedog » Fri Mar 02, 2012 8:55 am

We have (probably, as no sound driver exists) the same one as fedora and Debian, sound via openmax. Either a driver needs creating or an alsa version of openmax.
We have the same video as both
pepedog
Developer
 
Posts: 2431
Joined: Mon Jun 07, 2010 3:30 pm
Location: London UK

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby mlitke » Mon Mar 05, 2012 3:29 pm

I saw this post over at the raspberrypi.org site:
http://www.raspberrypi.org/archives/746
Nice work, I can't wait until the Raspberry Pi becomes more widely available and I can get one to install Arch Linux ARM on it.
mlitke
 
Posts: 55
Joined: Sat Apr 30, 2011 5:27 am

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby nasberry » Mon Mar 05, 2012 3:32 pm

Let us know when the RootFS is available, fancy getting this all running in QEMU.

Cheers

NASberryPi.org
nasberry
 
Posts: 1
Joined: Mon Mar 05, 2012 3:30 pm

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby pepedog » Mon Mar 05, 2012 6:10 pm

http://myplugbox.com/rpi-archlinuxarm18feb2012.torrent
That is slightly older rootfs, I asked if they would seed newer, but they just did sd img
pepedog
Developer
 
Posts: 2431
Joined: Mon Jun 07, 2010 3:30 pm
Location: London UK

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby pepedog » Mon Mar 05, 2012 8:34 pm

I know. The problem with the raspberry pi is there is no Linux to start with. Will write instructions soon, the sd card contains blobs, signed image , not uImage, kernel boot params, and eventually gets mounted as boot. It's fat32 LBA.
I got a 32 Mb (yes, Mb) card for this, and rootfs on hard drive. Or rootfs could be on part 2 of a bigger card.
Anyway, it's different. V fast to loading kernel, 25 seconds to prompt.
Rootfs can easily be ext4.
Anyway, script explains things more than I can.
This isn't my only thing on the go, been trying to get dove fb 2d acceleration on hf cubox.
Plus cooking meals for 88 yo mum, and dog is sick, his back legs weak and lost nail blood everywhere.
pepedog
Developer
 
Posts: 2431
Joined: Mon Jun 07, 2010 3:30 pm
Location: London UK

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby OrionFyre » Tue Mar 06, 2012 10:53 am

May I ask why the clock is defaulted to 800Mhz in config.txt? Shouldn't the decision to operate the device in an accelerated state rest in the hands of the end-user?
OrionFyre
 
Posts: 6
Joined: Sat Feb 25, 2012 3:25 pm

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby pepedog » Tue Mar 06, 2012 1:17 pm

Dom the BCM guy said 800 was stable, does not void warranty, so I thought why not? A 14% increase in speed free of charge.
pepedog
Developer
 
Posts: 2431
Joined: Mon Jun 07, 2010 3:30 pm
Location: London UK

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby OrionFyre » Tue Mar 06, 2012 5:52 pm

$this->bbcode_second_pass_quote('pepedog', 'D')om the BCM guy said 800 was stable, does not void warranty, so I thought why not? A 14% increase in speed free of charge.

Don't get me wrong. I agree in implementation personally and I will deffinitely be overclocking some of these bad boys even to the warranty voiding levels and possibly to destruction just because I can. I fully predict I'll be running all my Pi's at 800Mhz or more continuously for that extra oomph.

However, where I disagree is the motion to unilaterally make this decision for the end user. I don't want to step on any toes but I feel that this goes against the Arch Way(tm) of giving vanilla states of software packages and then allowing the end-user to make any modifications that they choose to make. Arch is one of the few distros that modifies upstream packages as minimally as possible keeping them as the coders intended, in-so-long-as it's possible. And I would think that same mentality should be maintained in regards to hardware configurations.

I guess my argument is that there is a decision that is being made for the end user who may not know that such a decision is being made, and furthermore may not be aware of the potential risks associated with such a decision. The reason I choose Arch for all my systems is because there are so very few decisions made for me.

Again, I do not mean to step on toes or presume to speak for the community (ALARM, RasPi, Arch. etc), but this seems to be a pretty big deviation from the Arch norms I've come to be acquainted with over the last five years of using it.

Whatever the outcome I do think that people should presently be made aware that by running the system with the default config setup that we are providing that they are operating the Pi in an accelerated clock state that is outside of the manufacturer's listed specification (700Mhz), with appropriate warnings of what that could possibly entail, and clear instructions on how to revert this change.
OrionFyre
 
Posts: 6
Joined: Sat Feb 25, 2012 3:25 pm

Re: [OFFICIAL] RaspberryPi: The 25$ PC

Postby kmihelich » Tue Mar 06, 2012 8:32 pm

The problem here seems to be a confusion of software policy and hardware setup. As far as software policy goes, we don't break tradition from upstream. Now let's go outside of the OS for a moment, and thus outside of Arch standards.

Since every device must receive some form of customization in the bootloader and initialization, under what you say we should do in applying a policy of software compilation and packaging to hardware setup we would not have a user base to speak of, as very few would actually be able get to the point of booting the OS. In effect this would make our lives easier, as we could just blast away installation pages, U-Boot replacements, environment configurations and just say, "have at it, we'll see you on the other side." As all of these modifications made by us are being "made for the end user who may not know that such a decision is being made, and furthermore may not be aware of the potential risks associated" with the decisions, where do you draw the line? Do we say that since a device did not come with the ability to boot from SATA, that providing that functionality is somehow against the established norms for the operating system's software, and thus should not be exposed?

Of course, this is completely silly. Obviously hardware setup is not comparable to the packaging standards of arbitrary pieces of software. We strive to make the OS accessible on platforms we have been able to solidify support on, and in general ensure devices perform to their highest potential. If a spec sheet says 700MHz is the production clock, yet an engineer for that company passes along that 800MHz poses no significant threat, warranty issue, or compromises stability, there is no reason not to take advantage of that knowledge to provide a better experience to the end user. For those that want to modify values to their liking, we will of course provide instructions on doing so in the appropriate area of the site.
Arch Linux ARM exists and continues to grow through community support, please donate today!
kmihelich
Developer
 
Posts: 1133
Joined: Tue Jul 20, 2010 6:55 am
Location: aka leming #archlinuxarm

PreviousNext

Return to Raspberry Pi

Who is online

Users browsing this forum: No registered users and 7 guests