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: - 126.96.36.199 only one usb dma channel (rx or tx) can be active at one time: use interrupt mode instead - 188.8.131.52 otg soft reset doesn't work right - 184.108.40.206 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.