Does GHC 7.8 make targeting bare metal ARM any easier?
There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar. Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot. With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box. Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc). I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked? - jeremy
Hello Jeremy, I'd also like to see GHC compiling for ARM bare metal. Honestly speaking I've avoided Raspberry Pi, but rather settled on ARMv7. Side note: BeagleBone is excellent for this as you get all the TI supported tools together with JTAG debugging just for free from TI (including ARM compilers if you care about this) and also you get full documentation for its Sitara 335x SoC. Anyway, back to the GHC topic. I find it too invasive to go straight from POSIX/libc dependency to nothing on bare-metal. Instead of this while analyzing the situation for myself I've rather settled on POSIX RTOS which is much less weight that general purpose Linux distro and yet it provides a lot of API which makes GHC RTS porting work much easier. So as my hobby time permits I'm working on GHC port to RTEMS[1] which is a single-process, multi-threaded RTOS with POSIX API supported. On its devel mailing list you may find that Raspberry Pi BSP was already submitted for inclusion. Generally speaking, I also hope that since this work is much less invasive on GHC, it has higher chance of a merge into GHC HEAD once ready... Cheers, Karel [1]: http://www.rtems.org/ On 03/20/13 02:07 AM, Jeremy Shaw wrote:
There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar.
Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot.
With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box.
Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc).
I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked?
- jeremy
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Wed, Mar 20, 2013 at 08:05:04AM +0100, Karel Gardas wrote:
Hello Jeremy,
I'd also like to see GHC compiling for ARM bare metal. Honestly speaking I've avoided Raspberry Pi, but rather settled on ARMv7. Side note: BeagleBone is excellent for this as you get all the TI supported tools together with JTAG debugging just for free from TI (including ARM compilers if you care about this) and also you get full documentation for its Sitara 335x SoC.
Anyway, back to the GHC topic. I find it too invasive to go straight from POSIX/libc dependency to nothing on bare-metal. Instead of this while analyzing the situation for myself I've rather settled on POSIX RTOS which is much less weight that general purpose Linux distro and yet it provides a lot of API which makes GHC RTS porting work much easier.
So as my hobby time permits I'm working on GHC port to RTEMS[1] which is a single-process, multi-threaded RTOS with POSIX API supported. On its devel mailing list you may find that Raspberry Pi BSP was already submitted for inclusion. Generally speaking, I also hope that since this work is much less invasive on GHC, it has higher chance of a merge into GHC HEAD once ready...
This is exactly what I've been telling my colleagues (who like me mostly are stuck working with C on embedded devices) is what we *really* ought to be doing. :) Is there anything I can do to help out? Are you doing this work in the open? Can I find the code somewhere? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Perl is another example of filling a tiny, short-term need, and then being a real problem in the longer term. -- Alan Kay
kiwamu has been targeting an arm cortex-m3 succesfully with jhc. this
is a CPU with 40k of RAM running Haskell code very much on bare metal.
:)
John
On Tue, Mar 19, 2013 at 6:07 PM, Jeremy Shaw
There have been at least a couple projects, such as hOp and HaLVM which attempt to run GHC on the bare metal or something similar.
Both these projects required a substantial set of patches against GHC to remove dependencies things like POSIX/libc. Due to the highly invasive nature, they are also highly prone to bitrot.
With GHC 7.8, I believe we will be able to cross-compile to the Raspberry Pi platform. But, what really appeals to me is going that extra step and avoiding the OS entirely and running on the bare metal. Obviously, you give up a lot -- such as drivers, network stacks, etc. But, there is also a lot of potential to do neat things, and not have to worry about properly shutting down an embedded linux box.
Also, since the raspberry pi is a very limited, uniform platform, (compared to general purpose PCs) it is feasible to create network drivers, etc, because only one chipset needs to be supported. (Ignoring issues regarding binary blobs, undocumented chipsets, usb WIFI, etc).
I'm wondering if things are any easier with cross-compilation support improving. My thought is that less of GHC needs to be tweaked?
- jeremy
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (4)
-
Jeremy Shaw -
John Meacham -
Karel Gardas -
Magnus Therning