Slashdot Mirror

check the Pi wiki. Although not many people own one yet, there are a hand full of hardware extensions in the works or already available. I find it amazing how a small eco system around the Pi is already evolving:

- Expansion Boards
- Peripherals
- GPIO Documentation

Sparkfun has these BlueSMIRF BT modules which can be connected to one of the uarts of the Pi.

I'm much more exicted about the EOMA-68 stuff. Particularly these guys who are making an EOMA-68 compliant board with a BOM of $15 and almost all the interesting signals broken out into easy to access headers. They are basing it on the Allwinner A10 1.2ghz ARM Cortex A8 which has great specs (SATA, USB, etc) and seems to have datasheets available (try to get those for the Broadcom chip) All the hardware can be run by open source drivers with the exception of the hardware MPEG decoder which you can just ignore if you don't need it.

There's a debian squeeze port available now right here. The problem is that it was never compiled to do floating point instructions in hardware, so you're going to lose some seroius performance by using it over Fedora.

There are two "stock" Debian ARM distros. The one in stable (the "Arm EABI" port) doesn't support floating point. There's also one in the unstable branch called "armhf" which has support for ARM hardware floaitng point, but only for ARMv7 and up. Raspberry Pi is ARMv6 (notes for armhf platform are here..

I received a "Raspberry Pi Update" email from Newark, today (March 2) at 19:46:08 GMT thanking me for my interest, and including a Buy Now button.
Apparently I had filled out the Register-Your-Interest form prior to finding out how to pre-order (see previous post).
I almost ignored it having already pre-ordered yesterday with an estimated ship date of May 10th.
But... I was curious as to what the current shipping estimates were.

Surprise! April 3rd! (Yes, I completed the order. Sorry if that offends anyone.)

So, now I'm wondering if maybe, I'm now actually in the first batch, or May 10th was just a wild safe guess, and now they are getting better estimates from the factory?

A list of expected ship dates are at eLinux: http://elinux.org/RPi_Shipping

The R-Pi wiki at eLinux.org has an interesting table where people are entering their order time, the place they ordered it from and the estimated ship date they were given. One of the entries (mine) matches up with your info pretty closely.
Link to Page
  http://elinux.org/index.php?title=RPi_Shipping

This thing has more than enough power to run X, so don't bother with the text-mode distro.

The problem you'll run into is not processing power, but connectivity. No SATA connector, for example. As long as you're OK with serving files from an external USB 2.0 drive or the SD card, you'll be OK.

http://elinux.org/Rpi_Hardware

According to the present wiki information Model A received "Onboard Network: None".

Neither model precludes a USB wifi dongle(and some stuff, particularly some RaLink, actually works); but it looks like the default options are either "None" or "10/100 ethernet provided by a SMSC9512 USB hub/Ethernet controller hanging off the SoC's USB master port.

A case design allowing for a USB dongle to be installed; but protected inside the case, should be trivial enough; but is not default.

There are a lot of changes Google made to the Linux kernel, that while the source is available are not in the mainline. Some of those changes the kernel devs did not like, and may never be in the kernel at all. Others are slowly working their way in. This page lists the major differences in Android versus mainline.

Because of the kernel differences, it would be difficult to run an Android environment on a mainline Linux distribution.

As I pointed out in a different post, Matthew Garrett is wrong. Simply read the description of the Busybox replacement project:

http://www.elinux.org/Busybox_replacement_project

The reason for the project is because Sony's *suppliers* are violating Busybox's license without Sony knowing about it. Sony is afraid (and rightfully so) that it will create liability for them even though they generally have no problem with complying with the GPL license. This project is a replacement for Busybox under the new BSD license which they hope will encourage their suppliers to stop violating the GPL. This will reduce their liability.

GPL compliance does not bother them (and they have quite a few devices on the market with Linux source code availability to prove my point). But in this case, so as to avoid unknowingly violating the license, they want to encourage the use of free software with a more liberal license. It makes complete sense.

Sony wants to use GPL-licensed code except for projects the license is actually enforced.

As you suggest, this seems to be the reasonable interpretation of the motivation.

Could this not be used as evidence that Sony knowingly avoids it's obligations except when forced to? Could this lead to greater punitive damages in future lawsuits against Sony?

Sony is perhaps missing the real opportunity for competitive advantage here. Sony could easily put processes in place to get their GPL compliance up to scratch. They could then, either in partnership with other right holders or perhaps on the back of their own contributions, use GPL enforcement to interfere with competitors who aren't meeting their requirements when distributing hardware to consumers.

Sony does not gain any competitive advantage by working with competitors to take Busybox out of the loop. It could gain advantage by complying appropriately and stopping competitors who don't from distributing their product.

"As part of their request to remedy a busybox GPL violation, the SFC does ask for source code unrelated to busybox"

What are the names of these Busybox using companies that the SFC requested non-GPL code from?

"There are instances where this litigation and the terms requested by the SFC have resulted in companies dropping their embedded Linux projects."

What are the names of these companies?

"It has also caused even compliant companies to re-evaluate their adoption of Linux"

What are the names of these companies, define 're-evaluate`.

ref: Busybox Replacement Project

Once again, Slashdot links to a blog instead of the original source. The linked blog gets its evidence from a wiki page at http://www.elinux.org/Busybox_replacement_project

This page has a Q&A which clearly states that it is not a Sony project:

        Q. Tim Bird, the proposer of this project, works for Sony. Is this a Sony project?
        A. No. Although Tim is employed by Sony, he spends a portion of his employed time working on behalf of the embedded industry to improve Linux and encourage GPL compliance. As of February 2, 2012, Sony has not endorsed or agreed to support this project. This wiki page is for gathering information and project description information, to present to various companies to solicit support and resources for the project.

        Q. Can Tim's creation of this proposal be used to infer anything about Sony's compliance record, future compliance intent, or other business practices?
        A. Tim has only recently informed his management about this proposal, and Sony has not yet (as of 2/2/12) agreed to support it. So, "no, not really". Sony has a good compliance record, and has strong compliance policies in place. It has never been contacted by the SFC and has no expectation of being contacted by the SFC about any license violation of GPL software. Tim is doing this as part of his (paid for by Sony) role in the industry to address issues which inhibit the adoption of Linux in consumer electronics.

...on smartphones and tablets, particularly Android and its derivatives.

Cut the Rope is 99 cents with at least half a million downloads. There are two unknown factors - how many returns were there (downside) and how many over 500k are they (upside). So they've made around $500,000 on this app.

GTA III on Android - 4.99 and over 100,000 downloads - another $500,000 in revenue. And a lot of the graphics and engine code was already written.

I had a chat with one of the Big Mountain Snowboarding developers ($2.99 times 5000+ is $15,000, plus an ad-based Android version with over 500,000 users) who told me that over 85% of the C++ and OpenGL code from their iPhone version could be reused in their Android version. Companies with an existing C++/OpenGL code base don't have to re-invent the wheel to get on Android.

Fruit Ninja : $1.26 * 500,000+ = $630,000. Doodle Jump: $0.99 * 500,000+ = $500,000. Madden NFL 12: $4.99 * 100,000+ = $500,000. And so on. Then there's the money games make on their free, ad-based versions. As I said, many of these games have existing C++/OpenGL code on another platform, so the half million in sales, plus more in ads, that they've made thus far, is money they made just for the port. Which also helps keeping you in the game if some competitors want to take these established games on in this newer platform.

Android is a Linux kernel, with the rest of its code open source. Tim Bird and others recently started an effort to bring the Android developers and Linux closer together, so hopefully that will bear fruit.

These boards are only a few weeks away, far more powerful, low priced and have nothing to do with broadcommm

http://rhombus-tech.net/

http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

Great, so this low cost computer can be plugged into the PCMCIA slot of a laptop.

ah NO! :) the mechanical design prevents insertion of EOMA-PCMCIA CPU cards into legacy PCMCIA slots:
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA#Deliberate_Mechanical_Non-interoperability

if you tried to force it in, you would mechanically damage the laptop and/or the card, and once you'd done that, the chances are that you'd blow up the card and/or the laptop as well.

Or you couyld just use the laptop. Am i missing something here?

you're missing something :) the design concept is that the EOMA-PCMCIA CPU card *is* the laptop... but only when the modular CPU card is plugged into an EOMA-PCMCIA-compliant laptop Motherboard that's *designed* to take these CPU cards. see example motherboards here: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA#Example_Motherboards

to have an x86 CPU in a laptop already (cost of $300+) and to then put in an extra low-cost CPU card that does pretty much the same job as far as 98% of computer users are concerned, well... that would just be silly. why not just have a modular mass-volume laptop plus CPU card that can retail for about $95, eh? :)

Great, so this low cost computer can be plugged into the PCMCIA slot of a laptop.

ah NO! :) the mechanical design prevents insertion of EOMA-PCMCIA CPU cards into legacy PCMCIA slots:
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA#Deliberate_Mechanical_Non-interoperability

if you tried to force it in, you would mechanically damage the laptop and/or the card, and once you'd done that, the chances are that you'd blow up the card and/or the laptop as well.

Or you couyld just use the laptop. Am i missing something here?

you're missing something :) the design concept is that the EOMA-PCMCIA CPU card *is* the laptop... but only when the modular CPU card is plugged into an EOMA-PCMCIA-compliant laptop Motherboard that's *designed* to take these CPU cards. see example motherboards here: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA#Example_Motherboards

to have an x86 CPU in a laptop already (cost of $300+) and to then put in an extra low-cost CPU card that does pretty much the same job as far as 98% of computer users are concerned, well... that would just be silly. why not just have a modular mass-volume laptop plus CPU card that can retail for about $95, eh? :)

See their wiki page. They estimate the mass-volume component cost to be 5-6$. So 15$ most probably is the retail price.

I appreciate the fullness of the answer.

no problem.

What will it cost to do something with the dev module? At least through the network?

ok, one idea i'm advocating is to adapt arduino-like schematics to connect directly to the EOMA-PCMCIA-compliant interface. as such projects are usually a 2-layer board, very low-cost and the schematics are available under Open Source Licenses, it's a no-brainer. probably the best one to pick is the Leaflab's Maple: http://leaflabs.com/devices/maple/ because in mass-volume the CPU is around $1 to $1.50 (the 48-pin version not the 100-pin version!)

as this CPU is so low-cost, but importantly also so highly functional, its use substitutes and strategically "normalises" Motherboard designs. the plans being discussed at the moment include using the STM32F to do Audio (because of the D/A and A/D converters), battery monitoring (A/D converters), LCD Backlight control (PWM), resistive touchpanels (A/D converters again), keyboard matrix (8+8 GPIO) - someone's already written a mouse driver so at least that doesn't need to be done :)

so yes: if you're interested, look up the cost of arduino-like devices. at least for prototyping purposes you could just get an off-the-shelf leafpad maple and connect it directly to the EOMA-PCMCIA-compliant CPU card even with a few bits of wire, in a pinch.

anway, here's a link to some example motherboards that have been designed: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA#Example_Motherboards
that includes a "micro" engineering board (that's nothing more complex than an adaptation of existing leafpad maple schematics) as well as something that's similar to the IMX53QSB, Beagleboard, Pandaboard and Origen etc.

Your price targets sound delightful. Might as well mark it up another $20 so you can fund the next version too. Or if the money could be spent on making it more rugged, that would be well-spent.

If the CPU is as fast as you say then there might be more interest in the dev module than you'd think.

yes, that's the plan :) would love to have some brainstorming ideas written by people on the possibilities, hmmm... let me just create a wiki page: http://rhombus-tech.net//community_ideas

all the software is "open" yet obfuscated

The entire Raspberry Pi depends on a gigantic proprietary blob from Broadcom.

So let's do a Nouveau-style reverse engineering project. How hard can it be?

Sounds like a perfect project for the target audience: curious and talented kids. With a bit of experienced help if they get stuck (seems unlikely to me though, with sufficient time & motivation). Some kids love reverse engineering. I did when I was young and I was far from the only one (but we didn't have an internet to meet each other back then).

(I did loads of reverse engineering from about age 11+ (that was 1983), starting with the BBC and moving on to everything I could get access to, pulling apart games (starting from the binaries), changing behaviours, porting them from tape to floppy disk ;-), even porting them to new architectures, and now I think about it, quite a lot of hacking on video hardware of the time, both in hardware, and quirky programming to make it do useful things it wasn't designed to do. If Mr Braben is listening, I printed a whole disassembly of Elite, BBC disk version on dot matrix that took days to print (wow just got a flashback), and spent a long time learning from its algorithms, some of which I still use today - thank you ;-) )

...and yet, just like the OpenMoko FreeRunner (giant opaque SMedia Glamo blob meant 2d VESA grade graphics only) and the OLPC XO-1 (giant opaque Marvell blob meant the whole WiFi subsystem and "mesh-while asleep" was all a black box and driver couldn't be troubleshot) , all the software is "open" yet obfuscated

The entire Raspberry Pi depends on a gigantic proprietary blob from Broadcom.

Hmm. Google search came up with this deviantart for "Raspberry Blob", maybe this can be the project's mascot. Hooray for undocumented blobs, we don't need source code, maybe we'll get Windows CE for it someday!

Quite. It's got a 700 MHz ARM CPU and a 24 gigaflops/second GPU. Source.

Unless you're talking about games, there isn't a whole lot this thing won't be able to handle that you'd usually do on an entry level Win7 laptop

An entry level Win7 laptop will run Windows, for starters. Plus it will run a lot faster.

And cost at a bare minimum 15 times as much.

As far as the internet goes, the bottleneck is the pipe, not the computer for the most part. Lightweight applications on this thing will do just fine. And I guess you could have some fun on that front too if you were so inclined: Just how much could you get this thing to do and it still be usable.

And of course, teenagers want to play games, too.

Most teens I know have consoles of some description alongside their PCs. Obviously YMMV on that of course. But then again, whilst this could be put to general purpose use and probably be ok in that role, it's not what it was designed for.

the cpu it's bolted to has plenty of documentation to go with it.

Really? I tried the Broadcom site, and I couldn't find anything. Do you have a link ?

Sure!

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf

Was cited in the Rasberry Pi wiki: http://elinux.org/RaspberryPiBoard

Not surprised you didn't find anything on the Broadcom site though... It's a bit of a pig to navigate around.

I'll believe it when I see it.

http://elinux.org/RaspberryPiBoard#Hardware_Details

http://www.broadcom.com/products/Mobile-Multimedia/Mobile-Multimedia-Processors

Well ... the Broadcom BCM2835 SoC in Raspberry PI can directly control an LCD (all required pins available on a header on board) and you can also interface with a touchscreen:

http://elinux.org/RaspberryPiBoard#Interfacing_to_Raw_LCD_Panels

So you can use the Raspberry Pi to build a whitebox Tablet PC.

a short summary: http://superuser.com/questions/329375/how-is-this-operating-system-switching-done/330926#330926

the presentation by AI at ELC 2011: http://elinux.org/images/5/5c/ELC-AlwaysInnovating-Gentil.pdf

Troubles start when each operating system wants to get control over wireless, the display or any other resource they all share and expect to have exclusive control over. So considering how many bugs we already have in current operating systems I can hardly imagine the amount of hacks required to android or GNU/Linux to make them at least cooperate enough for basic functionality is worth the benefits of having multiple OS at the same time. I dont really see the advantage of such a feature.

Malware in the closed binary blob firmware and bootloader. Closed gpu libs. Not being able to boot your own kernel. Not being able to boot off the block device or location of choice. To name a few.

Lots of people care. That is why so many people reverse engineer their ARM tablets and cell phones. That is why there are open firmware projects like http://www.coreboot.org/ coreboot, http://kexecboot.org/ kexecboot and http://www.denx.de/wiki/U-Boot u-boot. Take a look at the http://wiki.opengraphics.org/tiki-index.php Open Graphics Project or http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA mentioned earlier in the comments here for what and why.

imagine having a Zynq-7030 as a desktop PC in a PCMCIA-sized unit, and on the end of the 68-pin connector there was an Arduino-compatible 2in x 2.5in Leafpad "Maple"-like Embedded Controller as well (STM32F). would that absolutely rock, or would that absolutely rock? oh wait - this is what's possible as outlined by the EOMA/PCMCIA initiative, here: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA/MiniEngineeringBoard

the trimslice is $200, is non-upgradeable and does not have an SATA-II interface (whereas the raspberrypi is $25 - a discrepancy of 85%+ in price, for no good reason). the genesi products use an iMX515 which has a hard limit of 512mb RAM, and the laptop only has a maximum LCD resolution of 1024x600, which is completely unusable. every single product out there right now has these hard compromises that make them completely dissatisfactory for at least one market. this is why i'm doing the EOMA/PCMCIA initiative, so that a product is *not* restricted (requires a total motherboard redesign) to a particular CPU. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

the first problem is that the cost of the whole system's components is actually, as the RaspberryPi shows, somewhere around the $40 mark. also, if you look closer at the Tegra 250 which is used in the TrimSlice, it doesn't have SATA-II. and as i mentioned in another post here, the number of modern ARM CPUs with PCI-e on the market is less than 5.

so you can't expand it (ARM systems aren't designed that way), and it happens not to have the _exact_ set of features which make it truly desirable to free software developers, which is why free software developers are plumping (reluctantly) for the OpenRD Ultimate, and wishing that there was something better.

right now, it's all a big big compromise. and that's why i started the EOMA initiative, so that those "compromises" do not impact on the development of a product: you can always go swap out the CPU card for something better when it comes along. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

there was a discussion of the features available (and desired) on debian-arm a few months back, let me give you a link to jump somewhere into the middle of that:
http://lists.debian.org/debian-arm/2011/08/msg00012.html

The Broadcom BCM2835 looks like the ARM SOC used by the Raspberry Pi. There isn't a link for its data sheet that I could find. So it looks like just another closed hardware ARM design.

Zacate is 18 watts! that means you have to have a heatsink or heatpipe, fan and other moving parts, as well as much larger power components. by contrast, with something like the NuSmart 2816 if you run it at 1.6ghz then you can get away with 4 watts and that's *including* the ECC 1066mhz DDR3 RAM. a voltage regulator for a stable 4 watt power supply is approximately a $0.50 cents part. it's a whole different ballgame. so the EOMA Initiative, we've set a 5 watt absolute maximum limit, and are sticking to it. http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA sadly, not even intel's latest 1.2ghz 45nm CPU, the one that's designed for Meego, is suitable, because the CPU's 2.5 watts, the Northbridge IC is 2 watts, whoops there's not enough room to run the RAM ICs.

even the Z510 shows that this northbridge-southbridge strategy is unacceptable. you *have* to go "totally integrated", in order to reach the required power target. once Intel and AMD start doing that, then and only then will they produce a winner.

not if it's got 4gb of ECC DDR3 1066mhz RAM, it's not. the NuSmart 2816 is a 1.6 to 2ghz Dual-Core Cortex A9 with two versions - one 32-bit memory addressing and the other 64-bit. they're sampling, now. i'm working to get them plugged in to the EOMA initiative:
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA
http://www.openhardwaresummit.org/forum/viewtopic.php?f=5&t=502

well, fortunately there's soon going to be things like the NuSmart 2816, which will have the best of both worlds: Dual-Core 1.6 to 2ghz, 4gb of ECC DDR3 1033mhz RAM... and only about 4 watts for a system (at the 1.6ghz speed).

i'm working towards getting these - and other such beefy low-power CPUs - plugged in to the EOMA initiative:
http://www.openhardwaresummit.org/forum/viewtopic.php?f=5&t=502
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

it's a long story, but i've been working to get ARM-powered desktop machines and laptops into the hands of free software developers for some time.

one of the key problems are that the chinese and taiwanese factories have absolutely no software expertise whatsoever. some guy decides he got caught out by the USA and UK Governments placing embargos and tariffs on imported clothes a couple years back: his business was affected, so he goes "i know, i'll diversify, i'll make tablets, those are popular". so off he goes, he gets supplied with a GPL-violating Android OS right from the word "go" by a limited number of Chinese ODMs who are having a really hard time keeping hold of their software engineers, and it just goes downhill from there.

the other problem is, as can be seen from the insane amount of money spent by the openpandora group, that case-work for laptops etc. can well be in excess of $100,000. that means that anything like the "pegatron netbook" has to be bought in volumes of 250,000 and above in order for the R&D costs to be amortised over a reasonable period.

this is where the EOMA initiative comes in: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

by reversing everything on its head, and getting free software developers a modular architecture which _could_ be dropped into a mass-volume product, the tables are turned: those Chinese Factories can be supplied *by us* - Free Software Developers - with a completed ready-to-ship OS.

so, yes there's a board which is available that is similar in size and function to the pandaboard, origen exynos board, beagleboard, IMX53QSB etc., but unlike those boards, by complying to the EOMA/PCMCIA Open Standard it would be possible to literally drop that hardware-software combination straight into a mass-volume product, with the development effort of the required motherboard being nothing more than a low-cost 2 to 4 layer board that even KiCAD, Eagle or gEDA could do.

one key part of this strategy is to leverage arduino-like boards, like the leafpad Maple:
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA/MiniEngineeringBoard

anyway i think that's enough for one slashdot post. bit of background and some additional links, here:
http://www.openhardwaresummit.org/forum/viewtopic.php?f=5&t=502

it's a long story, but i've been working to get ARM-powered desktop machines and laptops into the hands of free software developers for some time.

one of the key problems are that the chinese and taiwanese factories have absolutely no software expertise whatsoever. some guy decides he got caught out by the USA and UK Governments placing embargos and tariffs on imported clothes a couple years back: his business was affected, so he goes "i know, i'll diversify, i'll make tablets, those are popular". so off he goes, he gets supplied with a GPL-violating Android OS right from the word "go" by a limited number of Chinese ODMs who are having a really hard time keeping hold of their software engineers, and it just goes downhill from there.

the other problem is, as can be seen from the insane amount of money spent by the openpandora group, that case-work for laptops etc. can well be in excess of $100,000. that means that anything like the "pegatron netbook" has to be bought in volumes of 250,000 and above in order for the R&D costs to be amortised over a reasonable period.

this is where the EOMA initiative comes in: http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA

by reversing everything on its head, and getting free software developers a modular architecture which _could_ be dropped into a mass-volume product, the tables are turned: those Chinese Factories can be supplied *by us* - Free Software Developers - with a completed ready-to-ship OS.

so, yes there's a board which is available that is similar in size and function to the pandaboard, origen exynos board, beagleboard, IMX53QSB etc., but unlike those boards, by complying to the EOMA/PCMCIA Open Standard it would be possible to literally drop that hardware-software combination straight into a mass-volume product, with the development effort of the required motherboard being nothing more than a low-cost 2 to 4 layer board that even KiCAD, Eagle or gEDA could do.

one key part of this strategy is to leverage arduino-like boards, like the leafpad Maple:
http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA/MiniEngineeringBoard

anyway i think that's enough for one slashdot post. bit of background and some additional links, here:
http://www.openhardwaresummit.org/forum/viewtopic.php?f=5&t=502

funny... i was just writing up a post to the http://openhardwaresummit.org/ mailing list about a way to accelerate the process by which enthusiasts can work with the latest mass-produced embedded hardware.

the initiative, which has a specification here - http://elinux.org/Embedded_Open_Modular_Architecture/PCMCIA - is based around the fact that, just as mentioned above, the development of processor "speeds" is slowing down. this funnily enough allows so-called "embedded" processors to catch up, and it's these embedded CPUs which are low-power enough to base an entire computer around that is still desirable yet consumes between 0.5 and 3 watts instead of 10 to 500 watts.

if anybody would like to participate in this initiative, please do join the arm-netbook mailing list - http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook

^ this. Maybe Mr Upton will answer all these questions with a link to http://elinux.org/RaspberryPiBoard or http://www.raspberrypi.org/?page_id=8

"I'm interested in your product but can't be bothered to click on any links in the summary I just read. Can you please tell me something I could have found out for myself in less than a minute?"

I see that you plan on using C and Python for teaching languages. I recognize that I am of an older generation but grasping C in its entirety or even little endian versus big endian was something that didn't fully come around until college for me. What are your strategies for teaching even younger targets with something like C (Python, however is probably easier)? Are you developing a rigid teaching course line or just happy to have the community put anything out? Furthermore, what is the point of putting all these other languages on your wiki like Processing or Lua? Could you or someone on your staff give a brief explanation for each of these links or are they here just to inspire someone to write a tutorial for -- I don't know -- harvesting data with the Raspberry Pi and displaying it in Processing on another computer? Or do you intend the processing application to compile to ARMv6 on the device and run on the device for a UI output? I know ARMv6 is supposed to be a leaner architecture but I'm not at all familiar with the Broadcom BCM2835 that you've shown on your alpha boards. All my searches for it just link back to your site.

GRRR! Stop it. You're scamming people. Do you sell it? Please. Look at the reviews, idiot..

Please, look at the specs, fuckhead

http://elinux.org/RaspberryPiBoard#Components

J7: Composite Video connector: RCA

It's one thing to say I'm wrong on a technical issue. It's a whole other thing to accuse me of "scamming". Of course I'm not selling the fucking things.

if it's possible to add some digital/analogue inputs/outputs it could become electronics bloggers new favourite toy

See here http://elinux.org/RaspberryPiBoard#Provisional_specification
"General-purpose I/O (About 16 3v3) and various other interfaces, brought out to 1.27mm pin-strip"
... obviously provisional...

this summarizes things nicely. And this is from PALM THEMSELVES.

You want open? It doesn't get any more open than webos. On top of that, it's ELEGANT. Gestures, the card metaphor, unobtrusive notifications and dashboards, synergy, universal search. It's FUN and PRODUCTIVE to USE.

The full Optware distribution, native SDL apps, and a click-the-launcher Terminal application, all looked on with favor by Palm tend to disagree with your claims, and that's not even mentioning that you can run custom kernels under WebOS if you like.

It's also funny you should mention writing apps in HTML+JS; I'm using GWT to do that right now for a desktop application exactly because it's an easy way to write multi-platform apps, including mobile versions.

It's in the right place, but will it behave the right way?

When those mainboards with extra flash for vista were announced I hoped for it being accessible directly via linux mtd.
Without reading the article I still assume that it will again be just another hdd simulator that doesn't allow the os to do the wear levelling or map the storage directly into the accessible memory.

Too bad. Since Debians live-helper made building live systems easy I'm running my desktop and laptop from squashfs anyways so I'd love to see them do execute in place,too. http://elinux.org/Application_XIP

I just noticed that although a stock Beagle Board is 500MHZ, it's possible to change the clock speed in the BIOS, so maybe he's already driving/overdriving the processor in this instance.

And for those kind words I'm going to post a follow up to my original post of more relevant changes between the 2.4 and latest 2.6 kernels (I'll try and add a few more words after each point).

Kernel configuration was overhauled. Outside support for more GUI menus, it now means you no longer have to do make dep after changing something. Further building modules outside the kernel tree is now not so baroque. The time to build and partially rebuild kernels also dropped. Building a kernel in parallel (i.e. using more than one CPU during the build process) works better.

Better support for configuring out unneeded parts of the core kernel on embedded systems. You can see the seeds of this going mainline in a git commit on 2.5.70. There is an outside project called Linux Tiny that produces patches aimed at being able to configure out features not needed for embedded systems. Over the course of 2.6 many of these patches have trickled into the mainstream kernel.

I mentioned that 2.6 scales better under load in my previous post. Here are some benchmark comparison graphs of 2.4 versus 2.6 kernels (the graphs also include comparisons against the BSDs but you can see that Linux 2.4 had some serious problems that Linux 2.6 addressed).

The kernel is now (on systems where there is reliable device discovery) able to automatically load the modules it needs to drive hardware. No more having to adjust static lists of which modules need to be loaded.

udev was introduced. This change meant that the entries in /dev were no longer static. In 2.4 all possible device entries (even for devices you didn't have) were shown in /dev and their major/minor numbers were fixed (which was causing problems as new devices were turning up - what major/minor number do you give them?). Additionally the other dynamic /dev system (devfs) was whittled away and killed off.

FUSE support (LWN article about FUSE). Allows filesystem drivers to be written in userspace. Currently the best Linux NTFS driver is written using FUSE and it allows fun things like sshfs. Might be handy if you need users to be able to configure where data is stored remotely, you are writing your own filesystem or you need to support writing to NTFS formatted USB disks...

There is better CFS (Samba/SMB/Windows File Sharing) support. NFS version 4 support was also added.

cpufreq support. The kernel can clock down the CPU speed (usually by changing voltages via some hardware interface) to save large amounts of power. This can be done in response to work load so you run at full speed as often as possible and then when things are quiet you scale down to the lowest setting (you often save the most power when doing absolutely nothing so it pays to finish things as quickly as possible).

Any switch from 2.4 to 2.6 will of course require userspace changes (updated modutils, udev, later gcc, later glibc).

There is also davej's post Halloween document discussing changes from 2.4 to 2.5. This is very detailed and is another excellent reference.

Many many other things have changed too (e.g. ALSA support for sound has been added) but I have tried to keep the ones mentioned at least tangentially related to the original scenario :)

Someone guy unpotted a Votrax module and refurbished the damaged components so that it still worked afterwards and he could reverse-engineer it. It's interesting and has lots of pictures of before and after. The thing starts out as a a big block of epoxy and ends up a normal-looking circuit board.

That is pretty cool but I suspect it would be a bit more difficult to do this with technology that is less than 25 years old (note the 1982(?) copyright under the logo).

Today the "chips" will probably be bare dies glued to the PCB with very delicate bond wires connecting everything together. Not very conducive to being exposed by a heat gun;-)

I have personally seen the kernel portion of a boot on an embedded board reduced to 186 milliseconds, using aggressive techniques such as Execute-in-Place.

For user space, customize your init scripts (actually, dump your init scripts in favor of one compiled /sbin/init binary).

In the x86 space, with legacy hardware, I think the thing that will give you the most problem is BIOS. I know of products with custom code that replaces BIOS, that load the kernel from ROM in under 150 milliseconds. But that's probably more effort than you are interested in. You may want to check out what options are available in your current (legacy) BIOS for skipping things like the POST test, etc.

Great review and great book. Just wanted to also point out that http://www.elinux.org/ (a site I edit) is a fantastic wiki for information regarding embedded linux and it's only getting better. We recently merged content from elinux.org (the original) and the CELF Public Wiki. Also, the wiki will be relaunched officially at OLS.

Looking at the links provided in TFA, it's hard to find the real violation here. For example, the link to HiSense quotes an email (March 2006) from the technical lead at USDTV, responding to a user request for copies of the source per the GNU GPL. He states that he would be happy to put up the files for download via a (web?) server, but they were moving offices and didn't have a box to use. Lame, but looks to be in good faith. Until they could put up a server, the technical lead listed the (unmodified?) software components covered by the GNU GPL:

• Linux kernel version 2.4.18
• glibc version 2.2.4
• libpthread version 0.9
• busybox version 0.60.0
• GNU tar 1.13.19
• gzip version 1.3

There is then a mention on the site (not part of the email) that the company has since hit financial problems, possibly implying they are going out of business. In fact, USDTV did go under. Technically, a violation of the GNU GPL for not providing the source on demand, but would be hard to bring to court. Especially since USDTV is out of business now. :-P

Under the GNU GPL, a developer who modifies or distributes code under the GNU GPL is required to redistribute the source code, "for a charge no more than your cost of physically performing source distribution". However, a program that is separate from the GNU GPL code (for example, a program that runs on top of the Linux kernel) is not bound by the GNU GPL. So they company isn't bound by anything to release code or binaries to their subscriber box software. And in any case, $30 could be a reasonable fee for physical distribution, since they are sending a field rep to your home - if they were distributing source code to the GNU GPL components (which doesn't appear to be the case.)

Reading through the (long!) forum, the company appears to be distributing an updated kernel and their own subscriber box software updates - from a USB "key" (I assume a USB fob or somesuch.) Forum members report they haven't been able to read the USB key on a PC. I didn't go through all 19 web pages of comments, but I didn't see anyone complaining about trying to get the source code.

So after much searching, it appears the submitted article is someone complaining they aren't getting upgraded TV software for free, and using the GNU GPL as leverage in their argument. Am I missing something???

Sadly, I can only provide a few tantalising hints. Not because I'm sitting on the information, but because very few people have written about this, and I haven't yet tried it myself.

Wikipedia on xD cards
Instructions to fit an xD card to a Mattel Juicebox
A comment on LWN from Wookey, who knows a lot about flash
xD card pinout

My best advice is to ask people on the linux-mtd mailing list for specific details.