Bounty List?

Hi,

i ordered a Raspberry Pi 2 Weeks ago and hopefully I will get one someday. While i was fiddling with all the informations posted, i was curious if there is some sort of bounty list, where one could give a bounty to someone who ports something to Raspberry Pi?

As a example, I would offer 500€ to someone who creates a platform in qemu that is 100% compatible with Raspberry Pi with all registers/the memorymap and all extension, so that all people waiting for their raspberry pi can use qemu on a one to one basis for development until their raspberry pi arrives, without hassling rewriting parts of code, because the address space is different or some parts are not in the emulation.

Just to be curious, do you think such a bounty list could help improve Raspberry PI further?

A bounty list would be helpful in some cases.

What you want (qemu full support for RPi) is going to cost a lot more and only Broadcom can help you with that.

Bounty list is not a bad idea, but Pi manuacture is really coming on stream now and people won't have to wait for the real thing soon.

Hmm, ok was just asking, because im a Professor at a University in Germany. I would like to offer our computer science students the possibilty to develop for arm without buying one (in the lab the real hardware, and for the homework the qemu).

University students can probably afford to buy their own Raspi, surely?

Just being curious: can I ask at what university you teach?

ohh that kind of bounty list, was getting exited at the thought of taking out targets for quick cash

/me looks nervously over shoulder.

As a example, I would offer 500€ to someone who creates a platform in qemu that is 100% compatible with Raspberry Pi with all registers/the memorymap and all extension, so that all people waiting for their raspberry pi can use qemu on a one to one basis for development until their raspberry pi arrives, without hassling rewriting parts of code, because the address space is different or some parts are not in the emulation.

You may want to offer this on the qemu-devel list.

One can probably provide support for GPIO and most registers but compatibility with the GPU is not feasible. May be just the framebuffer wouldn't be hard. Another problem is the binary blob (TM) is evolving rapidly -- a lot of new config.txt parameters have been added but they are not fully documented in one place.

You may want to offer this on the qemu-devel list.
One can probably provide support for GPIO and most registers

When this was mentioned before, I suggested viewtopic.php?p=83832#p83832

a lot of new config.txt parameters have been added but they are not fully documented in one place.

AFAIK they should all be documented at http://elinux.org/RPi_config.txt
If you find any that aren't you should probably give Dom/JamesH/Gert a nudge

You may want to offer this on the qemu-devel list.
One can probably provide support for GPIO and most registers

When this was mentioned before, I suggested viewtopic.php?p=83832#p83832

a lot of new config.txt parameters have been added but they are not fully documented in one place.

AFAIK they should all be documented at http://elinux.org/RPi_config.txt
If you find any that aren't you should probably give Dom/JamesH/Gert a nudge

Thanks. I was forgetting that page as I hadn't looked at it in a while. The missing ones I noticed:

device_tree (default bcm2835.dtb?)
kernel_old (is this still valid?)

There may be more. Scraping Dom's replies for "=" might yield a complete list : )

It would make sense to put *all* the variables in something like /boot/default/config.txt as a reference, with everything commented out as in

# var=defaultvalue

I can create an initial version if there is interest.

PS: good suggestion re: cloning code from existing gpio panel code from another project!