These are a collection of notes for developers. This section is intended to provide information, specifications, descriptions of things that have been tried and not tried, etc. to facilitate new development on the netBook kernel and filesystem. Our present most uptodate kernel is 2.4.21. My own view is that a great deal can be accomplished in kernel development by just poking around the kernel source - I've made a few advancements myself, and if I can do it anyone can! (I don't even know the C programming language!)
We continue to collect any and all information relevant to kernel development, however minor that information may be. We request that should you know of, or develop, information on present on these pages, that you make a post to the psilinux maillists ( linux-7110-psion@lists.sourceforge.net). Please, please, don't try to make things perfect before posting something. Others may be able to provide feedback, and help improve things.
Discussion of linux on ARM processors, and some documentation, can be found at The ARM Linux Project. There is a lot of information for developers at that site.
Documentation on the StrongARM SA-1100 processor (the basis of the Netbook), including GPIOs, serial ports etc can be found in Intel StrongARM SA-1100 Microprocessor Developer's Manual, Order Number: 278088-004, available from the LART website: www.lart.tudelft.nl/doc.php3
Extensive information on the ARM architecture is also available from ARM Ltd (fill in a web form, and they'll mail you a cd full of pdf documentation). www.arm.com/documentation/cd_request.html (useful for the entire psilinux project, not just the netbook)
There is an article by Wookey and Tak-Shing entitled "Porting the Linux Kernel to a New ARM Platform" that provides an overview of the kernel for ARM. You can obtain it locally here: porting2arm_aleph.pdf.
There is a great deal of existing kernel source code for PCMCIA on the SA1100 cpu. Rudimentary development of PCMCIA support on the netBook has occurred so that wireless networking works, but it is still fairly crude.
Debian Woody or openpsion (modified from openzaurus) can now be installed on compactflash. At times, people have taken a multimeter to the netBook to identify the pin functions. The remaining problem is that we haven't yet figured out how to properly configure PCMCIA interrupts.
A few people have taken a multimeter to the netBook's PCMCIA pins to extract information needed for kernel development. This information is...(a link?)
The problems with the X windows driver (the system responds with a blank screen and unresponsive keyboard), together with the bookboot problems, suggest that the framebuffer driver is not quite 100% all working. The framebuffer driver doesn't seem to be able to reset itself - perhaps the reason it works at all is that it inherits a certain amount of functionality from EPOC through the Arlo boot process. It would seem that the kernel framebuffer driver still has a few issues to resolve, in any case. Peter van S. comments regarding his 2.4.2 patch: "frame buffer: changed the sa1100 frame buffer driver to remap the video memory as setup by EPOC; it doesn't (yet) reprogram the LCD controller." However, in the 2.4.21 patch, video memory is _not_ remapped, and the LCD controller is programmed by the kernel (unlike Peter's 2.4.2 patch, which avoided touching any lcd settings) See netbook_series7_info in drivers/video/sa1100fb.c of linux-2.4.21-rmk2-kvd1.
IRDA does not seem to work on the netBook for any of the 2.4.2, 2.4.19, or 2.4.21 kernels. IRDA seems to be healthy and working insofar as the kernel is concerned, but I've not got any indication on my laptop that IR signals are being sent out. With the present kernel the /dev/ttySA1 (2.4.21) device, which might be expected to be associated with IRDA SIR, is never recognized - this can be fixed in "arch/arm/mach-sa1100/netbook_series7.c". (The 5MX recognizes the equivalent /dev/ttyAM0 and /dev/ttyAM1.) From the looks of the serial port and irda drivers, it looks as if development is needed to customize these a little bit for the Series 7/netBook hardware. Ordinarily, SIR would be set up with "irattach /dev/ttySA1 -s 1", and FIR with "irattach irda0 -s 1". Alternatively, "ifconfig irda0 up" followed by "echo 1 > /proc/sys/net/irda/discovery" is meant to start up FIR. Communication is then through /dev/ircomm0, e.g. by minicom or PPP. Linux's "irdadump" will show irda activity if it is present; irdadump seems to work fine on the netBook. SIR is a low-level generic driver for IRDA and the netBook's SA1100 is meant to support this - it is meant to be straight forward and hardly more complicated than the normal serial port...
It may be that IRDA requires additional configuration by installing it using modules and appropriate options. My own suspicion is that everything is working o.k., except the sa1100 irda routine lacks the small bits of code to just turn the irda on for the netBook. I also suspect that IRDA would work if it were first started in EPOC, and then linux was quickly booted. Linux would inherit the IRDA powered up.
From the documentation: The Infrared Communications Port (ICP) is serial port 2 with IRQ 16. Both SIR and FIR cannot be enabled at the same time. Hewlett-Packard Serial Infrared (SIR) modulation is used for low-speed transmission up to 115.2 Kbps. The HP-SIR enable (HSE) bit controls whether the HP-SIR bit modulation logic is enabled or disabled. When HSE=0, HP-SIR modulation is disabled, and if UART operation is enabled (ITR=0), it is used for normal serial transmission (NRZ encoding only) rather than IrDA communication. When HSE=1, HP-SIR modulation is enabled for low-speed IrDA communication; zeros are represented by pulses that are 3/16 of the programmed bit width, while ones are represented by no pulses.
The netBooks regular serial port is serial port 3 with IRQ 17.
The netBook is rumoured to support 4Mb/s FIR IRDA, but this has not been substantiated.
See http://www.hpl.hp.com/personal/Jean_Tourrilhes/IrDA/IrDA.html for as complete a description of IRDA and configuration as I have ever seen.
There seems to be some peculiarities with ramdisks. It seems as if mounting a second ramdisk causes memory problems, which is strange (e.g., mke2fs /dev/ram1 ; mount /dev/ram1 /mnt/disk"). Basically, the problem I've had is that copying large amounts of data to the ramdisk (e.g., the X windows system derived from the 5MX package) gradually fills up memory, and is perhaps not written to disk, leading eventually to a system freeze. The latest kernels behaved a little better, but were not trouble free.
One solution to this is to use ramfs or, better yet, tmpfs which seem to work better. However, for a ramfs filesystem, the newer kernels report nothing back using "df". There is meant to be a patch for this (to allow for accounting in a ramfs) in Alan C's package. Philosophically, ramfs is mean to be as simple as possible, apparently, hence the lack of accounting. So data can be stored and used on the ramfs disk, but no accounting of it is possible, other than a loss of memory shown with "free". For this reason the tmpfs is better, since it does keep accounting and "df" shows what's going on.
ramfs are mounted with "mount -t ramfs ramfs /mnt/disk", with no need to format the filesystem before doing this. ramfs are meant to expand in size as needed, so they are more flexible than ramdisks.
tmpfs are mounted with "mount -t tmpfs -o size=20M tmpfs /mnt/disk", with no need to format the filesystem before doing this. Like ramfs, tmpfs are meant to expand in size as needed, so they are more flexible than ramdisks. The "-o size=20M" option makes the disk size 20 MB, rather than the default ramdisk size. It may be that a default size of 4 MB could be used, omit the "-o size=20M" option for th tmpfs, and have the tmpfs grow as needed beyond 4 MB would work (but I've not tested this).
There presently does not exist any means to power off the netBook, set an automatic shutoff, or to lighten or darken the screen. I don't think anyone has yet worked on the power management issues. There is source code in the patch for the Series 5MX that may prove relevant to these issues, if not an easy port. There are also options for changing the frequency of the sa1100 - lower for power savings, higher for greater performance.
It appears as if we've managed to at least define keycodes for all the keys on the netBook, including the power switch and the external button at the front of the netBook. The key definitions we have are for the malaybook only, so there is a need to define keys for other versions (UK? DE?). The power keys and screen lighten/darken are not yet associated with those functions, however.
Arlo has a design limitation that prevents initrd.gz files of larger than 3.5-4 MB from being loaded. The initrd filesystem can be any size, so long as the compressed filesystem size plus kernel size is less than 4 MB. This is presently limiting the amount of data that can be placed on the initrd - the tools must be chosen carefully. Arlo is being redesigned and worked on to resolve the issue.
A list of requested Arlo developments:
- pass memory layout in kernel boot params (ATAG_MEM),
- possibly detect memory layout at runtime in boot2nd.
- pass boot parameter address also in r2 to the kernel,
compliant with Documentation/arm/Booting.
- Allow run-time adjustment of boot parameter address (e.g. in arlo.cfg)
- allow more than 4MB of total stuff to be passed to boot2nd
- save the "machine= Series 7" optionIn the kernel tree directory "devices/sound", there are a couple of sound routines for the sa1100: sa1100-audio.c, sa1100ssp.c. These look like they are ready to go for the netBook; they are presently set up for "lart" (another sa1100 system). I think the GPIO's that are used need merely be adjusted for the netBook, but I know nothing, really...
SanDisk have a CF card called "ConnectPlus" that combines 128MB CF and Wi-Fi. The 5MX people are proceding with development that may eventually be of use for the netBook. Output of dump_cis:
Socket 0:
dev_info
fn_specific 700ns, 2kb
mfc {
vers_1 7.0, "SanDisk", "ConnectPlus"
manfid 0xd601, 0x0101
funcid network_adapter
lan_technology wireless
lan_speed 34 mb/sec
lan_speed 35 mb/sec
config base 0x03e0 mask 0x0001 last_index 0x01
cftable_entry 0x01 [default]
Vcc Vnom 3300mV Vmin 3V Vmax 3600mV Iavg 300mA
Ipeak 300mA Idown 10mA
io 0x0000-0x007f [lines=7] [16bit]
irq mask 0xffff [level] [pulse] [shared]
}, {
common_jedec 0xdf 0x01
funcid fixed_disk [post]
disk_interface [ide]
disk_features [silicon] [unique] [single]
[sleep] [standby] [idle] [low power]
config base 0x0200 mask 0x000f last_index 0x07
cftable_entry 0x00 [default]
[rdybsy] [mwait] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
memory 0x0000-0x07ff @ 0x0000
cftable_entry 0x00
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x01 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x0000-0x000f [lines=4] [8bit] [16bit]
irq mask 0xffff [level] [pulse] [shared]
cftable_entry 0x01
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x02 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x01f0-0x01f7, 0x03f6-0x03f7 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
cftable_entry 0x02
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x03 [default]
[rdybsy] [pwrdown]
Vcc Vnom 5V Vmin 4500mV Vmax 5500mV Ipeak 80mA
io 0x0170-0x0177, 0x0376-0x0377 [lines=10] [8bit] [16bit] [range]
irq 14 [level] [pulse] [shared]
cftable_entry 0x03
Vcc Vnom 3300mV Ipeak 45mA
cftable_entry 0x07
}
Although compactflash is now working, a decent initrd on a 10-20 MB, say, RAM disk might still be useful. This, together with a reasonable kernel, will make for a minimally functional system, perhaps even with X windows. See, e.g., openpsion.
The development of a complete initrd is hampered by the Arlo design limiting (size of initrd.gz)+(size of kernel) < 4 MB. This means that things have to be transferred in to the RAM filesystem over the serial port after the minimal system is booted up. The X-windows system is about 17 MB in size, so this takes a while at 115kb/s, but is certainly doable. Transfer is faster using wireless networking, of course!