The last part that wasn’t finished was the SPI controller and the SPI flash driver, so this weekend I spent some time to finish it. So now, I can say that the port is finished, all drivers have been written for the device. With SPI flash support, I can now write the kernel to the device, and boot it from there (I don’t need to boot from network anymore).

Actually I am not really finished yet, since I still need to reformat the code according to the FreeBSD standard, and there might still be bugs in my code, so I invite everyone that have this device to try it out. There is also a feature in the network driver that is not implemented yet (multicast filtering), because the datasheet is not very clear (i would be very happy if someone could help me to complete this, wait now i suddenly understands the documentation).

For the boot loader, I am still using the default boot loader. This boot loader will load the kernel from memory 0×600000, and since I can’t change the boot loader configuration in this particular device, I modified the kernel configuration to match this. The latest code can be accessed at http://gitorious.org/freebsd-arm.

To do initial boot, you will need serial port. You will need to put your kernel on your tftp server. Hit any key during boot, and type:

setenv serverip 172.17.1.1
setenv ipaddr 172.17.1.2
tftpboot 0x600000 kernel.bin
go 0x600000

and to make it permanent:

dd if=kernel.gz.tramp.bin of=/dev/flash/spi0 obs=4k conv=osync seek=96

Please note that the blocksize is 4k, and 96 means the offset is 0×60000 (96*4096) which will be mapped to 0×600000 by the boot loader. If you are brave, you can just compile the image and dd using the default Linux, but I don’t recommend this, since you may have different hardware (espcially SPI flash chip).

Another news: I have completed the driver for ThinLinx Hot-e NAND using NAND2 framework. I also completed the SPI part and support for the flash SPI (read only).

I know that there are several Unicode layout library, such as Pango, Qt or ICU. All of them are too big for me to understand and port to Symbian. So my solution was to use the freetype library and harfbuzz font shaping. After using those two libraries on Symbian, I think now I can understand Unicode. Here is my quick guide to understand Unicode, from having a data and a font, to displaying the data with that font.

First thing that you need to understand is: Unicode defines list of characters for many languages of the world.

Some languages doesn’t have the concept of lower or upper case. Some languages have their own numbering system. Every language has their own system of ordering things. If possible: always use the function provided by the library you are using. 

Second to note is there are over 100 thousand characters defined in the Unicode. We need to store this efficiently.

Ideally to represent the data in memory, you will use 4 bytes representation because 1 or 2 bytes will not be enough to hold all the 100 thousands characters. Practically most people will not use the whole 100 thousands characters on a document or in an application, and storing everything in 4 bytes will waste a lot space. To solve that (and to add another problem), different Unicode encodings are created. There are several encodings 7-bit (UTF7), 8-bit (UTF8), and 16-bit Little Endian/Small Endian encodings.

Encoding Unicode character using less than 32 bit works by using escape characters inside the string. For example if we use 16 bit encoding, we can only store 65536 values, if the character number to be stored is less than some number (say 60000), then just store the number, else write an escape code that says "for the next character, add 60000 to it), and write "the number minus 60000". Actually this is a simplification, because the numbering is actually not linear (it is divided into block numbers/planes).

Third thing to understand is: Unicode encoding creates a new problem.

As you can see from the previous explanation: if we have a string 4 x 16 bits, the length of the character may not be 4, it could be 2, 3, or 4, it depends on the data. You will need to use special functions to do string manipulation such as accessing character number x,  or finding the length of a string. Different operating system uses different encoding for Unicode, so you need to know what encoding you are using.

Another thing to remember is conversion of old encoding system to Unicode or the other way around. Before Unicode, many countries/languages have their own encoding, character number 65 may not always be an "A" in some language. You may need a library to do this kind of conversion.

Fourth thing to understand is: Unicode string is only a list of characters in logical order.

You can’t just paint each character and hope that the result will be fine. If you have character "A" as the first character, and a COMBINING GRAVE character as the second character, on display you will only see one "character" (actually it is one grapheme). You also need to note that several algorithms should understand this logical ordering, for example, when you try to reverse a string, some character combinations must be kept intact.

Fifth thing to understand is: a font contains list of glyphs representing  characters.

Currently a font will never have all the possible glyphs of Unicode characters. Having a font library will enable us to load glyphs from font, and look up whether the font contains the glyphs that we need to display the character. Some fonts also contains predefined shapes for character combinations. Usually the font library will not be able to tell us that a glyph represents a combination of other glyphs.

Sixth thing to understand is: you need font shaping library to draw Unicode strings nicely.

Font shaper such as harfbuzz will try to parse a string into syllable, and will try to find the best representation of the syllable, either by looking up the correct glyphs that already combines several characters or by joining several glyphs in correct position.

Editing Unicode text is more difficult, and I still don’t understand well enough about it (my program doesn’t need that for now).

PS: the Malayalam version of Symbian bible is not released yet. I was just happy that I can display the characters correctly (as the reference PDF), so I want to write this.

Fixing it quite easy, I used a tape to make the space key thicker and easier to press, and I put a tape also in the keyboard to keep the rubber part from moving.

You can see more pictures on my photo gallery.

1. Basic architectural support (IRQ, timer, memory mapping)
2. Serial port
3. EHCI driver
4. OHCI driver
5. MTD driver

Here are some notes regarding the development:

1. Serial port is 16550 compliant, but you need to remap the registers.
2. STR9104 have PCI bus, but it is not connected anywhere. The old kernel have a driver for PCI bus, and it was used in the EHCI driver. I think this is kind of a hack, because the PCI stuff is not needed.
3. The EHCI and OHCI is part of the SoC, not on the PCI bus. There is a quirk in the initialization of the OHCI part (you can look at it in the patch)
4. MTD driver is based on CFI chipset (AMD/Fujitsu). I only tested reading and writing configuration partition (mtd2 and mtdblock2)
5. Network Driver (STR9104 contains MAC hardware, and in Agestar it is connected to IP101A as the PHY hardware)

I have not uploaded a new patch for the MTD yet (I will do it tonight). For the RTC and Button part, I think it will not be so easy:

1. The RTC in the old kernel uses I2C bus, and X1205 driver. The X1205 already have a driver in the kernel tree, but there is no driver for the I2C part in the source code from Linksys devices. In the STR9104 product page, it is mentioned that the SoC already have an RTC device inside it, so it is possible that this RTC might not require I2C at all. I need to do some experiments.
2. The button driver source code is not given, but I think I can reverse engineer this.

Kineq from the mailing list have warned me about something that is not right in the user space. When he tried to build uClibc, he got "invalid instruction" when running some applications (he was still using the old kernel at that time). With the new kernel, I also got the same thing, some applications (such samba) failed to start (segmentation fault), some works, but will halt in the middle (for example curl will get invalid instruction). The original agestar NCB3AST firmware uses libc 2.3, and not uClibc, so may be one of these things are not correct:

1. The uClibc (there were quite many bugs in uClibc)
2. The compiler (may be I am giving the wrong flags)
3. The processor (Faraday claims 100% arm compatibility, but may be it is not that compatible)
4. The kernel (I doubt it, since it also happens in the old kernel)

Note: Problem was solved. FA526 doesn’t support Thumb, and I tried to compile things using EABI, which requires thumb interworking.