Is it possible to put OpenFirmware on an SD card and use it to boot off e.g. a USB-attached mass storage device or using TFTP over a LAN? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
As far as I know, nobody has ported OFW to Raspberry Pi yet, but it would be easy to do. Once ported, OFW could then boot something else (e.g. Linux) from USB or LAN. OFW's network stack supports many other protocols in addition to TFTP. On the OLPC platform, I routinely boot using HTTP over wireless LAN. In the factory, they use OFW to communicate with Windows servers that run SMB/CIFS. If someone will arrange for a Raspberry Pi to arrive at my doorstep, I'll do a quick port. On 9/15/2012 4:19 AM, Mark Morgan Lloyd wrote:
Is it possible to put OpenFirmware on an SD card and use it to boot off e.g. a USB-attached mass storage device or using TFTP over a LAN?
Mitch Bradley wrote:
As far as I know, nobody has ported OFW to Raspberry Pi yet, but it would be easy to do. Once ported, OFW could then boot something else (e.g. Linux) from USB or LAN.
OFW's network stack supports many other protocols in addition to TFTP. On the OLPC platform, I routinely boot using HTTP over wireless LAN. In the factory, they use OFW to communicate with Windows servers that run SMB/CIFS.
If someone will arrange for a Raspberry Pi to arrive at my doorstep, I'll do a quick port.
I don't think I can arrange it, but I know I'm going to be asked where (i.e. what country) your doorstep is :-) -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
On Fri, Sep 14, 2012 at 08:19:28PM +0000, Mark Morgan Lloyd wrote:
Is it possible to put OpenFirmware on an SD card and use it to boot off e.g. a USB-attached mass storage device or using TFTP over a LAN?
I've now a Raspberry Pi (B). The armforth.static in the openfirmware repository as of now (r3683) seems to run: % cpu/arm/Linux/armforth.static cpu/arm/build/builder.dic ok bye % and rebuilding it seems to work fine: % (cd cpu/arm/Linux; make) ... % cpu/arm/Linux/forth cpu/arm/build/builder.dic ok bye % and rebuilding the builder seems to work fine: % (cd cpu/arm/build; make) ... % cpu/arm/Linux/forth cpu/arm/build/basefw.dic ok no-page to-file test words ok bye % So user-mode is probably okay, and a useful tool. It is said [1] that the SoC loads various files and runs them on the (closed) GPU. It then loads kernel.img and runs it on the ARM. % file /boot/kernel.img kernel.img: Linux kernel ARM boot executable zImage (little-endian) % I'm not planning a port, but I thought I'd mention what I've found so far, in case anybody is interested. The porting would be drivers for serial, SD, ethernet, and USB, possibly using the kernel sources as reference, given that there's very little data available. References: 1. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=10727 -- James Cameron http://quozl.linux.org.au/
On 6/25/2013 2:22 PM, James Cameron wrote:
On Fri, Sep 14, 2012 at 08:19:28PM +0000, Mark Morgan Lloyd wrote:
Is it possible to put OpenFirmware on an SD card and use it to boot off e.g. a USB-attached mass storage device or using TFTP over a LAN?
I've now a Raspberry Pi (B).
The armforth.static in the openfirmware repository as of now (r3683) seems to run:
% cpu/arm/Linux/armforth.static cpu/arm/build/builder.dic ok bye %
and rebuilding it seems to work fine:
% (cd cpu/arm/Linux; make) ... % cpu/arm/Linux/forth cpu/arm/build/builder.dic ok bye %
and rebuilding the builder seems to work fine:
% (cd cpu/arm/build; make) ... % cpu/arm/Linux/forth cpu/arm/build/basefw.dic ok no-page to-file test words ok bye %
So user-mode is probably okay, and a useful tool.
It is said [1] that the SoC loads various files and runs them on the (closed) GPU. It then loads kernel.img and runs it on the ARM.
% file /boot/kernel.img kernel.img: Linux kernel ARM boot executable zImage (little-endian) %
I'm not planning a port, but I thought I'd mention what I've found so far, in case anybody is interested. The porting would be drivers for serial, SD, ethernet, and USB, possibly using the kernel sources as reference, given that there's very little data available.
http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripheral... describes the peripherals. The mini UART looks pretty much like the 16550 (PC COM port) UART that everybody seems to use as a programming model these days, so no drama there. The EMMC controller looks like the common SDHCI programming model. Same old same old. The USB controller uses Synopsis IP; it seems like you can get the manual if you register. The Ethernet is on USB - it's inside an SMSC LAN9512 integrated USB hub/ethernet chip. I don't know its details, but in the past, adding OFW support for new USB ethernet interfaces has not proven to be difficult.
References:
1. http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=10727
For interest, a port of a Forth to Raspberry Pi happened in the last couple of months. There's enough working code there to make a port of Open Firmware slightly less effort. https://github.com/organix/pijFORTHos -- James Cameron http://quozl.linux.org.au/
James Cameron wrote:
For interest, a port of a Forth to Raspberry Pi happened in the last couple of months. There's enough working code there to make a port of Open Firmware slightly less effort.
I think the problem here is that for OpenFirmware to really be useful, i.e. to the same extent that it is on Sun systems, it needs to take control as early as possible and in particular shouldn't be loaded from a filesystem which can be screwed. On a Raspberry Pi, that raises two issues: i) The (originally undocumented) Broadcom SoC contains firmware or equivalent hardware to pull a first-stage loader off the SD card. So the SD card is always needed, even though the mechanical connector is known to be one of the less-reliable components and the card itself will, ultimately, have a limited life. ii) If one grits ones teeth and subverts that mechanism, one ends up in control of the SoC rather than in control of the application processer that normally runs Linux. If one instead tolerates the existing multi-stage loader, then one should be able to boot Forth onto the application processor in lieu of Linux. But this breaks the Sun model of "Open Boot in ROM, everything else on disc", and loses the desirable characteristic that any media or controller problem returns you to the "ok" prompt with diagnostic capabilities, and as such I'm not sure it's worth the effort. I'd be interested to know of any low-cost boards which could have OpenFirmware grafted in sufficiently early. A colleague is trying to build some router systems which, as a prerequisite, must have a serial console port. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
On Mon, Jan 05, 2015 at 08:34:45AM +0000, Mark Morgan Lloyd wrote:
James Cameron wrote:
For interest, a port of a Forth to Raspberry Pi happened in the last couple of months. There's enough working code there to make a port of Open Firmware slightly less effort.
I think the problem here is that for OpenFirmware to really be useful, i.e. to the same extent that it is on Sun systems, it needs to take control as early as possible and in particular shouldn't be loaded from a filesystem which can be screwed. On a Raspberry Pi, that raises two issues:
i) The (originally undocumented) Broadcom SoC contains firmware or equivalent hardware to pull a first-stage loader off the SD card. So the SD card is always needed, even though the mechanical connector is known to be one of the less-reliable components and the card itself will, ultimately, have a limited life.
ii) If one grits ones teeth and subverts that mechanism, one ends up in control of the SoC rather than in control of the application processer that normally runs Linux.
If one instead tolerates the existing multi-stage loader, then one should be able to boot Forth onto the application processor in lieu of Linux. But this breaks the Sun model of "Open Boot in ROM, everything else on disc", and loses the desirable characteristic that any media or controller problem returns you to the "ok" prompt with diagnostic capabilities, and as such I'm not sure it's worth the effort.
I agree.
I'd be interested to know of any low-cost boards which could have OpenFirmware grafted in sufficiently early. A colleague is trying to build some router systems which, as a prerequisite, must have a serial console port.
I'm interested too. Perhaps the BeagleBone Black? I've brought up C Forth on the Teensy 3.1, which while it isn't Open Firmware does share some behaviours enough to make me feel at home. But no filesystems or TCP/IP. http://quozl.linux.org.au/cforth-on-teensy/ -- James Cameron http://quozl.linux.org.au/
James Cameron wrote:
On Mon, Jan 05, 2015 at 08:34:45AM +0000, Mark Morgan Lloyd wrote:
If one instead tolerates the existing multi-stage loader, then one should be able to boot Forth onto the application processor in lieu of Linux. But this breaks the Sun model of "Open Boot in ROM, everything else on disc", and loses the desirable characteristic that any media or controller problem returns you to the "ok" prompt with diagnostic capabilities, and as such I'm not sure it's worth the effort.
I agree.
I'd be interested to know of any low-cost boards which could have OpenFirmware grafted in sufficiently early. A colleague is trying to build some router systems which, as a prerequisite, must have a serial console port.
I'm interested too. Perhaps the BeagleBone Black?
I've brought up C Forth on the Teensy 3.1, which while it isn't Open Firmware does share some behaviours enough to make me feel at home. But no filesystems or TCP/IP.
One of the interesting features of OBP/OpenFirmware is the extent that it allows you to explore partition tables etc. so that you can see why things are going wrong. That sort of thing really is valuable for headless systems, I struggled with Slugs as routers for a while and not having a decent console really was a pain. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
As James said, BeagleBone Black could be a contender.
On Jan 4, 2015, at 11:50 PM, Mark Morgan Lloyd <markMLl.openfirmware@telemetry.co.uk> wrote:
James Cameron wrote:
On Mon, Jan 05, 2015 at 08:34:45AM +0000, Mark Morgan Lloyd wrote:
If one instead tolerates the existing multi-stage loader, then one should be able to boot Forth onto the application processor in lieu of Linux. But this breaks the Sun model of "Open Boot in ROM, everything else on disc", and loses the desirable characteristic that any media or controller problem returns you to the "ok" prompt with diagnostic capabilities, and as such I'm not sure it's worth the effort. I agree. I'd be interested to know of any low-cost boards which could have OpenFirmware grafted in sufficiently early. A colleague is trying to build some router systems which, as a prerequisite, must have a serial console port. I'm interested too. Perhaps the BeagleBone Black? I've brought up C Forth on the Teensy 3.1, which while it isn't Open Firmware does share some behaviours enough to make me feel at home. But no filesystems or TCP/IP. http://quozl.linux.org.au/cforth-on-teensy/
One of the interesting features of OBP/OpenFirmware is the extent that it allows you to explore partition tables etc. so that you can see why things are going wrong. That sort of thing really is valuable for headless systems, I struggled with Slugs as routers for a while and not having a decent console really was a pain.
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________ openfirmware mailing list openfirmware@openfirmware.info http://www.openfirmware.info/mailman/listinfo/openfirmware
Mitch Bradley wrote:
On Jan 4, 2015, at 11:50 PM, Mark Morgan Lloyd <markMLl.openfirmware@telemetry.co.uk> wrote: James Cameron wrote:
On Mon, Jan 05, 2015 at 08:34:45AM +0000, Mark Morgan Lloyd wrote:
If one instead tolerates the existing multi-stage loader, then one should be able to boot Forth onto the application processor in lieu of Linux. But this breaks the Sun model of "Open Boot in ROM, everything else on disc", and loses the desirable characteristic that any media or controller problem returns you to the "ok" prompt with diagnostic capabilities, and as such I'm not sure it's worth the effort. I agree. I'd be interested to know of any low-cost boards which could have OpenFirmware grafted in sufficiently early. A colleague is trying to build some router systems which, as a prerequisite, must have a serial console port. I'm interested too. Perhaps the BeagleBone Black? I've brought up C Forth on the Teensy 3.1, which while it isn't Open Firmware does share some behaviours enough to make me feel at home. But no filesystems or TCP/IP. http://quozl.linux.org.au/cforth-on-teensy/ One of the interesting features of OBP/OpenFirmware is the extent that it allows you to explore partition tables etc. so that you can see why things are going wrong. That sort of thing really is valuable for headless systems, I struggled with Slugs as routers for a while and not having a decent console really was a pain.
As James said, BeagleBone Black could be a contender.
I agree, but the only mention I see of the combination turns out to be limited to DeviceTree. Another alternative would obviously be one of the resurgent MIPS boards. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
participants (4)
-
James Cameron -
Mark Morgan Lloyd -
Mitch Bradley -
Mitch Bradley