Group Actions
Engagement
  • Author Author: Former Member
  • Date Created: Date Created
  • Views 1493 views
  • Likes 1 like
  • Comments 14 comments
Related
Recommended

Overview

Former Member

In this blog I hope to share with you some of the more interesting way points on the journey to designing the Raspberry Pi Hardware from the ideas kicking around 6 years ago to the overwhelming (for me and a few servers!) launch on Wednesday. 

 

I was lucky enough to be with element14 in Nuremberg when the RPi arrived from the UK for the noon on-stand launch.  Mike Powell from element14 deftly cabled the RPi, but gave me the 'honour' of powering it up. As many of you will know - it's a heart stopping moment (especially in front of a crowd of enthusiasts) until the kernel boot appears on the screen - it's either command line, terminal silence or smoke!

 

There is plenty of stuff on the Web about the Foundation and it's aims so I won't be repeating it here (unless asked).  There will be little discussion about software - we have lots of talented people in the team that can talk way more sensibly about that.  There is also an equally talented team on the hardware side and I hope I can encourage them to chip in with useful comment and correct me when I go off the rails.

 

I'm very happy to be sign posted to things that interest you - so let me know, and I'm sure they can be worked in somewhere.

  • in reply to Former Member

    I'll put my old academia hat on and agree with Jason that speed is not a major concern in education, which is the motivating force for Rpi.  The CPU just needs to be "fast enough" to keep it highly responsive so that interactive development is not bogged down.

     

    Of course it's always nice to have more speed, but I think we'll have to wait for Rpi Next Gen for that.  The BCM2835's ARM11 is inherently slower than a modern Cortex-A series, so it's not the best choice of ARM core for speed merchants --- but then, that was never a requirement in this design.

     

    The other ARM licensees are probably very dismayed at Broadcom's massive PR coup with Raspberry Pi, but they have ample opportunity to compete:  make a similar board within the $25-$35 price bracket but based on a more modern core.  And if ARM Holdings needs some major pummeling to lower Cortex licensing fees if they're too high for this niche (as the BeagleBone price suggests), so be it. image

  • in reply to Former Member

    @coder27: The amount and organisation of caches really depends on the goals set by the designers.  The BCM2835 was not designed as an all-out speed demon on the CPU front, hence the descriptions of "Videocore IV with ARM bolted on the side" in some Hardware FAQ.  That said, the datasheet that PeteL pointed to says "BCM2835 provides a 128KB system L2 cache, which is used primarily by the GPU. Accesses to memory are routed either via or around the L2 cache depending on senior two bits of the bus address."

     

    So, it sounds like you can use the L2 cache from the CPU in some circumstances... is it done in the RPi Linux build at the moment?  Not sure.  Bear in mind that the datasheet was written for engineers looking at the BCM2835's suitability for embedded use - in which case the GPU would be the main user of the L2 cache.  Also, remember that the only reason an L2 cache exists in a single core system is to reduce cache miss rates for less overall (cost/latency/hit to the maximum achievable CPU frequency) than enlarging the L1 cache.  In a perfect world where you didn't have to care about such mundanities, you would just choose the L1 cache size to fit your cache miss rate for your chosen workloads.

     

    I went looking for a boot log to see if there was a mention of how big the ARM's L1 cache was - the ARM1176 architecture manual only says that L1 is between 4KB and 64KB in size - the decision is left to the licensee as to how much chip area they want to spend on the cache.  I couldn't find anything in the only dmesg output (from Paul Maunders' beta board).

     

    In any case, what are you worried about being slow in particular?  The GUI?  The boot time?  The actual programming environment?  It's got about as much memory and CPU performance as the machine I used as a staff member of a university Computer Science department in 2001... and I seem to remember being able to write a few programs with that.  Boot times can be tuned, simpler GUIs favoured, and lightweight IDEs chosen.  It's for schoolkids after all... they don't need Eclipse to write programs a few pages long; back when I was at secondary college, we thought that Turbo Pascal running on a 640KB PC was usable for what we were asked to do.

  • in reply to Former Member

    I agree - there is no obvious reason why this should be a problem as the adaptor is a completely passive device.  I think this stems from the fact that microSD cards are largely based on later generations of silicon (die shrink to meet the form factor). This comment is in some way related to the troubles with some Class 10 cards and the microSD therefore appeared to be a total no go.

     

    We are in the process of running some tests on microSD cards to find which ones (if any) work and we are also looking at issues with Class 10 and SDHC to see if we can find a fix.  We will publish more when we have some solid results to share.

     

    From a hardware point of view I would have loved to use a just microSD card - just look at all the real estate I could have saved!

  • in reply to Former Member

    I am presuming that the lack of L2 cache for the CPU is the main reason why a 700Mhz ARM performs only at the speed of a Pentium II 300.  I cannot imagine putting a Pentium II 300 class machine in front of a student to get them excited about programming.  A sluggish computer is no fun at all to use, although for embedded applications it may be fine.

     

    L2 cache is normally a no-brainer, since it doesn't increase the number of cpu pins, and it doesn't increase power usage.  In fact it saves power because it reduces memory bus traffic.  Intel tried eliminating the L2 cache on the original Celeron, which they soon realized was a major mistake, even for a low-cost entry-level cpu.

  • http://zenit.senecac.on.ca/wiki/index.php/Raspberry_Pi_Fedora_Remix_Installation claims that you must use a SD card, specifically: "Do not use a MicroSD card with an adapter -- it will not be recognized by the Raspberry Pi."

     

    As a HW engineer, can you comment on the basis for this statement? I thought a microSD card in an adaptor *is* an SD card, and the computer should not be able to see any difference (?)  I understand that there may be trouble with some Class 10 cards, and 16 GB size SDHC, but I don't understand why all microSD is forbidden.