log in | register | forums
Show:
Go:
Forums
Username:

Password:

User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Can't remember the name. (Games:8)
- RISC OS on GitHub (News:2)
- Aemulor (Gen:7)
- GMail and POP (Gen:2)
- !DualHead in use (News:6)
- I'm back... (Gen:12)
- R-Comp release !DualHead (News:1)
- August news round-up (News:)
- Revisting the old Acorn magazines online (News:4)
- Jason Tribbeck's code library released (News:13)
Related articles
- Newsround
- Easier video playback on RISC OS?
- Software migrates to the Beagleboard
- CES 2010: ARM hardware roundup
- RISC OS on new hardware
- A gaggle of gadgets
- Iyonix: first birthday review
- A summary of RISC OS hardware
- Aemulor Pro revealed
- Aemulor Pro-gress
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
 
Article archives
The Icon Bar: News and features: RISC OS on OMAP - the future?
 

RISC OS on OMAP - the future?

Posted by Jeffrey Lee on 12:00, 19/5/2009 | , , , , , , , ,
 
BeagleBoard.org logoAs most of you probably know by now, a few months ago I started work on porting RISC OS Open's RISC OS kernel to TI's OMAP3 platform - a group of SoC's (Systems on a Chip) which use ARM Cortex-A8 cores. To date, OMAP3 SoC's have been confirmed as being used in various products, including the Pandora handheld gaming console, the Touch Book convertible netbook/tablet, and the BeagleBoard development board. For years RISC OS users have been asking for a new portable RISC OS machine, and soon they may find that they have several available.
 

 

Out with the old, in with the new

The Cortex-A8 and Cortex-A9 cores from ARM are the latest and greatest iteration of ARM chips. Although the 600MHz CPU in the OMAP3530 doesn't offer any increase in clock speed compared to the XScale-based CPU in the Iyonix, it has several advantages in other key areas:

  • Dual-issue superscalar design - Previous ARM CPUs that have run RISC OS were all based around scalar designs, i.e. they only had one instruction pipeline and therefore were only capable of processing a maximum of one instruction per clock cycle. But the Cortex-A8 uses two instruction pipelines operating in parellel, allowing it to process up to two instructions per clock cycle. This means that although the CPU is only clocked at 600MHz it has a maximum theoretical performance of 1,200 MIPS, twice that of the IOP321 in the Iyonix.
  • Vector Floating Point Unit - For many years ARM CPUs as used by RISC OS have lacked floating point units, resulting in poor performance in many modern number-crunching tasks such as audio/video encoding/decoding or 3D games. With the Cortex-A8 that's all about to change, as it contains support for both the VFPv3 and NEON instruction sets. Although this new floating point instruction set isn't backwards-compatible with the old FPA10/11 instruction set that RISC OS has historically used, the new instructions are far more powerful and look to be a key part of ARM CPUs for many years to come.
  • L2 cache - The CPU core in the OMAP3530 has 256KB of L2 cache. This is practically nothing when compared to modern x86 CPUs, but this is the first time a CPU with an L2 cache has been available for use by RISC OS, and should help to speed up many common memory-intensive tasks.
  • Improved memory interface - As many people will testify, the memory interface of XScale-based CPUs contains flaws that severly limit the available bandwidth. Cortex-based CPUs do not suffer from these flaws, and as a result the CPU has approximately 4x greater memory bandwidth available, despite the fact the RAM is often clocked slower (165MHz DDR on a BeagleBoard compared to 200MHz DDR in an Iyonix).
  • MMU enhancements - The addition of a second L1 page table pointer allows for much faster task switching than the current lazy task switching system, and as a result a more responsive desktop (Although it is questionable whether anyone will notice the difference!)
Beyond the Cortex core, the OMAP3530 also brings the following new features to the table:
  • Flexible display controller - The display controller supports upscaling/downscaling and rotation of the display, helping to make the OS more usable on portable devices with small or irregularly-sized screens.
  • Hardware YUV overlay - Nowadays this is an essential feature for video playback. When used together with the VFPU, it should greatly improve RISC OS's media player capabilites.
  • C64x+ DSP - A second processor capable of running programs independently of the main CPU. Its instruction set is tailored to performing audio/video codec functions; once suitable drivers exist for RISC OS it will be able to alleviate the CPU of much of the work needed for video playback.
  • SGX 3D core - Although the SGX drivers remain closed-source, there is some hope that in the future RISC OS will gain the ability to use it for hardware acceleration of 3D games or other rendering tasks.
Unfortunately, since the OMAP3530 is targetted for portable/embedded systems, it also has a few deficiencies when compared to regular desktop ARM machines like the Iyonix:
  • No IDE/SATA controller. Instead builtin flash memory (typically 256-512MB) and SD/MMC cards are used for primary storage. Although the price of SD cards has dropped significantly in recent years, they still don't offer the same price/GB ratio, speed, or total capacity as a hard disc. Secondary storage devices such as floppy or optical discs must be connected via USB.
  • No PCI/podule bus. Instead USB is used as the main form of expansion, which could cause problems with device/driver compatability, or the poor CPU performance currently offered by the Castle USB stack.
  • Limited display resolutions. The maximum pixel rate the OMAP3530 is capable of is 86.5MHz - which is just about enough for 1280x1024 at 57Hz. For portable devices like the Pandora or Touch Book this isn't much of an issue, but for people planning on using a BeagleBoard as their main computer it may be very important. The display controller is also incapable of generating the timings required for many standard VESA modes, so you may find that some tweaking is required to get an MDF that works well on your monitor.

Getting started

A while ago I got my hands on a BeagleBoard of my own, to help me more effectively work on the RISC OS port. For anyone else looking to get involved with porting RISC OS to the board, here's a rough getting-started guide, along with a few of the things I've learnt whilst working with the system.

List of parts

The first thing you'll need to do is draw up your shopping list.

  • A BeagleBoard. The only official retailer is Digi-Key, who use UPS express delivery to get your board to you within a couple of days, even if it's been sent from the USA. Most other vital equipment can be ordered from Digi-Key also, although not always at the best of prices. Just be aware that if you are in the EU, you'll have to pay the delivery man VAT when he delivers your board (This will be about £20 in the UK if you just buy a board and a serial cable). You may also have to answer a couple of questions from Digi-Key via email to help convince the US export officials that you're not an evil terrorist, or put up with their ordering system mistakenly flagging the beableboard as export-prohibited and cancelling your order - but since it's free delivery for orders over $50 you can't really complain.
  • A case. Although not mandatory, a case will help protect your board from knocks, bumps and spills. Currently Special Computing are the only supplier known to sell cases, although at $29 for a case and $42 for international shipping it's hardly a cheap addition if that's all your in interested ordering from them. Special Computing also sell BeagleBoards and a few other supplies, so if you aren't worried about the fact that the Beagle Hospital only accepts RMAs on boards bought from Digi-Key then an order from Special Computing may be more appropriate for you.
  • A power supply. You have a few options available here:
    • A USB cable plugged into the USB OTG port. All that you'll need for this is a standard USB A to mini-B cable and something to plug the other end into (e.g. a PC or a powered hub). If you own a PDA, PSP, digital camera, or fancy mobile phone then you may already have an appropriate cable.
    • A dedicated power supply plugged into the DC jack. 1A at 5V is all that's needed, although you should also be careful to make sure the jack is the right size and polarity (check the reference manual if you're in doubt)
    • A USB cable plugged into the DC jack. Special Computing are the only place I know of that sell an appropriate cable; I've had trouble tracking down suppliers in the UK.
    Just be aware that if you're powering the board via a USB cable then there will only be around 100mA of power available to the USB port(s), which is only really enough for one low-power device. But since the board only has two USB ports you'd usually want to use it with a (powered) USB hub anyway.
  • A serial cable. Although you might be able to get by without one, it's strongly recommended that you have a serial cable available as it's the only sure-fire way of configuring the U-Boot bootloader that's used by the board. It's also the easiest way of debugging nasty RISC OS crashes, or setting up a different operating system such as Linux.
    The serial cable header on the BeagleBoard is suitable for an IDC10 connector. This is the same as used in most old PC's, so you may find that you've already got a suitable ribbon cable to convert from IDC10 to DB9M (The standard 9-pin serial connector). Then you can use an ordinary null modem cable to connect it to your host machine. If you don't have a suitable IDC10 cable handy, then both Digi-Key and Special Computing sell cables that can be used.
  • HDMI/DVI cable. HDMI is backwards-compatible with DVI-D, so to save space on the board a HDMI socket is used instead of DVI/VGA. This means that with the appropriate cable you can connect the board to either an HDMI or DVI display - but not to VGA, as the board doesn't supply any appropriate analogue signals. With a good HD TV or monitor you may find that you can use high screen resolutions such as 1920x1080 @ 30Hz. For ordinary monitors 1280x1024 @ 57Hz is about the best you can expect. If you have a choice between HDMI and DVI, DVI is perhaps the best, since it allows the board to read the EDID information of the monitor (assuming the OS is capable of doing something with it!)
  • Powered USB hub. The board itself is usually only capable of providing a small amount of power to the USB ports, plus there are only two ports available. A hub is therefore mandatory if you're planning on using the board for any serious work. Almost any powered USB hub should do, although you'll have to take into account how many ports you'll be using. The good news is that you can use the hub to power the board itself - i.e. one USB cable running from the hub to the board to provide power, and a second cable running from the board to the hub to provide the extra USB ports.
  • USB keyboard/mouse. Technically you could use a USB switch/KVM to connect the board to your existing keyboard and mouse, but since my board was going to be connected to the same monitor as my RiscPC (which doesn't use a USB keyboard or mouse) I figured it would be a better idea to buy a dedicated device just for the board itself. Since I'm short on desk space I decided to try something new, and went for a mini keyboard with builtin trackball. Wireless keyboard+trackball/touchpad combos are easy to come by, but since I can't abide by replacing/recharging the batteries in wireless peripherals I went for a more expensive wired version. The only downside to a keyboard+trackball/touchpad combo is that most seem to only have two mouse buttons, so a seperate utility will be needed to use them properly with RISC OS (or in my case, a few minutes of hacking around in the USB HID driver to remap the Windows key to the middle mouse button).
  • USB network adaptor. Not a necessity, but it's the easiest way to get programs to and from the board once the OS is installed. Although I have a couple of USB wifi dongles lying around the place, I wasn't sure if any of them worked with Linux, or even worse, whether any of them had open enough drivers and documentation for a RISC OS port to be made. With that in mind I decided to buy one of the cheapest USB ethernet adaptors I could find, under the assumption that cheap + mass-produced = high chance of open source drivers. Luckily this plan worked, as the device I bought has open source drivers available for both Linux and NetBSD. Plans are already in place to add support for the device to James Peacock's EtherUSB module so that it can be used under RISC OS. Note that you can also get USB hubs with builtin ethernet adaptors, such as the one sold by Special Computing, or by searching for 'laptop docking station' on any big retailers website. However these devices are often more expensive than if you were to buy a seperate hub + network adaptor, or may come with extra unwanted features (e.g. audio in/out, USB VGA adaptors, etc.)
  • USB cables. To make the most of the OTG port you'll probably want two cable. The first is a male A to male mini-B cable to allow the board to be used in gadget mode. This cable will also allow you to power the board via USB. The other type of cable is a male mini-A to female A cable, which allows the OTG port to act as host - but since all new BeagleBoards have a standard full-size USB host port this could be an optional purchase. Finding places selling male mini-A to female A cables is a bit tricky - Special Computing sell them, as does this amazon seller.
  • SD/MMC cards. Although the BeagleBoard does have 256MB of internal flash, it's not the best choice of storage medium for a writeable filesystem because it lacks hardware wear levelling. The NAND chip on the BeagleBoard is soldered ontop of the CPU and RAM, so there's no way of replacing it - unlike a cheap and disposable SD/MMC card.
    With that in mind you'll want at least one SD/SDHC or MMC card to use with the board, or more if you're doing serious development work or want to easily use multiple operating systems. For maximum compatability you'll want to make sure that the cards are supported by the ROM bootloader - this means they must be 3V 4 bit cards. Even though new versions of X-loader and U-Boot will work with cards which the ROM bootloader won't, it's a good idea to have at least one ROM bootable card around the place in case you corrupt the copies of X-loader/U-Boot that are held in the internal NAND memory. Also remember to get a USB SDHC/MMC card reader if your computer lacks one.
  • Audio, S-Video cables. Depending on exactly what you're using the board for, you may want audio and/or S-Video cables to hook it up to speakers, a mic, and/or a TV/monitor with S-Video input.
There are certain tasks related to board setup that will need to be performed on a computer other than your BeagleBoard. These are:
  • Formatting SD cards. The ROM bootloader only accepts them if they're formatted correctly, which they might not be when you purchase them. A Windows, Linux or Mac OS X PC should suffice for this.
  • Compiling OS images. For compiling RISC OS you'll need a RISC OS machine to do the compiling, and a Windows/Linux/Mac machine for fetching source from CVS using ROOL's shell scripts. For compiling other operating systems, such as Linux or Android, you'll most likely need a real Linux machine, or at least a virtual machine - I don't think there's any guarantee that Cygwin or Mac OS will work correctly with the build systems that most OS distributions use.
  • Installing OS images. Most BeagleBoard linux distributions use SD cards with two partitions - a bootloader-compatible FAT partition containing the kernel, and an ext2/3 partition containing the OS filesystem. To set this up correctly a Linux PC or a virtual machine is needed (Mac OS X will probably do the trick also). Windows alone is unlikely to work, due to poor support for ext2/3 and SD cards with multiple partitions.
  • Communicating with the board. Any computer with a serial port, including RISC OS machines, should be able to do this. You can communicate with recent versions of U-Boot using the USB OTG port instead of the serial port, but unless the OS you're running on the board also supports using the OTG port in that manner you may run into some difficulty if the OS takes a dislike to your keyboard/mouse/monitor.

What to do when your board arrives

The first thing to do when your board arrives is to make sure that it works! The best way to do this is by following the instructions in the BeagleBoard System Reference Manual, or on the BeagleBoard wiki. This should also serve to familiarise you with terminology such as X-loader, U-boot, and the tasks required to create bootable SD cards. If you want to try a more complete system to test out your board, you can also try out the Angstrom Linux demo image, although if you're unfamiliar with linux you may struggle to do some of the more useful tasks such as changing the screen mode, running the omapfbplay video player, or installing new software.
 
After that you'll probably be wanting to try out RISC OS - in which case the guide on the ROOL wiki should contain everything you need to know about building the source and starting the ROM image (skip the start bit and scroll down to 'Getting started with the source code').

BeagleBoard impressions

There are several operating systems available for the BeagleBoard at the moment - Angstrom Linux, Ubuntu Linux, Android (itself based around a Linux kernel), Windows CE, and of course RISC OS. Angstrom is widely regarded as being the Linux distribution with the most support for the board and its features, so here I take a look at how it compares to RISC OS in terms of functionality and ease of use.

Angstrom Linux

After playing with Angstrom for a while, using both the demo image and my own self-built one, a few things became clear to me. Angstrom Linux, despite having its roots in ARM-powered PDAs such as the Zaurus range, still appears to suffer from the same problem as most other Linux distributions - the desktop experience is rather lacking. Beyond the SD indicator light flashing there's no indication whether the program you just clicked on is launching or whether it has silently failed. The Angstrom display manager doesn't yet support the new OMAP display drivers, so you're only able to change the desktop resolution by changing the kernel boot parameters, or entering the right values into a terminal window and restarting X. Angstrom also seems to be rather heavy on memory utilisation, with the memory monitor app reporting that around 100MB of the boards 256MB had been used by the time the desktop was reached.
 
But on the bright side, Angstrom does get several things right. It's the only Linux distribution to support all of the boards hardware features out-of-the-box, and installing extra software using the Angstrom package manager is easy (even if the online package browser is a bit broken at the moment). Firefox 3 seemed responsive, apart from the long time it takes to load pages - although I have a feeling that was more to do with dodgy USB drivers than a fault in Firefox itself.
 
It will be interesting to see what improvements are made to Angstrom once commercial devices such as the Pandora start shipping.

RISC OS

A lot of people seem to be interested in when the right time is to start buying BeagleBoards, Pandoras, Touch Books or whatever for general RISC OS work, so I might as well give an overview of where the RISC OS port currently stands and how it stands up to its main competitor, Angstrom Linux.
 
The most important thing to mention is that it's not yet a polished experience. There's no support for automatically loading/saving the CMOS RAM state, so the OS will always boot to the supervisor prompt. RISC OS also takes several seconds to reach the supervisor prompt instead of 1-2 seconds, due to the current slow implementation of the RAM clear code. If you're board is powered by the hub that the board is using for USB ports, then it will take even longer, as RISC OS attempts to poll the unresponsive USB OTG port. There's no !Boot sequence publicly available that is tailored to the hardware, so you'll have to build your own if you want to try running most apps from the desktop. The driver for the USB host port, although mostly functional, appears to have flaky device insertion/removal detection, so hotplugging storage devices often results in the dreaded 'Ambiguous disc name' error from SCSIFS. Performance of filecore-formatted USB drives is atrocious - an 8GB class 6 SDHC card, which should give at least 6MB/s read/write performance, takes up to two minutes to mount and only offers ~500KB/s transfer rate. Changing screen mode runs a risk of about 1 in 5 that the computer will lock up. Changes in the instruction set related to unaligned loads/stores means that, for the moment at least, most precompiled software won't run. A bug somewhere prevents you from setting the system clock to the correct time and date. Even if you could set the correct time and date, the lack of backup battery on current BeagleBoards means you'd have to reset the clock each time the computer boots (although this could be fully automated once the USB network drivers are more mature). There's currently no support for hardware acceleration of graphics redraws, so although some aspects of the desktop are responsive others are not (e.g. the 10 or so seconds it takes for '*modules' to complete its listing if you enter it after hitting F12 while in a high-resolution screen mode). There's also no support for any hardware differences between devices that use the OMAP3530, so even if you had a Pandora or Touch Book in your hands right now the chances are that RISC OS won't run on it.
 
But on the bright side, all of the above can and will be fixed, hopefully in time for the first consumer-oriented machines to start hitting the market. Even at this early stage it's clear to me that RISC OS still beats Linux in terms of memory usage, desktop responsiveness, and user-friendliness of application launching. If netbook manufacturers think that ARM netbook users won't be too worried about their inability to run Windows apps on ARM Linux, perhaps we'll be able to tempt a few ARM Linux users onto an operating system that provides a better desktop experience?

Benchmarks

Enough of the pointless speculation of about the OMAP's performance relative to existing RISC OS machines. Let's have some pointless benchmarks instead!

Dhrystone

Dhrystone is a benchmark that's often abused by people using compilers that detect the Dhrystone source code and replace it with hand-optimised assembler. But regardless of that, it can still be a useful benchmark, especially if you're in control over which compiler and settings are used.
 
Using RISC OS GCC 3.4.6 r3, I compiled the Dhrystone benchmark program, using the sources that are supplied with GCC. The Dhrystone program was then used to compare the performance of a BeagleBoard (running at the default CPU clock speed of 500MHz) and my Iyonix, resulting in performance figures in both Dhrystones/sec and DMIPS. Overall I ran the test twice - once without any optimisation, and once with ordinary -O2 optimisation. In the results, higher numbers = better.
 

Compiler settingIyonix scoreBeagleBoard scoreRelative performance
-O0 -mlibscl395296.6 dhry/s = 225 DMIPS467289.7 dhry/s = 266 DMIPS118%
-O2 -mlibscl806451.6 dhry/s = 459 DMIPS1176470.6 dhry/s = 670 DMIPS145%

 
Although these results fall rather short of the 1,200 DMIPS that ARM claim, they do show the speed advantage the Cortex has when performing CPU-intensive tasks using code produced by a standard compiler using standard optimisation settings.

Ackermann

The Ackermann benchmark is meant to be something to do with measuring the coding efficiency of procedures. That's about all I know about it, except that depending on the input parameters it will either complete the benchmark almost immediately or take longer than my patience (e.g. 10 seconds). Once again GCC 3.4.6 r3 was used to compile the source, both with and without optimisation. The resulting executables were run with '3 9' as the parameters. In the results, lower numbers = better.
 

Compiler settingIyonix scoreBeagleBoard scoreRelative performance
-O0 -mlibscl534150356%
-O2 -mlibscl20396211%

RISC OS mark

Finally something a bit easier to understand, and with benchmark results readily available for a variety of RISC OS machines. For these tests, RISC OS mark 1.01 was used to compare my RISC OS 5.12 Iyonix, running at 1920x1200x16M, against the 500MHz BeagleBoard at 1280x1024x16M. Note that the percentage scores as produced by RISC OS mark are relative to the base system of a 200MHz StrongARM RiscPC, so if you own one of those you'll have an indication of how well a BeagleBoard compares to that.
 

TestIyonix scoreBeagleBoard scoreRelative performance
Processor260%294%113%
Memory (copy 128KB block)187%1089%582%
Memory (copy 1MB block)200%832%416%
Rectangle copy1483%38%2.5%
Icon plotting181%305%168%
Draw path95%163%171%
Draw fill53%150%283%
HD read (MB/s)151.38.6%
HD write (MB/s)391.33.3%
FS read (KB/s)252020.0008%
FS write (KB/s)271920.0008%

 
A few notes about these scores:
  • The default RISC OS mark memory test of copying a 128KB block would have caused the results to be heavily skewed by the 256KB L2 cache on the beagleboard, so the memory test was performed twice - once with a 128KB block and once with a 1MB block.
  • The rectangle copy operation has the potential to be sped up significantly once code is written to make use of the OMAP's DMA engine for hardware acceleration. The DMA engine in the OMAP is capable of rectangle copies, fills, and rotations, so should easily provide a level of hardware acceleration similar to that available with the Iyonix or ViewFinder/V-Pod equipped RiscPCs
  • The Iyonix was using an IDE hard disc, whereas the BeagleBoard was using dog-slow USB mass storage. This is why the filesystem scores for the BeagleBoard are so low. These scores should improve over time now that the USB stack and USB mass storage drivers are a more important part of the OS.

!Befunge

I would have chosen something more useful for this last test, such as compressing files using command-line zip, but I was unable to find a compiler setting that would produce a working executable (presumably due to unaligned load/store issues). So instead I decided to try !Befunge, my WIMP Befunge interpreter, which luckily ran without any problems. To test the relative performance of the two systems I ran my turtle quine through the interpreter. On the Iyonix it completed in approximately 70 seconds, while on the BeagleBoard it took approximately 23, resulting in a relative performance of 304% (saving the resulting DrawFile to RAM disc instead of USB to avoid a nasty penalty).

Conclusion

What the OMAP3530 gives with one hand it takes away with the other. Although it's undoubtedly going to be the most powerful ARM CPU to run RISC OS, it's also going to require a certain amount of hard work from OS and application developers in order to support the new hardware features such as the VFPU, and to work around architecture changes such as the handling of unaligned loads/stores. The OMAP3530 may not offer high-resolution screen modes or a fast expansion bus, but it's an important platform to support if we want to see RISC OS running natively on affordable new hardware instead of just under emulators or geriatric RiscPC's.
 

  RISC OS on OMAP - the future?
  flibble (12:12 19/5/2009)
  Chris (16:53 19/5/2009)
    tlsa (22:44 20/5/2009)
      glavallin (04:51 20/9/2009)
        Phlamethrower (13:08 21/9/2009)
          bhtooefr (14:32 21/9/2009)
            epistaxsis (16:15 21/9/2009)
              swirlythingy (21:33 22/9/2009)
                epistaxsis (09:19 30/9/2009)
                  Phlamethrower (10:21 30/9/2009)
                    epistaxsis (11:23 30/9/2009)
                      Phlamethrower (13:30 30/9/2009)
                        hubersn (22:51 30/9/2009)
                        Phlamethrower (02:25 1/10/2009)
                          epistaxsis (14:47 1/10/2009)
                            epistaxsis (01:46 5/10/2009)
                              bhtooefr (03:27 5/10/2009)
                                epistaxsis (04:00 5/10/2009)
                    hubersn (12:30 30/9/2009)
  epistaxsis (17:11 19/5/2009)
    Bucksboy (18:17 19/5/2009)
      filecore (19:34 19/5/2009)
        epistaxsis (20:53 19/5/2009)
          Monty (21:20 19/5/2009)
    flibble (22:49 19/5/2009)
  Phlamethrower (23:05 16/10/2009)
 
Peter Howkins Message #110085, posted by flibble at 12:12, 19/5/2009
flibble

Posts: 863
For the case might I recommend something along the lines of

http://shop.lego.com/ByTheme/Product.aspx?p=6166&cn=348&d=70

Highly extend-able smile
  ^[ Log in to reply ]
 
Chris Message #110087, posted by Chris at 16:53, 19/5/2009, in reply to message #110085
Member
Posts: 283
Great article, and really interesting stuff. These are intriguing times for RISC OS. Getting the OS working reliably on a Beagleboard and related technologies could rekindle interest in the platform as a cool hobby OS. Great work to get things this far along - good luck with polishing off the rest of the project (sounds like there's lots still to do).
  ^[ Log in to reply ]
 
keith dunlop Message #110088, posted by epistaxsis at 17:11, 19/5/2009, in reply to message #110085
epistaxsis

Posts: 159
I expect to see a suitable lego enclosed beagleboard out of you by the time of the next show Peter... smile
  ^[ Log in to reply ]
 
George Greenfield Message #110089, posted by Bucksboy at 18:17, 19/5/2009, in reply to message #110088
Member
Posts: 56
Thanks for a highly informative and thought-provoking article!
  ^[ Log in to reply ]
 
Jason Togneri Message #110090, posted by filecore at 19:34, 19/5/2009, in reply to message #110089

Posts: 3867
Interesting stuff, but I'm having a mental failure when I try to parse "RISC OS" and "future" in the same sentence. That is, without the addition of the words "has no". This is strange and frightening.
  ^[ Log in to reply ]
 
keith dunlop Message #110091, posted by epistaxsis at 20:53, 19/5/2009, in reply to message #110090
epistaxsis

Posts: 159
Interesting stuff, but I'm having a mental failure when I try to parse "RISC OS" and "future" in the same sentence. That is, without the addition of the words "has no". This is strange and frightening.
BE VERY SCARED wink
  ^[ Log in to reply ]
 
Edward Rogers Message #110092, posted by Monty at 21:20, 19/5/2009, in reply to message #110091
Member
Posts: 154
Interesting stuff, but I'm having a mental failure when I try to parse "RISC OS" and "future" in the same sentence. That is, without the addition of the words "has no". This is strange and frightening.
Surely Riscos is by now well and truly beyond the 'redundant & obsolete' stage. Having managed to safely traverse these reefs without a complete shipwreck, one might say it has passed into the balmy and undemanding waters of the 'sidelined & uncompetitive'. Thats a nice place to be for any system that isn't Windows, Linux or Mac. Lots of free time to tinker and improve without the pressure of sky-high expectations. A modest future for Riscos shouldn't be too difficult to achieve at this level.

[Edited by andypoole at 14:46, 20/5/2009. Added proper quoting.]
  ^[ Log in to reply ]
 
Peter Howkins Message #110093, posted by flibble at 22:49, 19/5/2009, in reply to message #110088
flibble

Posts: 863
You provide me a beagleboard, and I'll make the case wink
  ^[ Log in to reply ]
 
Michael Drake Message #110104, posted by tlsa at 22:44, 20/5/2009, in reply to message #110087

Posts: 1093
Great article, thanks. And thanks for all your work on the OMAP port. grin
  ^[ Log in to reply ]
 
Geoff Lavallin Message #111397, posted by glavallin at 04:51, 20/9/2009, in reply to message #110104
Member
Posts: 39
I have noticed that ARM intend to bring out Cortex A9 dual core processors at 2 Ghz. Is it feasable that the Beagleboard RISCOS 5 port could run on just one of those cores in a computer?
  ^[ Log in to reply ]
 
Jeffrey Lee Message #111429, posted by Phlamethrower at 13:08, 21/9/2009, in reply to message #111397
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
I haven't looked at any of the techincal docs for the Cortex A9, but I doubt there would be any major hurdles to getting RISC OS to run on one of the cores. Just remember that if it involves changing to a new SoC manufacturer then we may need to write a whole load of new device drivers for the rest of the hardware that's in the SoC.
  ^[ Log in to reply ]
 
Eric Rucker Message #111435, posted by bhtooefr at 14:32, 21/9/2009, in reply to message #111429
Member
Posts: 336
That said, the OMAP4440 is launching at 1+ GHz, with a dual-core A9.
  ^[ Log in to reply ]
 
keith dunlop Message #111439, posted by epistaxsis at 16:15, 21/9/2009, in reply to message #111435
epistaxsis

Posts: 159
Well I've just got to get RISC OS 5 running on my beagleboard!

Have had to order a serial cable as banging in a ROM and the boot.scr file didn't work unhappy

Guess my board isn't as spammed up as I thought it would be...

Never mind we'll probably have a fiddle at ROUGOL tonight big grin
  ^[ Log in to reply ]
 
Martin Bazley Message #111472, posted by swirlythingy at 21:33, 22/9/2009, in reply to message #111439

Posts: 460
Never mind we'll probably have a fiddle at ROUGOL tonight big grin
How did the meeting go? I can't believe I had a second chance at seeing RISC OS running on a beagleboard... and missed it again.

It didn't help that the reminder arrived in my inbox the evening after the meeting! tongue

Well, there's still the RISC OS London Show. If I manage to remember to come to that.
  ^[ Log in to reply ]
 
keith dunlop Message #111531, posted by epistaxsis at 09:19, 30/9/2009, in reply to message #111472
epistaxsis

Posts: 159
YESSSSSSS!!!!

Have managed to get my beagleboard to boot into RISC OS! big grin

Now I need to get a clean !Boot folder so I can actually configure it...
  ^[ Log in to reply ]
 
Jeffrey Lee Message #111532, posted by Phlamethrower at 10:21, 30/9/2009, in reply to message #111531
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
YESSSSSSS!!!!

Have managed to get my beagleboard to boot into RISC OS! big grin
Excellent!

Now I need to get a clean !Boot folder so I can actually configure it...
If you're lucky there'll be one appearing on the ROOL site in the next few days. I'm not sure if you can wait that long however wink
  ^[ Log in to reply ]
 
keith dunlop Message #111533, posted by epistaxsis at 11:23, 30/9/2009, in reply to message #111532
epistaxsis

Posts: 159
If you're lucky there'll be one appearing on the ROOL site in the next few days. I'm not sure if you can wait that long however wink
Well I do have a certain RISC OS show deadline looming...

So anything that you can do to help would be appreciated.
  ^[ Log in to reply ]
 
Steffen Huber Message #111534, posted by hubersn at 12:30, 30/9/2009, in reply to message #111532
Member
Posts: 66
I also recently received my BeagleBoard and since then I hope to have a "few minutes spare" to actually set it up...my next best hope is the coming weekend big smile

I really enjoy reading your postings in the ROOL forum, Jeffrey - keep going! IMHO you have already performed a large part of the miracle needed to make RISC OS an interesting, motivating platform again!

I even had a quick look at the SCSISoftUSB code to find out why it won't recognize non-harddrives (i.e. CD/DVD writers). If I understood the code correctly, there are a few but hopefully easily fixable shortcomings.
  ^[ Log in to reply ]
 
Jeffrey Lee Message #111535, posted by Phlamethrower at 13:30, 30/9/2009, in reply to message #111533
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
Well I do have a certain RISC OS show deadline looming...

So anything that you can do to help would be appreciated.
*checks calendar*

Yeah, I guess it's a bit sooner than I thought. I'll sort something out for you tonight and drop you an email (There have been far too many RISC OS shows featuring the BeagleBoard where the desktop hasn't been shown off properly!)

I really enjoy reading your postings in the ROOL forum, Jeffrey - keep going! IMHO you have already performed a large part of the miracle needed to make RISC OS an interesting, motivating platform again!
Cheers!

I even had a quick look at the SCSISoftUSB code to find out why it won't recognize non-harddrives (i.e. CD/DVD writers). If I understood the code correctly, there are a few but hopefully easily fixable shortcomings.
As I understand it the NetBSD code that SCSISoftUSB is based around supported a fair number of different device types. However I think almost all the code unrelated to the SCSI protocol has been removed. So if you're thinking of updating it to support CD/DVD drives then it's probably a good idea to take a look at the relevant NetBSD sources.
  ^[ Log in to reply ]
 
Steffen Huber Message #111539, posted by hubersn at 22:51, 30/9/2009, in reply to message #111535
Member
Posts: 66
I even had a quick look at the SCSISoftUSB code to find out why it won't recognize non-harddrives (i.e. CD/DVD writers). If I understood the code correctly, there are a few but hopefully easily fixable shortcomings.
As I understand it the NetBSD code that SCSISoftUSB is based around supported a fair number of different device types. However I think almost all the code unrelated to the SCSI protocol has been removed. So if you're thinking of updating it to support CD/DVD drives then it's probably a good idea to take a look at the relevant NetBSD sources.
It would certainly be a good idea to compare the code to the latest *BSD efforts. And to find out which devices *BSD supports nowadays.

The part of the code I identified actually restricts the allowed SCSI commands to the 10 byte variants of READ, WRITE and VERIFY. Good enough for harddrives and alikes, but for MMC devices, you need full support for 6/10/12 byte commands and basically all variants of commands (it would be reasonably easy to put in support for all commands CDVDBurn currently uses, but a bit harder to provide full transparency for all SCSI device types).

Ah well, that damned weekend is too far away...
  ^[ Log in to reply ]
 
Jeffrey Lee Message #111542, posted by Phlamethrower at 02:25, 1/10/2009, in reply to message #111535
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
Well I do have a certain RISC OS show deadline looming...

So anything that you can do to help would be appreciated.
*checks calendar*

Yeah, I guess it's a bit sooner than I thought. I'll sort something out for you tonight and drop you an email (There have been far too many RISC OS shows featuring the BeagleBoard where the desktop hasn't been shown off properly!)
Hmm, the email address on your website doesn't seem to work ("550 email account no longer in use" error). If the boot sequence hasn't appeared on the ROOL site by the time you read this (the source is now in CVS so you could build it yourself if you feel adventurous!) then drop me an email and I'll send a copy of the boot sequence your way.
  ^[ Log in to reply ]
 
keith dunlop Message #111544, posted by epistaxsis at 14:47, 1/10/2009, in reply to message #111542
epistaxsis

Posts: 159
Hmm, the email address on your website doesn't seem to work ("550 email account no longer in use" error). If the boot sequence hasn't appeared on the ROOL site by the time you read this (the source is now in CVS so you could build it yourself if you feel adventurous!) then drop me an email and I'll send a copy of the boot sequence your way.
takes foot out of mouth Sorry I had forgotten to change my address in my profile blush anyway emailed you smile <-- have to really as I still haven't worked out how to get CVS working on my linux machine (which amusingly is an EeePC running Ubuntu NBR...)
  ^[ Log in to reply ]
 
keith dunlop Message #111564, posted by epistaxsis at 01:46, 5/10/2009, in reply to message #111544
epistaxsis

Posts: 159
http://epistaxsis.co.uk/beagleboard/screen.jpg

big grin
  ^[ Log in to reply ]
 
Eric Rucker Message #111565, posted by bhtooefr at 03:27, 5/10/2009, in reply to message #111564
Member
Posts: 336
Huh, is the Steel theme the default now? Really, it does look a lot cleaner and more modern than the other themes.
  ^[ Log in to reply ]
 
keith dunlop Message #111566, posted by epistaxsis at 04:00, 5/10/2009, in reply to message #111565
epistaxsis

Posts: 159
heh not quite!

The themes configure plug in works smile
  ^[ Log in to reply ]
 
Jeffrey Lee Message #111652, posted by Phlamethrower at 23:05, 16/10/2009, in reply to message #110085
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
For the case might I recommend something along the lines of

http://shop.lego.com/ByTheme/Product.aspx?p=6166&cn=348&d=70

Highly extend-able smile
My parents are moving house, so a couple of weeks ago they came by and dumped a load of my Lego with me. Which means...

(dodgy webcam alert!)

The board is just about 10x10 studs in size, so it fits quite nicely in a 12x12 box. And the two buttons line up OK with the two axles sticking out the top.

I do need to adjust the design a bit further so it fits the L-shaped jack of my DC adaptor, and I also need to add a hole somewhere so I can connect the serial cable.

[Edited by Phlamethrower at 23:10, 16/10/2009]
Picture 9.jpg 640x480 262.4KB
Picture 9.jpg
640x480
262.4KB
Picture 10.jpg 640x480 262.2KB
Picture 10.jpg
640x480
262.2KB
Picture 17.jpg 640x480 261.8KB
Picture 17.jpg
640x480
261.8KB
Picture 25.jpg 640x480 276.8KB
Picture 25.jpg
640x480
276.8KB

  ^[ Log in to reply ]
 

The Icon Bar: News and features: RISC OS on OMAP - the future?