Arm ports update

Geoff Collyer has provided news on the arm ports

   From: geoff@pla...
   Subject: changes to the ARM SoC ports
   Date: Tue, 27 Apr 2010 15:05:02 -0400

   booting(8) has been updated; take a look if you're using an ARM port.

   On the Kirkwood SoCs (Sheevaplug and Openrd-client), USB now works.
   Nemo was helpful fixing this, as usual.

   One of the people here is working on using the Kirkwood crypto
   acceleration hardware.

   The OMAP3530 port is now available in /sys/src/9/omap.  It currently
   runs on the IGEPv2 board.  The hardware can execute VFPv3
   floating-point instructions, but 5[cal] don't generate them yet, so
   floating-point is currently emulated.  USB isn't quite working yet.
   Once it is, we should be able to use USB Ethernet and thus run on
   Beagleboards.  The ohci and ehci controllers are seen, but no devices
   yet.  There are several USB errata that need to be looked into.  From
   the latest omap3530 errata:

   - 3.1.1.130 only one usb dma channel (rx or tx) can be active
          at one time: use interrupt mode instead
   - 3.1.1.144 otg soft reset doesn't work right
   - 3.1.1.183 ohci and ehci controllers cannot work concurrently
   - §3.1.3 usb limitations: all ports must be configured to identical speeds
          (high vs full/low)

   This port is being made available now primarily as a basis for GSoC
   students; we expect it to improve.

   Rae McLellan of Bell Labs deserves thanks for helping to decrypt what
   passes for hardware documentation these days.

Mail thread here.

Information on the Plan 9 GSoC project is available here.

   From: geoff@pla...
   Subject: arm ports update
   Date: Wed, 12 May 2010 23:42:50 -0400

   The kw port now supports the Guruplug Server Plus, including both
   Ethernet interfaces, and probably the other Guruplugs.  booting(8) now
   has the necessary instructions to get started.  They are more diverse
   than one might like because every version of u-boot we get for a new
   board seems to have had the dhcp, bootp and tftp commands tinkered
   with to behave slightly differently.  We have two Guruplugs and one
   has been stable but the other is prone to random resets (and runs much
   warmer than the Sheevaplugs).  I'd be interested in hearing from
   anyone else who sees random resets.

   I've imported the flash memory support from native Inferno, other than
   the flash translation layer, which was developed for nor flash and is
   suspect with nand flash.  flash(3) describes the interface.  It seems
   to work on the Kirkwood boards, but I haven't exercised it
   extensively.  It does implement software ECC.  /dev/flash looks like
   it always returns zero bytes on the igepv2 board, but lack of
   documentation makes it a little hard to tell what to expect.

Mail thread here.

Information on the kirkwood is available in this pdf. (5495468kb)

To post a comment you need to login first.