This page is under frequent revision until the a GPS NTP server is done.
A shorter step by step version will then be available.

Early 2007, a Linux NTP server was under discussion. Since not a Linux guy, I started research lightly. Until April, AMCC Tauhu eval board was selected as the target hardware. Many devices will be removed from the board since there is no need for PCI, USB, and maybe I2C.

"Warning! Warning! System Overload! Shut Down Imminent! Shut Down Immi...." Well, that is my feeling when searching on the net about Linux subjects. It keeps coming and coming. On other hand, I cannot find something to guide me through a complete path. (Probably I need to make my search skill better.)

Finally, I got my hand on a Taihu eval board. The resource CD led me to DENX Software Engineering. "ELDK 4.1 for Windows Released" caught my eyes. Downloaded the ISO_CD_image. Because Taihu is developed under ELDK 4.0, I navigated around DENX site and found ELDK 4.0 ftp page. Download ELDK 4.0 iso cd image. Tree, Rope, and Bench. Let the fun begin.

1. coLinux Installation (Follow README.txt on the CD)
   Burned the "ELDK 4.1 for Windows" image to CD. Installed the coLinux with instructions from the net (wrong place, README.txt on the CD.) Played around with colinux.xml and other configurations. Looked OK, but something not quite right. Uninstalled coLinux. It seemed good.
   
   Installed again. Got more familiar. Unistalled again. One thing was to install ELDK 4.0. For some reason, my CD cannot be mounted in coLinux. The workaround is to create a cofs device on my windows CD drive. Mount the drive (device) and install from there. Although there is warning about not to execute from cofs device, it seems OK for this. By the way, a cofs device is a windows folder that can be accessed by both coLinux and Windows. Other (co)Linux block devices are not accessible from Windows. They are just big binary files under Windows. Incidentally, those files may be fragmented. After defragmentation, they just stick together.
   
   Read the README.txt on the CD. It shows all the steps I have tried and more on patches. It worked much better. The default installation folder is C:\ Program Files\coLinux. However, I put it under C:\coLinux for two reasons, it was first installed under C:\ (according to net instruction) and it is easier to find C:\coLinux, since there are a long list under my Program Files folder.
   
   
2. coLinux Setup
   As a Windows guy, I would like to have files accessible from Windows. My plan is to use MSVC to develop source code and cross compile the code for AMCC PPC 405EP in coLinux. So I played with cofs device to get familiar it. One issue I experienced is that if the cofs's Windows folder is on physically different hard drive, vi will report error during save. This is minor for me. Simply use the c drive. Do other things, such as backup, from Windows.
   
   There is one cofs device in the colinux-ELDK.xml. I added more. At first, they are mounted manually. Then, they are mounted through /etc/fstab. Copy the file to Windows. Edit with Notepad to preserve Unix text file format. Copy back to linux. Halt and start coLinux. Eventually, vi the file. vi is friendlier than I remembered from 15+ years ago: arrow keys work. Along the way, frequently seached various Linux commands and found Linux/Unix commands page helpful. It contains samples of commands. Most other pages show syntax and options, but no samples. It was a little hard for me, a window guy, to grasp. In addition, it lists most commands. I bookmark the page and go there once in a while now.
   
   Add user. Well, it keeps failed to log in. It turns out the password is too short. I still do not know the minimum size, but just make a long one.
   
   It is time to get putty. Download, install, run, and connect (in coLinux, ifconfig shows the IP address to connect to.) Simple enough. Logout form putty, halt coLinux, and take a break. After the coffee, lunch, or whatever break, start coLinux, find the IP address, and start putty and login. Let's get lazy and save the putty session. Logout from putty, halt coLinux, save putty session, and take another break. Now do the sequence all over again. OOPS! The putty session IP address is off by 1. Did I save wrong? Save this new session. Halt, but no break this time. Start coLinux and check the IP address. Well, it advances by 1 again. Luckily, I can look into the router for the DHCP server. Several continuous IP addresses were less than current coLinux IP address, including those saved as putty sessions. Halt coLinux and start again. Another new IP address. Wow. The dynamic addresses will soon be used up by coLinux.
   
   Time for static IP. Hit the net again. Try this. Try that. Change here. Change that. Well, coLinux kept eating up IP addresses. Once, I did some damage and coLinux would not start. Uninstall and reinstall. Restore what have done. NO, I did not backup. I did over again. (Look the bright side. This helps me to reinforce what need to be done.) Now, it really calls for a break. A break it is. Then one thing hits me. During the search for the static IP setup, I found that mac address can be configured. I also noticed that coLinux generates different mac address each time it starts. So, mac is added in the following line in the colinux-ELDK.xml.
   <network index="0" type="bridged" name="Local Area Connection" mac="00:FF:B2:07:B8:00" />
   You can use the same mac address. Your DHCP server will assign a new address next time coLinux starts and will give same address from now on. Or you can find out the current mac address that coLinux generates and edit the xml file. The current IP address will be used. (There is chance that the address changes, usually the server is restarted or the IP is assigned to other computer when the coLinux has not been used for a while.)
   
   Add mac address to network parameters in the colinux configuration XML file, if you do not want new IP address each time.
   
   Here is a copy of my colinux-ELDK.xml. If you figure out how to use static IP, please kindly let me know.
   
   
3. Taihu Power-Up
   Follow the instruction from the resource CD. Only thing was that Board IP on the table of content pane is at bottom. I need to scrow to find it to update Taihu's IP address. Taihu is connected to our network. I would try to use the cross ethernet cable to connect the board to a laptop soon.
   
   Ran the bench test. Tried some demos. Not much incident. The longest confusion is finding the Board IP address field.
   
   
4. Hello, World
   Classical first program, Hello, World, is coming up. Edit the .bashrc to add the path and environment varaibles for ELDK. (See section 1.5 of README.html on ELDK 4.0. Of course, it is pcc_4xx for Taihu.)
   
   Create helloWorld.c. Compile it. FPT down to Taihu. The file is in /var/ftp directory. Make it executabe. Execute it. But get "-sh: helloWorld.o: not found". Double check with ls -l. It is there. Here is the worset situation for a program - nothing happens. Even the shell does not like it. It must be simple, fundamental. Well, you guest it, it is. Luckily, I ask for help from TaihuSupport at AMCC. It IS simple and fundamental - the current directory is not in the PATH. Linux only executes programs (binaries or scripts) in PATH unless the directory is specified. ./helloWorld.o says "Hello, World!". (That's why "./install -d ...", not simply "install ...") Under DOS, current directory is automatically in PATH. Maybe, long long time ago, the current directory was put into PATH in the startup script during my expience with Unix, long long time ago.
   
   
5. Rebuild Kernel
   As a software engineer for long time, making sure you have what is sent out is a normal. MFC includs timestamp.
   That causes me some hand waiving about the released sources and programs to my managers. Reccently I also found out that MFC can remove the stimestamp info. Anyway, rebuild the kernel.
   
   First I unzip the kernel under windows. It shows files overwritten. It is probably because windows do not support symbolic link as Linux. tar -xzf ... under coLinux has not message. This is not the point here. The point is there are so many files for so many architectures Linux supports. It makes me think of the day when I maintained 3 product lines of 5 or 6 models per line out of same source. It was a trap then. When you worked on one product or one model, you missed a #defines and others were broken or after you thought you were done, those modifications were on wrong product or model. Worse yet, to build all of them takes > 60 hours. Start a clean build on 5 PM Friday and check the completion on 9 AM Monday morning. That was how to maintain those products in check each week.
   
   How is the rebuild? They do not match in size. According to Taihu support, time stamp causes that. Let me deal with that later. At meantime, I remove other architectures and drivers without breaking the build. The sizes of the tarballs reduce about 40%. It could haunt me soon especially those drivers. Let's see.
   
   By the way, the README-linux.2.6.13 lists 3 more entries under the linux build root, Module.symvers, 
   PWD/, and WD/. It seems that Module.symvers is important when building kernel module. make modules creates the file.
   
   
6. LCD Display
   Embedded systems still express themselves. LCD and LEDs are the visual parts of a SBC, if they have them. Taihu has a LCD module controlled by LCM section. The first impression of LCD is they are slow. It is from the uC/OS-II project couple years ago. They do not buffer communications. CPU needs to wait between commands it sends to LCD.
   
   The LCD IO addresses are found in uBoot code since there is a message shown on LCD to indicate AMCC and Taihu. Study the code. Copy and paste the code. Compile, download, and run. "Segmentation error." Reasonable. Applications cannot access physical address, as PCC uses memory mapped IO. Time to ask! But this time, no luck. Taihu support responsed that they do not have smaple for LCD control and others I looked for. Hit the net (not I have not.) The Linux Documentation Project Guides page has many interested topics for Linux development. The particular one for LCD module is The Linux Kernel Module Programming Guides.
   
   There are two design decisions for this driver.
   1) Avoid "wait" within the driver. This is to avoid any delay to the reference clock handling. At least one of the article on the net mentioned that a module installation/removal affected time jittering. This is to remove any potential doubt about additional modules affecting the major goal of this project - time service.
   2) Single user space LCD interface. This is shifting the driver functionality from kernel space to user space to support the first decision.
   
   Here are code for the LCD module. They are not complete and will be changed any time. More user space side functionality will be added. Since the moduel is not integrated in kernel, manuallly insmod and mknod lcdMod.ko before run the lcd.e. The LCD device uses dynamically allocation for its major number. Application side will handle this later, within binary or through script.
   
   
7. NTP Package
   After I got feet wet, it is time to tackle NTP itself. During the surfing, a site described how to use GPS to make a NTP stratum 0 under Linux 2.6. It gave me a place to check out all the necessary "parts". The target GPS receiver is not as the one on the site. The protocol, NMEA, and 1 PPS feature, however, are same. One way or the others, NTP-4.2.4p0 is downloaded. It is the stable release at the time. Before my finishing of the project, later patch will be used.
   
   As usual, the doucument folder, html, contains a lot of information. After looping (not a typo of looking) around the html documents, try-and-error is always good, as long as it does not make any irrecoverable damage. Extract the files to under target linux root, for my case: /home/dev/linux-2.6.13/ntp-4.2.4p0, because somewhere it mentions that the make will look for target file from the parent directory of the NTP root. It is kind of support cross development. Later, you'll see it does.
   
   The steps to create NPT suit are simple: configure, make, and make install. Let's configure and make. It does not make. Copy the error message, paste and search the net. One solution is to make change in config.h.in. #define HAVE___ADJTIMEX in the file. configure --host=ppc --build=i686 --prefix=/home/dev/linux-2.6.13/ntp, make and make install. Download files in prefix directory to Taihu and test it. ntpd runs (ps command shows ntpd), but ntpq -p complains no libreadline.so.5. What's this? Without the ntpq, we do not know what ntpd status. Why one runs, but other does not? Then OOPS! This is not my ntpd. The command is wrong (forgot ./ again.) Well, Taihu comes with a version of NTP suit. Restart!
   
   After started, download NTP suit and ./ntpd. Guess what. "./ntpd: ./ntpd: 1: Syntax error: "(" unexpected" appears. ./ntpq -p and see " ./ntpq: ./ntpq: 1: Syntax error: word unexpected (expecting ")") ". Well, generic enough. Something fundamental. Any, let try the net. Nothing seems reasonal. Ask the support.
   
   While waiting for repot, I look here and there. Run nptd with debug info on. There are some failures. And config.log provides some information. The chances are make uses wrong compiler. After check into configure script, indeed, it has cross development in mind. The --host=pcc, however, is not recognized by the script. It is not what I like to see as well. The compiler should be soemthing like ppc_4xx-gcc. Modified config.sub script to add the ppc_4xx system. (sntp/config.sub needs same change; otherwise, when making sntp part of make chain, make fails.) The test is better now. ntpd complains about no librt.so.1 and ntpq -p, libreadline.so.5. At this time, Taihu support reply comes. Get a hint about how to solve the missing file. It is librt-2.3.5.so under ELDK 4.0 tree and both librt.so.1 and libreadline.so.5 are symbolic linked to it. It works better. Progress is good.
   
   Since config.sub needs change, there is no better time to start to understand script as now. After some reading, the better --host option is ppc-linux. make will use ppc-linux-gcc, which is same as ppc_4xx-gcc. It also uses ppc-linux to set other configurations. Going through some re-configure and re-make, librt.so.1 is not needed, but libreadline.so.5, and thus librt-2.3.5.so, is still needed by ntpq -p. Thing is going well.
   
   NTP runtime configuration file is better to put at default location, /etc/ntp.config. It is to help all other executables to find the same servers. At least one time, ntpq reports "No association ID's returned". Another thing hunting me is there are errors in the config.log. It will be dealt later.
   
   In summary, NTP package can be created for Taihu as:
   1. make clean
   2. configure --host=ppc-linux --build=i686 --prefix=/home/dev/ntp --disable-all-clocks --disable-parse-clocks
   3. make
   4. make install
   Sometime configure or make complains if not clean. Disabling clocks options are from the web site metioned earlier.
   
   Because PPS patch is to kernel, PPS patch and NMEA patch have to wait until I figure out how to build and download the kernel.
   
   
8. Flash Download and TFTP boot
   Taihu partitions the flash into 2 regions, boot region and application region, of 3 sections each. Sentions of boot region are Kozio kDiags, u-Boot Environment, and u-Boot. Sections of application region are kernel, ramdisk, and JFFS2 filesystem. JFFS2 is the filesystem to save persistent data between boots (start-ups). For my application, it should be enough. Kozio should be let along as this moment. u-Boot Environment could be set when u-Boot is up. The only concern is to have u-Boot console up and running. On the other hand, the only change in u-Boot may be the LCD message. Risk could be low. Any way, let's work on the main objective first.
   
   image/README.flashupdate shows how to update flash. Taihu runs without obvious problem after kernel image from the CD is download. ui/tftpboot.html provides an alternative to test kernal and ramdisk through TFTP. It is always better to test before update.
   
   A free TFTP server of solarwind.net is used on the host PC. Use File->Configure to configure the server. My configureation simply uses the default root directory, C:\TFTP-Root, and allows transmit only. Copy kernel and ramdisk images to the root. The TFTP server on host is ready.
   
   Get on to the step 2. For server IP address, the SolarWinds.net TFTP tells you the IP address. The Taihu's IP address is up to you. Since Taihu has been running for a while, it should not be difficult to find an address. The step 3 is simple. However, the step 4 dose not work. TFTP downloads are OK. But 'bootm 0x10000 0x1000000' do not work. It will restart and use images on the flash. There are what from Taihu Support:
   tftp 0x400000 kernel.img
   tftp 0x1000000 ramdisk.img
   run setboot
   bootm 0x400000 0x1000000
   Note: The addresses are different. One more command, run setboot, is added before bootm.
   
   
9. Ramdisk Image
   Revisit software/linux/kernel/README.linus-2.6.13 to see to create kernel. "ramdisk.image.gz" expected? It is not in the boot/images/. Need to make one! Well, software/linux/rootfs/README.filesystem has instructions and even sample output. Simple.
   
   Not quite. The ramdisk size is 70000k vs the 48000k in the readme file. Bigger is better. Not an issue. "mount: could not find any device /dev/loop#" is different story. From the net, it says loopback device is not supported. If so, it would be serious. How to include the support? It is the whole purpose to use coLinux to have all features needed to cross develop Taihu. It would be bad to add the support. Asking for help from both DENX and Taihu Support. After a weekend, no reply. Try "mknod /dev/loop1 b 7 1" (saw from net). Does not work. /dev/MAKEDEV looks interesting. man -a MAKEDEV (MAKEDEV(8)). Loop device is listed along with hard drive, floppy drive, and other devices. Restart coLinux to get rid of those mknod loop devices. MAKEDEV loop creates 256, loop0 to loop255, loopback devices. WOW, too many. Restart coLinux. They are automatically installed. No chance to use MAKEDEV -m 16 loop to reduce the number or check wether it works.
   
   The outputs of ./make_rootfs.sh are reasonable. The result is in this file.
   
   Time to move LCD module and NTP executables to ramdisk. Copy librt-2.3.5.so to /opt/filesystem/static/lib; create a symbolic link of libreadline.so.5 to the file. Copy NTP executables to /opt/filesystem/static/usr/sbin. Create ntp.conf in /opt/filesystem/static/etc/. Remake the ramdisk.img. Copy the image to TFTP root. Boot through TFPT. Run ntpdW and ntpqW -p. It works.
   
   
10. Kernel Image
    With a version of ramdisk.image.gz in ppc/boot/images/, it is ready to create kernel image. PPS patch can be applied. NMEA patch is also in line.
    
    What do you know! Patch command is not found. Whenever you think it is obvious, it is not. "sudo aptitude install patch" gives aptitude not found. apt-get gives not found. What is there? yum is there. (sudo) yum install patch (under root) finally works. It searchs the net, downloads about 65k, and installs patch. Since apt-get is mentioned many places (more than yum to me), let me install it, but (sudo) yum install apt-get does not work. Just to remeber to use yum instead of apt-get. What's next? None, hopefully?
    
    Patch in both ntp-pps-2.6.13.diff (for kernel) and ntpd-nmea.patch (for ntp package). ntp-pps-2.6.13.diff is copied under /home/dev/linux-2.6.13/ and patch -p1 <ntp-pps-2.6.13.diff. ntpd-nmea.patch under and patch -p1 <ntpd-nmea.patch.
    
    Run 'make taihu_defconfig'. Here is where I pay for directories removed earlier during rebuild kernel. Many directories are required in drivers/ and net/, although some of them still do not make sense for me. Copy all them back to satisfy the make.
    
    Run 'make menuconfig', but change nothing. The .config shows that 1PPS is not defined:
    # CONFIG_SERIAL_PPS is not set
    # CONFIG_SERIAL_PPSTEST is not set
    After couple hours of looking around, first time I look into Kconfig (of drivers/serial.) SERIAL_PPS is there, but why is it not set? Then, finally know what 'make menuconfig' does. Navigate (with down arrow key, Device Drivers --> Character devices --> Serial drivers, set LinuxPPS on) in the menu and select both of the options. Now .config has CONFIG_SERIAL_PPS=y. (If you enable CONFIG_SERIAL_PPSTEST, "linuxpps: ktimer: PPS event at xxxx" message will pump out ever second. It is for PPS debug.)
    
    
11. NMEA & 1PPS NTP
    Although this module is actually built before 1PPS kernel, it is OK to describe it late here. My current GPS receiver does not use NMEA sentences. It is an Odestic board with GPS engineer (ironically, it uses NMEA.) However, since NMEA is the target and the receiver sends a format of $UTCT,hhmmss,dd,MM,YYYY,S,T<cr><lf>. It can be handled in NMEA code. One other diffference is that the receiver supports 9600 vs 4800 baud. The server mode in the ntp.conf seems is good way to patch in my receiver. The next available mode is 8 (bit 3.) In order to anticipate new NMEA module will have 9600 baud, the mode 8 is also used to select 9600 baud. For the 9600 baud standard NMEA receiver, the mode will be 9 (1 - $GPRMC which NTP package perfer + 8 - 9600 baud.)
    
    An extra sentence, $UNSL,UTCT,1* (without cr/lf), needs to be sent to enable unsolicited UTCT message from the receiver. It is done in nmea_start() when mode & 8 is not 0. Here is my refclock_nmea.c.
    
    Copy timepps.h from linux-2.6.13/include/linux to /opt/eldk/ppc_4xx/usr/include to define HAVE_PPSAPI. (At first, I thought this is a patch, but http://time.qnan.org mentions this should be done for cross development.) Still have "refclock_nmea: time_pps_create failed: Invalid argument" in system log (/tmp/messages) which means no PPS yet.
    
12. NTP Rebuild
    After let the NTP run a while, "ntpdc -c kern" reports estimated error around 15 ms. But the error from http://time.qnan.org is expected to be 8 us (0.0000008 second). The error is too much. By the way, " ln -s ttyS1 gps1" under /dev is used to create /dev/gps1 for my system. (Later, find out that it needs to be "ln -s /dev/ttyS1 gps1". Otherwise, the device found will be ttyS1 not /dev/ttyS1. That cause nmea code to quit.)
    
    After expanding inline function time_pps_create(), where the error is reported, and functions in it, I realize that the PPS patch (ntp-pps-2.6.13.diff) does not match with the ntp-nmea.patch. Although the .diff is against the linux version Taihu uses, the 2.6.13.diff does not have PPS_HAVE_FINDPATH. The fd passed to time_pps_create() is wrong. time_pps_create() expects a fd returned from time_pps_findpath(). Done it once, can do it again. From the README in pps patches page, it turns out ntp-pps-2.6.13.diff is version 1.0.0. Let me take a leap to ntp-pps-2.6.22-rc6-new_API.diff. (Why? Well, it is one of the latest and it does not matter soon.) Patch in the kernel. WOW! Rejects! Check into the reject files. Line numbers are off quite a bit. Mutex is used. Linux 2.6.13 uses semaphore to "simuate" mutex. Later version (at least 2.6.17) has mutex. It is not a time to find out yet which version and the implementation. Try to manually patch PPS related codes. It does not work too well.
    
    Earlier version could be more suitable. Check diff for 2.6.15, no PPS_HAVE_FINDPATH. Diff for 2.6.17 has it. So it is. Patch into kernel without PPS package. Two rejects. netlink.h is simple - a new net links value, in addition to PPS one, was added between 2.6.13 and 2.6.17. Just added the new one and also PPS one. 8250.c has a small issue. One of the reject does not make sense. The other reject is due to mutex, but it is simply replacement of mutex with "simulated" mutex. Manually patch both sections (hunk?).
    
    Configure the kernel to enable PPS. Since it is a strip down version of 2.6.13, some directories are to be put back. The configuration screen is different. PPS is not under Serial drivers. It moves 2 levels up and is directly under Device Drivers: Device Drivers ---> PPS support. First all featuers are selected. Later, Kernel timer client (... for debug) is de-selected to removed message/second on console.
    
    Extract ntp-4.2.4p0 and install nmea patch. Copy ppstime.h to eldk include path. Configure ntp with script file: configure --host=ppc-linux --build=i686 --prefix=/home/dev/ntp --disable-all-clocks --disable-parse-clocks --enable-NMEA --enable-LOCAL-CLOCK --enable-linuxcaps --program-suffix=W
    
    Update the new refclock_nmea.c with my changes. Make and make install. Create a ram disk image with the ntp programs. Download new kernel image and ram disk image through tftp. Create /dev/gps1. Run ntpdW. But ntpqW -p shows "No association ID's returned". The demon is not running. How come? Check the system log. It did not find ttyS1. Does it have to be /dev/ttyS1? Remove the gps1 and relink it to /dev/ttyS1, instead of ttyS1 when ln is executed under /dev/. Now it goes.
    
    After hours, check with ntpqW. The offset and jitter still not stable: offset 11 to 3 ms and jitter 8 to 2.5 ms. Check with ntpdcW -c kern . The estimated error starts from 15 ms and gradually becomes 4 or 5 ms. It is not good and probably still not quite right somewhere. I may just leave as is for the week.
    
    
13. EBC Interrupt
    From /tmp/messages, it 8250 and PPS drivers report that the intervals of GPS 1 PPS are oscillating between 1008 and 992 ms. While "looking around", there is a 8 ms issue related to serial chip. No quite understand the issue. Anyway, it is my road map to go to EBC interrupt handling. Let me use the 1 PPS as interrupt source. It should be relative clean source comparing with mechanical switch or touching.
    
    Find the interrupt pin at pin 36. From board manual, it is either IRQ 5 or IRQ4. It would be more helpful if the document is more consistent. The interrupt routine is based on the The Linux Kernel Module Programming Guides. Build OK. Download to target, but target says __create_workqueue() and queue_work() undefined. No problem in build. So they must be in OS symbols. Switch gear. Use the sample from Linux Device Drivers, 2nd Edition. No complains. Unfortunately, both IRQs do not generate interrupt. Ask the good old Taihu support. While waiting their response, it turns out that __create_workqueue() and queue_work() along with couple other functions use EXPORT_SYMBOL_GPL(). My module license was set to Proprietory. They work after the licence is GPL. (LCD module is also modified while waiting.)
    
    The response from Taihu Support is very helpful. The IRQ number should be 30 as defined by UIC in table 10-1 of processor user manual. They also are ahead of me to let me know where to change the interrupt polarity and trigger. Here are the changes in ppc/platform/4xx/ibm405ep.c :
    - .ext_irq_mask = 0x0000007d - If the mask is 1, the IRQ will always use 0 for both polarity and triggering (See ppc/syslib/ppc4xx_pic.c.)
    - .polarity = 0xffff7f82 - to make IRQ5 (UIC 30) polarity high
    - .triggering = 0x00000002 - to make IRQ5 (UIC 30) edge trigger
    During the test of polarity, it turns out the pin 36 is pulled high. That means if it is open, it is high. When I tested with polarity high and level trigger, the system looks hang. It is not hang. It just keeps serving EBC interrupt. When connect the EBC pin 36 to ground (low), the system reacts normal.
    
    The intervals of interrupts driven by the 1 PPS from GPS receiver are 1000 ms. The 8 ms issue is related to serial chip. Now a reasonable interrupt can be used to feed 1 PPS to NTP. Here is the EBC interrupt handler.
    
    
14. NTP Rerun
    The approach I select is to "cheat" 1 PPS from EBC to NTP as from 8250. The first step is to generate PPS assert events within EBC interrupt handler and remove the assert from 8250.c. However, 8250.c still generates PPS clean events. NTPd also uses the clear events. So step 2 is to generate PPS clear events from the bottom (2nd) part of the EBC interrupt sequence and remove the clear events from 8250.c.
    
    After the changes of 8250.c and ibm405ep.c, rerun ntpd with ebcintr.ko "insmod"ed. The estimated error from ntpdc is 15 us. It is 1000 times improvement from the first ntpd run (without PPS.) Although it is not as good as expected 8 us, it is within the scale. Maybe finding nanokernel is next.
    
    
15. LCD Update
    A new update for the LCD driver and applicaitons: LCD Module. This module will work for me later in the project.
    
    
16. LCD "logo"
    The initial, booting LCD message is in u-boot code under board/amcc/taihu/lcd.c. It is changed to remove the AMCC Tauhu message. Make a new boot code:
    make distclean
    make taihu_config
    make
    
    Follow the instruction in images/README.flashupdate. Next step is to auto log on and run "start-up" script.