I want to play with Linux (inc. maybe Android) on ARM platforms, and figured the Raspberry Pi would be a good target platform, albeit hard to get my hands on right now.
Has anyone here played with this who can give me any suggestions as to where I should start? I can see various suggestions on the R.Pi website (QEMU or Scratchbox) so I'm really just asking to seek the benefit of anyones experience here, otherwise I'll pick one of the examples out there and see where it gets me.
Separately: I've not done a lot with ARM in the past. How transferable are skills learned (and code written) between ARM platforms? I quite like the look of some of the ARM dev boards you can get on eBay, for example, and I'm sure the range of options will only increase over time, so I don't want to tie myself to the R.Pi any more than I need to at this stage.
On Mon, Apr 16, 2012 at 02:01:24PM +0100, Mark Rogers wrote:
Separately: I've not done a lot with ARM in the past. How transferable are skills learned (and code written) between ARM platforms? I quite like the look of some of the ARM dev boards you can get on eBay, for example, and I'm sure the range of options will only increase over time, so I don't want to tie myself to the R.Pi any more than I need to at this stage.
I'm doing some vaguely commercial (i.e. I might get paid a bit for it) work on an ARM based board - it's the SolderCore board, you'll find some information at soldercore.com but there are major changes going on to the way the business is managed at the moment so things are a bit 'fluid'.
I'm using the (commercial I'm afraid) Crossworks IDE by Rowley Associates, I'm not very impressed with it really, there's too much in it and so it's overly complex.
As a general comment about working with ARM it *seems* a bit of a complex mess with loads of variations of the processor and the chips it's available in each of which seems to need a different compiler - or at least a customised set of compiler options.
It's taken me quite a while just to get to the point of getting some sample code to compile and talk to the ethernet interface on the board, however now I'm there I'm hoping to make more rapid progress.
On 16/04/12 14:01, Mark Rogers wrote:
I want to play with Linux (inc. maybe Android) on ARM platforms, and figured the Raspberry Pi would be a good target platform, albeit hard to get my hands on right now.
Has anyone here played with this who can give me any suggestions as to where I should start? I can see various suggestions on the R.Pi website (QEMU or Scratchbox) so I'm really just asking to seek the benefit of anyones experience here, otherwise I'll pick one of the examples out there and see where it gets me.
Separately: I've not done a lot with ARM in the past. How transferable are skills learned (and code written) between ARM platforms? I quite like the look of some of the ARM dev boards you can get on eBay, for example, and I'm sure the range of options will only increase over time, so I don't want to tie myself to the R.Pi any more than I need to at this stage.
If all you want to do is gain some experience of ARM coding, have you thought of RPCEmu? The original Risc PC by Acorn was developed from the Archimedes which used an ARM2 chip, later upgraded to ARM3.
The Risc PC started with an ARM610 CPU and was later upgraded to a StrongARM. These are all options on the RPCEmu menu. A compiler is available as is an inbuilt assembler if you have, or want experience in that area.
All of that is free of course, save the cost of the ROMs for RPCEmu - a fiver from RiscOS.com.
Although I run RPCEmu here, I'm thinking of buying a Raspberry Pi but not quite sure why! I just like to tinker though so perhaps that explains it.
On 16/04/12 15:49, Chris Walker wrote:
If all you want to do is gain some experience of ARM coding, have you thought of RPCEmu? The original Risc PC by Acorn was developed from the Archimedes which used an ARM2 chip, later upgraded to ARM3.
See reply to Tony: I do have an R.Pi on order (and even if I hadn't I'd get one as soon as I could because I think they're a great idea), so it probably makes sense to start with that? Although having some idea how portable what I'm doing is would be helpful - and from Chris Green's comments it's going to be "not very"....
Just to be clear, I'm working on a starting assumption that whatever I play with will already have a Linux port, ideally something Debian/Ubuntu-like, so hopefully a large part of the architectural differences will be taken out of my way by the O/S. I am keen to make sure what I write isn't making any architectural assumptions though, so having multiple architectures to play will would be useful.
I don't have specific projects in mind, but getting a LAMP stack (or similar) up and running as a starting point gives me plenty to play with.
On 16 Apr 2012, at 14:01, Mark Rogers wrote:
Separately: I've not done a lot with ARM in the past. How transferable are skills learned (and code written) between ARM platforms? I quite like the look of some of the ARM dev boards you can get on eBay, for example, and I'm sure the range of options will only increase over time, so I don't want to tie myself to the R.Pi any more than I need to at this stage.
ARM covers quite a range, from full debian installs to bare cpu with 32K. The higher end boards, quite standard linux. Some of the smaller systems are, well, standard embedded linux, openwrt+busybox+uboot. These are quite transferrable to various boards and even architectures. The os free systems, though... The details tend to be quite different between boards. Different toolchains, compiler options, jtag. Never mind peripherals! But the workflow is quite similar. Bill
On 16/04/12 21:41, Bill Hill wrote:
ARM covers quite a range, from full debian installs to bare cpu with 32K. The higher end boards, quite standard linux. Some of the smaller systems are, well, standard embedded linux, openwrt+busybox+uboot. These are quite transferrable to various boards and even architectures. The os free systems, though... The details tend to be quite different between boards. Different toolchains, compiler options, jtag. Never mind peripherals! But the workflow is quite similar. Bill
Well I've just ordered: http://www.ebay.co.uk/itm/320786483250 based on a Samsung S3C6410 ARM1176JZFS chip, which I believe is the same as the Raspberry Pi (albeit that the Pi uses a Broadcom chip). Lead time on the board from eBay is 3-5 weeks so who knows whether the Pi will get here first anyway!
So I seem to have hung my coat on the ARM11 hook for now...
On Tue, 17 Apr 2012 11:56:27 +0100 Mark Rogers mark@quarella.co.uk allegedly wrote:
So I seem to have hung my coat on the ARM11 hook for now...
Mark
If you are not already subscribed, it may be worth taking a look at the debian-arm list at debian-arm@lists.debian.org. There is frequently a lot of discussion there about the relative merits of various development boards/tool chains etc. (And there is an entertainig character called luke kenneth casson leighton who frequently posts about getting people on board to get development going for cheap SOCs in china.)
Mick --------------------------------------------------------------------- blog: baldric.net fingerprint: E8D2 8882 F7AE DEB7 B2AA 9407 B9EA 82CC 1092 7423 ---------------------------------------------------------------------
On 17/04/12 15:42, mick wrote:
If you are not already subscribed, it may be worth taking a look at the debian-arm list at debian-arm@lists.debian.org. There is frequently a lot of discussion there about the relative merits of various development boards/tool chains etc. (And there is an entertainig character called luke kenneth casson leighton who frequently posts about getting people on board to get development going for cheap SOCs in china.)
Thanks, I've just spent a few informative hours reading through the archives.
One thing I am quickly realising is just how little I know about ARM, and I'm struggling to find a decent introduction. Also, from playing with QEMU, I'm realising how little I know about the boot process. This is going to be interesting! It seems that I've become a little bit lazy over the years, and I'm going to have to get out of the cozy world of "apt-get install" to get far with ARM.
On 18/04/12 11:34, Mark Rogers wrote:
One thing I am quickly realising is just how little I know about ARM, and I'm struggling to find a decent introduction.
Found this:
http://blogs.arm.com/software-enablement/605-arm-fundamentals-introduction-t... .. which was very useful.
It looks like my two boards (the Mini6410 off eBay and the Raspberry PI) both use the same CPU spec (ARM1176JZF-S, ARMv6), but with different GPU. For my intended apps video performance isn't an issue although I would at least like to be able to get something onto the screen!
Fedora and Debian, amongst others, seem to support ARMv6, although some distros (Ubuntu in particular) seem to have jumped to ARMv7 as a minimum spec. Although Ubuntu seem unmoved by the calls for them to support the R.Pi, it does look like the existence of the Pi will cause support for ARMv6 to improve in general rather than die out as would be expected of such an old architecture, and indeed I would be surprised if there isn't a community supported Ubuntu variant in due course (although how well it would support the GPU on my Mini6410 is another matter). Personally I'm used to Ubuntu's way of doing things but I can cope with RPM if needed so both Fedora and Debian are options (Fedora currently looks better prepared for the R.Pi).
Am I being naive to assume that regardless of GPU, basic (VGA) graphics should be supported without any difficulty?
To what extent should I look at Android, given it's strong support for ARM? If I have an Android install, how easy is it to add a LAMP stack to it?
Incidentally, if you have an ARM-based Android smartphone, you can install your favourite distro in a chroot thereon, and happily develop away. There's a Debian-focused tutorial on this at http://evilzone.org/android/debian-on-android/, and a Gentoo-focused one at http://forum.xda-developers.com/showthread.php?t=789003. Although if you're considering Gentoo, be aware that large packages can compile _very_ slowly in this environment.