Well ive got Hexxeh's image loaded and updated. Ran into a few SD card issues, but the new card ive got seems to run well with the latest firmware etc. Had to update manually as rpi-update started throwing mmc0 errors.

I've updated everything and got Iceweasel working, seems to be quite acceptable and im posting this from it now :)

My only problem now is when i tried to do 'tasksel install standard'. It seemed to start ok and went to the blue screen with prograss bar but then got text streaming up the screen too fast to read. Left it for about half an hour, and then had to kill the power as nothing was responding. It looked like loads of lines saying something like 'Function entered at [<c0as>] from [<c00249>]' but very hard to see, even after taking pictures with my phone!


Keep up the good work though, very promising!

KeithSloan wrote:yes http://en.wikipedia.org/wiki/Xgl makes interesting but despondent reading, but I expect making an X Server that uses OpenGL is a lot of work and will be a lot more hard work than just porting some existing effort. Personally I don't think its likely we will see any solution for the Pi in the short to medium term.

Sadly, this seems the case. I'm very surprised that an X server built over OpenGL ES isn't already a solved problem. I guess up until now there has been very little need for desktop X on such devices. This is a great opportunity for some enterprising individual to make themselves a hero to a lot of Raspberry Pi users.

I think this thread by teh_orph is the only one that shows progress towards an accelerated x:

http://www.raspberrypi.org/phpBB3/viewtopic.php?t=4649

JamesA wrote:Left it for about half an hour, and then had to kill the power as nothing was responding. It looked like loads of lines saying something like 'Function entered at [<c0as>] from [<c00249>]' but very hard to see, even after taking pictures with my phone!

Keep up the good work though, very promising!

I've not yet tried Raspbian but I think this may have been mentioned in this thread. Try changing the vm.min_free_kbytes = 8192 in /etc/sysctl.conf
I've had to go higher than this figure to get rid of these when downloading from multiple threads on a news server with the standard debian image on my pi.

I've the same issue as JamesA with tasksel. The thing starts, and shows a bar, but then starts pushing out a continuous flow of... well.. something like 'Function entered... etc. My camera didn't manage to capture it properly. Only a reboot solved the issue.
But besides this, the whole thing runs fine! Thanks for all the effort that is being put into this!

shalo wrote: I've not yet tried Raspbian but I think this may have been mentioned in this thread. Try changing the vm.min_free_kbytes = 8192 in /etc/sysctl.conf
I've had to go higher than this figure to get rid of these when downloading from multiple threads on a news server with the standard debian image on my pi.

Adding vm.min_free_kbytes = 8192 in /etc/sysctl.conf indeed fixed the thing! Thanks!

Well, the Maker Fair was a bust for me as far as meeting the folk from Raspberry Pi. My son had a playoff baseball game today and we weren't able to get to the Maker Faire until a few hours after it opened. The result is I missed Eben's talk. No problem I thought, I'll go find out where they are hanging out at the faire. Wrong...

I've been going to the faire since they began five or six years ago and each year it's gets bigger and bigger. This year was no exception. The crowd was enormous. And crowds and I just don't mix well. The halls where companies show their wares were so jam packed that I could hardly even move. Unfortunately, no maps were given out of individual exhibits, the web app they wanted visitors to use sucked, and even the staff at the show couldn't help me figure out where Element 14 or anyone else were exhibiting the Raspberry Pi. I simply had no way to find out where the Raspberry Pi was being exhibited, if at all.

After four hours of looking, I just gave up and enjoyed the exhibits with my kids. I did manage to find one Raspberry Pi that was being shown by the Berkeley Linux Users Group. The person who owned it wasn't around and the other guy just smiled at me and said it runs Linux as if he expected me to not know what that was. I just smiled back and said "I know.". Oh well, I guess I don't look like a Linux user.

Builds have been going pretty well today. Plugwash found an issue that was preventing a good number of packages from entering the build queue which has now been fixed. The current package counts for Saturday evening are:

Debian armhf 34413
Raspbian armhf 31017

Just a few thousand more binary packages to build to reach parity with Debian armhf.

For those wishing to use the Midori web browser, a new build of the gtk webkit is being pushed to the public repository. This version disables the Javascript JIT which will hopefully prevent the instability experienced in Midori.

Could someone who previously ran Midori do an "apt-get update" and a "apt-get dist-upgrade" to pick this new version of the Javascript interpreter from gtk webkit (libjavascriptcoregtk-1.0-0_1.8.1-2.1+rpi1_armhf.deb) and report back here if Midori is now running more stable?

mpthompson wrote:For those wishing to use the Midori web browser, a new build of the gtk webkit is being pushed to the public repository. This version disables the Javascript JIT which will hopefully prevent the instability experienced in Midori.

Could someone who previously ran Midori do an "apt-get update" and a "apt-get dist-upgrade" to pick this new version of the Javascript interpreter from gtk webkit (libjavascriptcoregtk-1.0-0_1.8.1-2.1+rpi1_armhf.deb) and report back here if Midori is now running more stable?

On the positive side, it seems much more stable - it was crashing on the forum previously, and I can now post using it (presuming this post appears). Also, first impressions are that it isn't using 100% cpu all the time like it did in the last official debian image I tried. It seems slightly quicker to start than iceweasel, and sites like bbc.co.uk and guardian.co.uk are displaying without problems.

On the negative side, the sunspider benchmark doesn't run, which is working in iceweasel.

mpthompson wrote:Well, the Maker Fair was a bust for me as far as meeting the folk from Raspberry Pi. My son had a playoff baseball game today and we weren't able to get to the Maker Faire until a few hours after it opened. The result is I missed Eben's talk. No problem I thought, I'll go find out where they are hanging out at the faire. Wrong...

Yeah, I realized the same thing as I tried to link up with Eben and Liz via PMs and Tweets - it took about two hours and I only accidentally ran into Eben on my way back to where they had been earlier in the afternoon. There had to be upwards of 30,000 people crammed together, and they all seemed to always be right next to me. The scarcity of Pi boards meant that there was no real way to host a dedicated area to show them off. Of course, by next year there will be enough Pi systems for everyone at the Faire to have one and, as Eben, Liz, and I agreed, that will be a very happy situation to be in at that point. I guess this year is for coordination of strategy and aligning development efforts, and we can do that on-line, for now.

Well, off to the Demo Stage to see Eben's presentation on programming at 11 AM along with Liz, and a lot of other people, if Saturday was any indication.

The best things in life aren't things ... but, a Pi comes pretty darned close! :D
"Education is not the filling of a pail, but the lighting of a fire." -- W.B. Yeats
In theory, theory & practice are the same - in practice, they aren't!!!

hexelpdkk wrote:On the positive side, it seems much more stable - it was crashing on the forum previously, and I can now post using it (presuming this post appears). Also, first impressions are that it isn't using 100% cpu all the time like it did in the last official debian image I tried. It seems slightly quicker to start than iceweasel, and sites like bbc.co.uk and guardian.co.uk are displaying without problems.

On the negative side, the sunspider benchmark doesn't run, which is working in iceweasel.

Thanks for the report back. I'm glad to hear it at least running stable enough to use.

How can I assist in this development effort?

I think it's really important going forward to have a distribution available that makes the maximum use of the Pi's hardware.

I have a long term goal to us a Pi as the "brain" of a Sojourner-sized Mars Rover replica. In order to do the stereo vision calculations, I'll want the maximum FP performance possible.

I'd consider myself a medium-ability Linux/UNIX user, I played around with Gentoo in the 2003-2004 timeframe when it was fashionable, used Ubuntu on a laptop for ~2 years, ran Solaris 10 Express on my NAS for 3 years; (now it's using FreeNAS), and I have Linux Mint 12 LMDE on two machines right now. I don't know everything off the top of my head, but If I don't know something or it doesn't work, I can usually find the documentation and fix 90% of issues myself. I'm not so good with C/C++, so I can't really generate patches myself, but I can test and try and reproduce issues...

marsman2020 wrote:How can I assist in this development effort?

I appreciate your enthusiasm to help. I made a list of things that could be done a few days ago earlier in this thread:

http://www.raspberrypi.org/phpBB3/viewt ... 714#p78714

The builds continue to be going smoothly. Not a big package count day as I updated the repository with new sources from Debian Wheezy and much of the day was spent rebuilding the updated source packages which doesn't count in the numbers below. The current binary package count as of Sunday evening is:

Debian armhf 34377
Raspbian armhf 31384

Less than 3000 packages to go to reach parity with Debian armhf. Lots of good stuff in the build queue including more gnome pieces and much of KDE waiting to be built -- although the value of KDE on the Raspberry Pi is questionable. Perhaps it will run better than I expect or will run well once an accelerated X server is available.

I'll be out of town on a school school field trip with my son for the next two days and I won't have Internet access :o. I'll be back on Wednesday...

Just for fun, I benchmarked Quake 3 between Debian armel, and Raspbian armhf.

debian "driver info" : http://i.imgur.com/wtYhB.jpg
debian timedemo score: http://i.imgur.com/i2TkN.jpg
20.2fps

raspbian "driver info" : http://i.imgur.com/8nqa1.jpg
raspbian timedemo score: http://i.imgur.com/dUu0g.jpg
28.5fps

Both using ioq3 1.35 compiled from here: https://github.com/raspberrypi/quake3

Over 40% increase in performance!

mpthompson wrote:

marsman2020 wrote:How can I assist in this development effort?

I appreciate your enthusiasm to help. I made a list of things that could be done a few days ago earlier in this thread:

http://www.raspberrypi.org/phpBB3/viewt ... 714#p78714

Since I have a Pi in-hand, it might make sense for me to look at the installer stuff. I have no experience with the traditional Debian installer, so it will take some research on my end.

One thought - we have to have the firmware on the SD card for the Pi to even boot into the installer. So the installer setup will be a little different then say, installing from a LiveCD.

I am thinking along the lines of the following:
-The installer be in a 2GB SD card image, just like the pre-installed Debian images
-The image have 2 partitions, the /boot for the firmware, and a 256MB partition with the installer (this is about the size of the Debian netinst images, plus some room to add specific packages for the Pi)
-Once the installer is running it partitions the remainder of the SD card as desired by the user
-The installer installs a basic system from its image and downloads any additional packages at install time (netinst)
-At the end of installation, or at first run, the 256MB installer partition is deleted and replaced by /swap

An alternate implementation would be to put just the firmware/installer image on the SD card and have a package library on a USB key, in which case a 4GB image could be used with more packages available without going out to the network....

It seems that the normal way to run the debian installer on arm boards is to put the kernel and installer initrd on the fat partition of the SD card then load the rest of the installer over the network.

I'd be tempted with a minimal Debian install, a script that helps me configure the basics (keyboard, network, users and so forth) and then asks if I want to install some common package combos (gcc, lamp, lxde etc).

A full blown installer is appropriate when you have PC's with varying configs of hardware but we don't - we have a known base config so can use a fixed base install - it's just the extras that could be prompted for with an 'installer'

Pico/RP2040 ≠ Arduino
Pico = hot rod kit car, Arduino = hot rod kit car wrapped in cotton wool with buoyancy aids & parachute

posting this from iceweasel on raspbian, it works (once I set the min_free_kbytes that dom mentioned) but it's painfully slow.

Since nobody is packaging raspberry pi specific stuff yet (or if they are it isn't public) what are things people are using to get images working so far?

The broadcom installer in the sbin adds some initscripts and ld.so.conf entry. I have been adding things by hand as needed.

To get broadcom bins working:
ln -s /lib/ld-linux-armhf.so.3 ld-linux.so.3

/etc/ld.so.conf.d/vc.conf:
/opt/vc/lib

/etc/sysctl.d/rpi.conf:
vm.min_free_kbytes = 12288

/etc/udev/rules.d/10-videocore.rules:
SUBSYSTEM=="vchiq", GROUP="video", MODE="0660"
SUBSYSTEM=="vc-mem", GROUP="video", MODE="0660"

I haven't played with gpio yet but I think these probably need some udev rules. Would be handy to have pkgconfig files to help development when we decide on paths for the libs.

posting this from midori on raspbian which feels better than iceweasel but still struggles with the outlook web app.

Has ffmpeg been built in armhf yet?
If yes - then I'd be interested to know if it makes it feasible to play mpeg2 files.
They are way too slow on the regular Debian distribution.
I don't have a spare SD card at the moment so can't test the build - but I can make a short MPEG2 file available if anyone is available to try it.

I quickly checked and ffmpeg mpeg2 decoder does not use floating point, so don't expect major improvements...

Damn - but thanks for checking.

I've done some research on the process of building debian-installer initrd's for the netboot and "business card" size images that pull all their packages off of the network.

I'm a bit busy right now, but sometime in the next week I still start with one of the images Hexxah has provided and try and create a prototype image with the debian-installer initrd in the /boot firmware partition.

I agree that the final customized debian-installer version for raspbian (raspbian-installer?) will mostly be asking questions about what software to install, and pulling the latest firmware/hardware drivers for the specific hardware in the Pi from the repositories. It should actually be simpler then the versions that run on PCs and have to deal with autodetecting a ton of hardware.