Back to the R-Pi Hub
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 isn't released yet - this page is a community work in progress in preparation for the launch. 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
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.
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 ;-)
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)
- "rysnc -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)