Back to the Hub.
Tutorials - a list of tutorials. Learn by doing.
Guides - a list of informative guides. Make something useful.
Projects - a list of community projects. Help others out.
Tasks - for advanced users to collaborate on software tasks.
Datasheets - a frambozenier.org documentation project.
Education - a place to share your group's project and find useful learning sites.
Community - links to the community elsewhere on the web.
Games - all kinds of computer games.
This page lists key functionality missing from Raspberry Pi Foundation's ultra-low-cost (~15UKP or 25USD) Linux computer for teaching computer programming to children, and encourages the community to provide a solution.
The Raspberry Pi Foundation is a UK registered charity (Registration Number 1129409) which exists to promote the study of computer science and related topics, especially at school level, and to put the fun back into learning computing. We expect this computer to have many other applications both in the developed and the developing world.
Please note that the Raspberry Pi has only just been released - this page is a community work in progress in preparation for when people get their devices. Please also note that we will be setting up a repository for uploading contributions, but this isn't ready yet so please simply use http://pastebin.com or http://dropbox.com and provide a link from this page, until we have something set up
It is intended that these tasks will be implemented by the Raspberry Pi community.
OTG device mode
Inspired by the device mode idea below: Allow the Raspberry Pi to work as an USB device. Sharing the SD card as a storage device is one option. But becoming an USB-display is another.
Decisions to make: Run Linux on the "device mode" Raspberry Pi or not?
Difficulties: the Raspberry Pi has a "device mode" connector, but the data pins are unconnected. Solutions: Use the USB connector on a Model A with a custom cable/converter, or find pins on the board to attach patchwires to.
OTG Device mode
The idea: A student has damaged or wiped the OS on their SDCard. By plugging two Raspberry Pi's back-to-back using the Mini-AB cable with the white end attached to the working device and a recovery SDcard image in the non-working device, the firmware will allow the non-working unit's SD card to be accessible to the working unit.
The detail: Once both devices are booted, the recovery image runs completely from RAM. The SDcard can be ejected and the damaged or wiped SDcard inserted. The SDcard of the working machine can then be cloned.
The task: The device won’t support device mode out of the box, though we’re using a Synopsys OTG core so the hardware is there and the firmware is open, so it might be possible. I suspect if you forced 5V onto the USB power rail it would boot. (Note: Maybe not: There might be a 140mA Polyfuse in there).
A device driver would need to be written and a recovery image created. A command line tool set will need to be provided to deliver the functionality described above.
Possibly simpler recovery idea
How about a recovery application as part of the standard image, that can run from RAM? This just needs a working SDcard. The goal is to clone the working SDcard to a "bricked" SDcard.
Here's a possible workflow:
- Start the device with a working SDCard.
- Start the "recovery" application. This probably does super kernel/driver magic to only provide text out, and SDcard mounting/unmounting, and prompts the user.
- Using the available RAM as buffer, load the first 128/256 MB (minus 1 MB for the recovery thing.)
- Ask the user to switch to the "bricked" card.
- Write the first 128/256 MB to the bricked card.
- Keep swapping, 16 times (or 8, if you have a 256 MB device)
- If the card has two partitions, one for OS, and one for user files, the number of swaps needed is smaller.
With two devices, this can be improved to something similar to the original suggestion, but using a simple binary that comes with the distribution:
- Start device 1 with a working SDcard.
- Run the "brick recovery" application. This makes sure to lock itself in RAM. Prompt user to insert the bad card and connect device 2.
- Start device 2 off the working SDcard and connect to device 1. (How does power work here? That might be really hard without a special "A to A" cable...)
- Run the "brick recovery" application on device 2. This detects that device 1 is already connected, and starts transferring the image from the SDcard.
The nice thing here is that recovery only needs to be a small binary on the original image, and is always available, and would be available even without a USB cable in case 1.
The special affordances needed by the recovery application are:
- Switch graphics into text mode, or some other super-simple presentation mode that doesn't need lots of RAM.
- Run the SDcard port.
- Stop everything else from happening.
- Lock the recovery application and SDcard driver into RAM.
- Optional USB driver for 2-device recovery, also coded into the recovery app.
Once the kernel has that "take over the device" mode, I'm sure some neato to-the-metal applications will also spring up ;-)
An Even Simpler Backup/Restore Idea
A much easier and less error-prone recovery method would be to clone the current system's SDcard to another card in a USB writer. The software required could be a simple shell script wrapper around dd, maybe using dialog for prompts and warnings and confirmations.
USB SDcard Reader/Writers are cheap - even Amazon has them for $1.75, retail price for single units, and you can probably find them even cheaper if you google for "USB SDcard writer". Some writers are as small as USB thumb-drives.
They could offered as an optional purchase along with a Raspberry Pi, or schools could be given one or two with larger orders, along with instructions on how to use them to restore a student's damaged SDcard.
This could be treated as a mundane "Backup Your SDcard" procedure, rather than as a scary last resort.
The idea: A script which partitions and formats the SDcard ready for software.
The detail: BeagleBoard community uses something similar, see http://www.angstrom-distribution.org/demo/beagleboard/ and http://www.xora.org.uk/2009/08/14/omap3-sd-booting/
The task: Write a script to create a FAT32 partition for the GPU firmware and a EXT3 partition for the rootfs.
Tomato 22:08, 22 October 2011 (UTC)
Some of my past projects use such a script to generate a sdcard. I modified it, so it does only the requested things ( removed the part that installs a MBR and copies files to the card ). It can be found here http://pastebin.com/u9Qpm5n0. ATM the partitions are ~80 MB for ext, rest of the card for FAT32 (can be changed on request).
The idea: A script that copies files from an attached USB flash drive to the SDcard after a delay, allowing the user to unplug the keyboard or mouse and plug in the USB drive.
The task: Write the script. Make it bullet proof.
Automatic, no delay solution
--Markit 21:24, 26 October 2011 (UTC)
- Download devmon.
- Start a daemon with
- devmon --no-gui --exec-on-drive "cp -r /directory/to/copy/each/time %d;devmon --unmount-recent;echo Copy complete, safe to remove | wall"
Tomato 23:38, 26 October 2011 (UTC)
- "rsync -ac /directory/to/copy/each/time %d" might be better suited to transfer the files to the card.
- "sync" to flush the buffers afterwards couldn't hurt either
- Each time a usb key is added, the daemon will automatically copy the folder, unmount the disk and send a message to all connected local/ssh terminals.
udev could also be used.
- Discussion and task list being developed on the ROOL site.
R-Pi System/Data Management
--Meltwater 20th Dec 2011
Details here: Pi in the Sky - Cloud management? Basic concept: Enable ways to easily switch and share system images for the R-Pi and manage user data, allowing joint development and easy management of set-ups.
- Fast/Easy backup of system/data to external storage or network (local or cloud).
- Management/Repository of base images.
- Boot from network
This would enable a number of potential scenarios:
- Keep multiple R-Pi's synced across locations (office vs home or classroom vs home)
- Manage a multiple users of R-Pi's (i.e. classroom setup, each user's data gets synced with network so each user can continue their own work on any R-Pi)
- Easy switching of function by booting to multiple images (i.e. Media centre image, programming image, in-car image)
- Remote management of R-Pi's (by updating the master image)
The project should be able to be divided into a number of smaller projects which when put together may well be able to perform the functions we want.
- User Data sync/web mount
- System Image backup/restore (to online/local network/local)
- Bootloader with boot from online/local network/local image
- Online image repository
Project Wiki Page - R-Pi System/Data Management
First problem Defining how user applications are managed and installed, and thus how the card is partitioned. Straw man proposal:
- FAT GPU (and boot?) partition
- EXT partition for rootfs and /usr and /var /etc ... root writable
- EXT partition for /usr/local ... all user-installed applications go here (note: traditional Linux "rpm -i something.rpm" writing everywhere in the FS is not particularly great for manageability)
- FAT partition for Windows-shareable user files -- perhaps /home is mounted here?
- Do we need swap?
- Default for bigger cards should probably be something like putting 65% of free space on /usr/local (EXT) and 35% on /home (FAT)
The idea: One R_pi will be connected to another and both can work on the same code.py. So that way say a teacher wanted to help a student with code without taking over. They can just plug there pi in to the students and go through checking for mistakes ect.
The Conection: Conection will probably be via Ethernet using an ad hoc Network.
Whats needed?: The program needs to open .py files and edit them. Next it needs to make a shered file that is updated every time a character changes. A different program (or same does not matter) should then connect to this file and update it in the same way. Every 10 seconds both pi's reload the shared file, thus have the same code. If the changes contradict each other then the host pi will override the connected pi.
Why not just use VNC?
How much of this "collaborative editing" is already built into Sugar? 
For something a little less intrusive/immediate, a DVCS like mercurial or git keeps people from stepping on each other's toes.
Further evolutions: once/if the initial goals are acheved then further developments to the project would include making the systom compleatly live so there in no 10 second delay to each update. And make it posibal to connect the pi's via the Internet.
The initial task: The first stage In this project is to make a file browser that can open and edit .py files.
More info: for more information about the project follow @Lipj01 on twitter or email me at: Lippojac@gmail.com