Board:bcom/winnet100

The BCOM WinNET100 mainboard was sold by IGEL some years ago as their product IGEL-316. Their product was a Linux based terminal to work remotely with Windows and X.

Status

Device/functionality	Status	Comments
CPU	Works	—
RAM	Works	—
IDE	Works	Tested with 2.5" disk.
IDE using CF-to-IDE adapter	Untested	—
SATA	N/A	—
USB	Works	Tested with irqpoll kernel parameter. Tested: USB thumb drive.
On-board ethernet	Works	Tested with irqpoll kernel parameter.
On-board audio	Untested	—
On-board VGA	Works	VGA support in LinuxBIOS works fine (e.g. for displaying a boot logo), for console/X11 you need a special kernel console and Xorg driver.
PCI add-on cards	N/A	—
PCI Express add-on cards	N/A	—
Floppy	N/A	No connector provided.
Serial port (COM1)	Works	—
Serial port (COM2)	Untested	Simple UART mode only (due to TTL level, used by the SmartCard Reader).
Parallel port	Untested	Running 'modprobe ppdev' works fine, but further tests were not done, yet.
PS/2 keyboard	Works	—
PS/2 mouse	Works	—
Smartcard reader	Untested	Probably won't work in Linux as there are no public datasheets [1].
Mainboard sensors/fans	N/A	This CPU does not need a fan.
CPU frequency scaling / powersave modes	Works	Frequency Scaling on this CPU is useless. Stop clock on HLT saves more power (enabled by Linux as default).
Flashrom	Works	Works fine, both with LinuxBIOS and with the proprietary BIOS.

Hardware

File:Igel winnet100 1.png The IGEL-316 (WinNET 100) thin client.	The backpanel.
The mainboard.

• GX1-300B-85-20 Cyrix/National/AMD CPU with 300MHz core clock
• CS5530A-UCE part of the chipset, Cyrix/National/AMD companion device
• PC97317 Super I/O
• RTL8139C Realtec network controller
• 39F020A PLCC32 256kiB flash memory to boot
• LM4546 National, AC97 AD/DA
• DOC2000 DIL32 16MiB DiskOnChip
• SDRAM 32MiB SDRAM with 133MHz/CL2 capability as SO-DIMM

Connectors

External:

• 1x PS/2 keyboard
• 1x PS/2 mouse
• 1x serial port (COM1)
• 1x parallel port
• 2x USB (OHCI)
• 1x DSUB15 VGA analogue
• 1x RJ45
• Audio: Line-in, line-out, Mic

Internal:

• 1x 44pin 2mm 2.5" harddisk connector
• 1x serial port (COM2), but TTL levels only (used for the card reader)

Detailed System Information

Block diagram

The following information was gathered on a running Linux 2.6.21 system, booted via LinuxBIOS:

lspci -tv

-[0000:00]-+-00.0  Cyrix Corporation PCI Master
           +-0f.0  Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+
           +-12.0  Cyrix Corporation 5530 Legacy [Kahlua]
           +-12.1  Cyrix Corporation 5530 SMI [Kahlua]
           +-12.2  Cyrix Corporation 5530 IDE [Kahlua]
           +-12.3  Cyrix Corporation 5530 Audio [Kahlua]
           +-12.4  Cyrix Corporation 5530 Video [Kahlua]
           \-13.0  Compaq Computer Corporation ZFMicro Chipset USB

/proc/cpuinfo

processor       : 0
vendor_id       : Geode by NSC
cpu family      : 5
model           : 9
model name      : Geode(TM) Integrated Processor by National Semi
stepping        : 2
cpu MHz         : 300.691
cache size      : 16 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu tsc msr cx8 cmov mmx cxmmx
bogomips        : 602.14
clflush size    : 32

/proc/iomem

00000000-000006d3 : reserved
000006d4-0009ffff : System RAM
000a0000-000bffff : Video RAM area
000f0000-000fffff : System ROM
00100000-01bfffff : System RAM
  00100000-00253ad9 : Kernel code
  00253ada-002a5f2b : Kernel data
40000000-40000fff : scratch_pad_ram
  40000000-40000fff : Geode GX1 Framebuffer
40008000-400080ff : bus_interface
  40008000-400080ff : Geode GX1 Bus Interface
40008100-400082ff : video_pipeline
  40008100-400082ff : Geode GX1 Framebuffer
40008300-400083ff : display_control
  40008300-400083ff : Geode GX1 Framebuffer
40008400-400084ff : memory_control
  40008400-400084ff : Geode GX1 Memory Control
40008500-40008fff : power_control.0
40400000-407fffff : smm_area.0
40800000-487fffff : video_memory
  40800000-487fffff : Geode GX1 Framebuffer
febfb000-febfbfff : 0000:00:12.4
  febfb000-febfbfff : Geode GX1 Framebuffer
febfc000-febfcfff : 0000:00:13.0
  febfc000-febfcfff : ohci_hcd
febfd000-febfd0ff : 0000:00:0f.0
  febfd000-febfd0ff : 8139too
febfe000-febfe0ff : 0000:00:12.1
  febfe000-febfe0ff : CS5530a (Kahlua) SMI handler
febff000-febff07f : 0000:00:12.3
fffc0000-ffffffff : flash_memory.0

Building a LinuxBIOS image

$ cd targets
$ ./buildtarget bcom/winnet100
$ cd bcom/winnet100/winnet100
$ LANG=C make

The LANG=C is only for those users (like me) that uses a localised system. Determining some include pathes fails in LB's build system, if the GCC answers in German...

Using the hardware with a current kernel

The current 2.6.22/23 kernel does not know the CS5530 interrupt router. So it is impossible to let the kernel itself setup PCI's interrupt routing. Even if you provide the kernel with a valid interrupt routing table (PIRQ). No interrupts will work as the interrupt routing registers are still left at their reset values. The small patch below solves this issue (it was rejected in mainline as it breaks various standard BIOS based Geode systems, as they were shipped with broken PIRQ tables [2]).

Since kernel 2.6.23 Geode chipset access macros are now working as expected. Due to this, some chipset tweaks embedded in the kernel are working now. One of these tweaks setup the performance incrementor for a 233MHz CPU. This may fail on a 300MHz CPU now (additionally it depends on the SDRAM speed). The symptom of this failure is a freezing system after running a while (after warm up). Take a look into arch/i386/kernel/cpu/cyrix.c, function set_cx86_inc(). Correct the setting to:

setCx86(CX86_PCR0, getCx86(CX86_PCR0) | 0x05);

when you run a 300MHz CPU.

How to bring LinuxBIOS in

I was not successful to boot anything other than the software in the DoC to get some information about this board. It seems a very special BIOS as it only outputs "booting os" and nothing else. Then the splash screen comes up and the graphical environment starts. One or two times I was successful to run an update of this firmware. Because the update process fails (the server it tries to connect to doesn't answer anymore), the console comes up. That's why I know they run a 2.4 kernel with an XFree86 3.x. Their software needs about one and a half minute to boot up and supports graphical resolutions up to XGA@64k colours and SXGA@256 colours.

With my own implementation (LinuxBIOSv2, Linux 2.6.2x kernel, Xorg 7.2) I boot this machine in about 10 seconds, then the xdm dialogue occures (its a terminal, not a workstation) and supports also SXGA@64k colours.

As is it hard to get a console on this system with the original software, I found no way to reprogram the boot flash in a running system. But it is very easy to disassemble the flash memory. Only 3 screws to unscrew at the reverse.

Pull the front panel to one side, the casing to the other. Ready. You now have access to all relevant parts.

To disassemble the PLCC32 boot flash ROM you need something with a hook. I'm using my SMD tweezer. Did I mention that you will need something to burn your flash?

How to build a root filesystem

This question is easy to answer. Download the following archives:

• Board Support Package (BSP)
• Build System
• Patch package
• Generic projects package
• Toolchain package

Start with the BSP, extract it and read the quickstart in Documentation/GeoTerm-Quickstart.pdf. It will guide you through the steps that are required to:

• get a generic project build system,
• get a cross toolchain for the Geode GX1,
• configure the BSP and build it,
• bring this target up and running with LinusBIOS and GNU/Linux.

The BSP builds all parts to run this Geode GX1 system. This includes LinuxBIOS and the kernel and also userland with X to run as a terminal (not as host!).

Note: This BSP includes all required patches for the kernel. You won't need the patches below.

Required patches

When you build your own kernel for this target you might need the following patches:

• This patch is needed to let Linux know the Cyrix 5530 interrupt router.
• This patch is needed as someone has overoptimised chipset tweaks so the used access macros failed. This patch is required only for kernels up to 2.6.22. From Linux 2.6.23 on it's part of mainline.