any changes ? nope

It's been a while since I wrote on this blog. I started experimenting with NGW100 1,5 year ago. Meanwhile I did a lot of other targets as you can read on my blogs. But I wanted to retake a brand new buildroot with an updated kernel and give it shot. I can use the NGW in my project to serve as a TCP/IP to I2C converter so it was worth to try. But I knew that it's hell working with linux buildroots. I had hoped tough it had changed a bit in the good direction.

So I downloaded the buildroot from the atmel site 2.3.0 RC1 with kernel 2.6.27. I did my tests a year ago with kernel 2.6.23. I noticed very quickly that nothing has changed. The same old problems appeared like missing packages and broken compilings. As a test I said to my self let me try with a buildroot for ARM9 and see if this gives any differences. Also that one was real shit to compile.

My conclusion is that the open source on itself is quit a good philosophy but the compile and build environments really suck. Dependencies all over the place and if you don't have one right you lose. As long as people out there are not changing that complex process I'm not intended to go any further with it. There is need to standardize this process so it could run on any linux distribution. Also the interface of making the BSP and kernels must be greatly enhanced anbd simplified. At this moment there are far too many different distributions which makes it only worse.

So people who love to play with embedded systems stuck with some good old C and maybe a good RTOS to run with. But stay a way from the ugly linux buildroots.

I guess I have to found some other system to do that job ;-)

temporarly or definitly stopping

As you could read in my previous topic I started with analysing the FTDI chip. Furthermore I said that this should be treated in a dedicated blog title. And guess what it's up online now !

http://ftdi-guyvo.blogspot.com

I'm very disappointed that atmel engineering doesn't handle my issues with some higher priority. I also didn't receive any answers or status up till now. So I consider this as some "nice to have" kind a thing in the eyes of Atmel. The good thing is that I learned quit some new stuff doing this project. It enlarged my global knowledge on embedded linux development with some huge quantities. Maybe I will retake this project maybe not, depending on the reply of Atmel obviously. Also the results on the FTDI solution will have an impact on the question if I'll retake or not. Only the near future can bring clearness in this matter. So for now you'd better follow my FTDI blog if you interested in the progress of this project.

Hopefully waiting on Atmel ...

not that good

Been a while now since I wrote something here. Meanwhile I upgraded the SDRAM from 32M to 64M in the hope some programs would give better results. The upgrade was successful after also flashing a new Uboot. I started to test my programs on the 64M.

First the mplayer with playing a song an AAC format. The problem of stopping in the middle of the song wasn't resolved. The strange thing is that when lancing the mplayer using the strace utility the song is playing til the end. Postting a couple of threads on avrfeaks didn't bring a solution.

The second was playing around with my lighttpd webserver running on the NGW. Again the problems I had with my normal website pages remained. The webserver starts to transfer but half way it hangs. Even with no large files here. Also the problem of large files was not resolved with having more ram memory.

It's pitty because my proof of concept was ready to go. But I definitly need the other programs to work correctly to build a nice modern system. In my opinion the linux port for AVR32 has a great lack on matureness. Especially on the low level architecture depend layers like the SD card driver and the TCP/IP communication. I already posted mail to atmel engineering to look in some issues I discovered when testing these layers. This was his final answer:

"... As you say, this is not the sort of usage embedded systems are typically designed for. I agree, of course, that this should be improved, and appreciate that the issue is brought to our awareness. However, it might delay some time before this is given priority... "

Personally I think that the linux port for ARM targets is far more evolved than for the AVR32. AVR32 still misses a bit on popularity and is also rather new comparing to the ARM7/9.
Maybe some day this will change as the AVR32 starts to find his way in hand-held devices.

Conclusion:

I take a break working on this target now. As I saw some possibilities with the FTDI chips. The latest types are very powerful. They even can communicate directly with I2C buses. So I ordered a development kit based on this technology of the FT2232D type. The intention is combining this chip directly with a PC platform. But as I considered this out of topic of this blog I will start a brand new one and keep you posted over there. Maybe I will retake the AVR32 some day when I have some news of the Atmel engineering.

first brainstorming towards the final project

I did a first overall analysing on my white board with all necessary blocks present. This can be seen on the picture left. I will post more and more of those things like drawings and schemes in the near future as my project continues. This becomes possible now because almost all separate functional blocks are ready to be integrate in the final project. I'm also thinking on posting source examples of basic principles I used. I don't know yet how and in what format. Probably I will go for my google pages. I will check out how non proportional fonts look like when rendering on google pages.

Yesterday I tested the linux file/dir notifications 'inotify'. Great results on directory as well as individual file level. again a functionality that is ready to be used. The only block still to look at is the message queues but I'm confident in that because it's a default linux mechanism for inter process communication. I learned this out of one of my books presented in an earlier blog. So still a lot of new things to explore but I learned quit a lot in this passed 6 mounts I must say. The other half of the year will be more dedicated on building my project based on the knowledge I already gathered until now. But there'll always be some time to explore in the side line.

So don't hesitate to rss feed my blog if you want to follow my project. And feel free to write some comments and/or questions on the blogs.

tests continued

Nice results in testing the GPIO as interrupt source coming from the input PCA ! I assembled the low level stuff in a DLL (SO) file and called from a test program. So the only thing I do is pushing/releasing a button connected with the first IO on the board.Below you can see some stdout printf which gives an idea :

0x00400000
negative edge I/O change detected
read --> 0x01 : 0x00 : 0x00 : 0x00 : 0x00

omit reset:
0x00600000 -> reset int
read --> 0x01 : 0x00 : 0x00 : 0x00 : 0x00

release:
0x00400000
negative edge I/O change detected
read --> 0x00 : 0x00 : 0x00 : 0x00 : 0x00

omit reset:
0x00600000 -> reset int
read --> 0x00 : 0x00 : 0x00 : 0x00 : 0x00

When the mask is 0x00400000 the button is pushed when the mask is 0x00600000 the button is released. Of course the positive edge will be omitted because this means that the interrupt is being cleared by the i2c readout.

The only thing left to test is the DAC values when the resistors are replaced. I also ordered a bigger SDRAM of 64Mb. Fingers crossed ;-)

i2c shared library continued

Previously I told you about some problems I encountered with writing my proper library to interface the I/O functionality of the i2c extension board.

- One of the leds didn’t work --> replaced and ok

- One opto coupler not connected --> wire patch and ok

- Unload function called twice --> constructor copy/paste error ok

After that I continued with testing the DAC. It was soon obvious that the levels were not correctly emitted. 3/4 of maximum digital input was already maximum analogue output. I discussed it with my friend who did the hardware and soon he saw an issue in the calculation of R2/R1 for the opamps he forgot the 1. The correct one was:

Vo = 1 + R2/R1

So he had to order some new resitance with 1.65K. Replacement planned for this weekend. I also finished testing my shared library interface now. I covered following :

1. Writing all banks output PCA
2. Writing per bank output PCA
3. Reading all banks input PCA
4. Reading per bank input PCA
5. Writing all DAC
6. Writing individual DAC

Error messages are logged into syslog system because this must be able to run as a daemon without stdin/out. Next thing todo is making a GPIO shared object on the same basis as i2c one. Finally test this out with a small interrupt handler that catches the pca level changes and act appropriate. If that is covered I only need to write one more proof of concept for the playing the wav files. This will be done using linux message queues. Also a little daemon process that sits and wait on new sound demand arrivals. Whenever these things are done, I hope end of this mounth, I finally can start with the real domotic logic.

webtoolkit

After putting an enormous effort in porting the boost/wt I gave up because I found a better way to reach my rich client interface. There were still undefined errors on some functions even after a new buildroot. I posted two avrfreaks topics but as most of the time they face out and are doomed to die after introducing detailed problems or even things that are "too simple" for certain individuals or once you get off the front forum list page:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=65818

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=65743

Instead of spending hours of iterating trying to find the buildroot problems JavaScript is the one to go for if you want to redirect and lighten the burden on the server site. I bought two books on the subject:

- JavaScript: The Definitive Guide, 5th Edition (David Flanagan)

Need to learn JavaScript fast? This best-selling reference’s visual format and step-by-step, task-based instructions will have you up and running with JavaScript in no time. In this completely updated edition of our best-selling guide to JavaScript, leading Web and computing experts Tom Negrino and Dori Smith use crystal-clear instructions and friendly prose to introduce you to all of today's JavaScript essentials. Along the way, you'll find extensive coverage of Ajax and XML techniques, current browsers (Opera, Safari, Firefox), and more.

- JavaScript and Ajax for the Web, 6th Edition: Visual QuickStart Guide (Tom Negrino, Dori Smith)

Two brand-new chapters explain the cornerstones of the Ajax application architecture: scripted HTTP and XML processing. Another new chapter shows how to draw client-side graphics using the tag and other cutting-edge technologies. Yet another new chapter explains the use of namespaces in JavaScript: essential when writing complex programs, rather than simple scripts. This edition also includes new material on classes, closures, persistence, Flash, and JavaScript embedded in Java applications.
As always, JavaScript: The Definitive Guide is both a complete programmer's guide and a keep-on-your-desk reference manual. Part I explains the core JavaScript language in intimate detail. If you are new to JavaScript, it will teach you the language. If you are already a JavaScript programmer, Part I will sharpen your skills and deepen your understanding of the language.
Part II explains the scripting environment provided by web browsers, with a focus on DOM scripting with unobtrusive JavaScript. The broad and deep coverage of client-side JavaScript is illustrated with many sophisticated examples that demonstrate how to:Generate a table of contents for an HTML document :
Display DHTML animations Automate form validation Draw dynamic pie charts Make HTML elements draggable Define keyboard shortcuts for web applications Create Ajax-enabled tooltips Use XPath and XSLT on XML documents loaded with Ajax And much more...
Part III is a complete reference for core JavaScript. It documents every class, object, constructor, method, function, property, and constant defined by JavaScript 1.5 and ECMAScript version 3. Part IV is a reference for client-side JavaScript, covering legacy web browser APIs, the standard Level 2 DOM API, and emerging standards such as the XMLHttpRequest object and the tag.
About the AuthorDavid Flanagan is a computer programmer who spends most of his time writing about JavaScript and Java. His books with O'Reilly include Java in a Nutshell, Java Examples in a Nutshell, Java Foundation Classes in a Nutshell, JavaScript: The Definitive Guide, and JavaScript Pocket Reference. David has a degree in computer science and engineering from the Massachusetts Institute of Technology.

These are to ones I'm going to read during the summer period and of course practice a bit the language spec. So in fact the user interface can now be served by PHP as cgi and JavaScript as the client site enrichment. Nice I would say.

I tested yesterday my i2c shared object that will contain all i2c functionality internally divided in following structure:

- general
- board specific
- pca specific
- dac specific

Tests are going well. I saw that one of the leds acted some kind unstable but it's now back ok. And also the fact of missing a one of the inputs. This must have some further investigation. But normally the library itself proceeds very well. I introduced the _fini/_init load and unload functions to trigger those actions. Strange thing was the whenever my test executable starts and load the SO lib I get a unload event first. This is kind strange though because there's no other process that uses this lib. I check on it with strace.

another web tool

Very busy lately back again at my blog. A few weeks ago I heard someone at work mentioning the existing of WT toolkit. A web toolkit written in C++ based on the set of boost libraries. More info can be found on following links:

http://www.webtoolkit.eu/wt/
http://www.emweb.be/

http://www.boost.org/

I thought it might be great to have that toolkit running on the NGW because of the rich interface components you can use on the client. Of course this demanded for the porting of all the C++ libraries to AVR32 which isn't an easy thing todo because the boost project uses the bjam make tool and wt the cmake. I'm still busy with it as we speak. The compilation for boost is done by making symbolik links to the avr32 tool chain to bypass the bjam stuff. I'm not sure if this is the right way to go. The cmake for wt is easier for cross compilation and went smoothly. Nevertheless there're still problems in finding (C++) library functions on the target after installing the libs in the LD export directory. I even had to remake the buildroot with wchar support. But this is also a good exercise to learn the possible linux library configurations. So I will continue this in parallel with my proof of concept. But the WT project has started me thinking on the possible other ways to build my browser interface like using JavaScript / Ajax and DOM. I will buy a few books on these concepts because they are all hot topics now a days. From O-Reilly:

- JavaScript: The Definitive Guide, 5th Edition (David Flanagan)
- Ajax: The Definitive Guide (Anthony Holdener)

Meanwhile I started with the proof of concept in building a shared object library for the I2C stuff.
I made a i2c_func.so library. Still not sure on the versioning stuff in respect with ldconfig. Will investigate and read more on that subject. What with multiple so versions and their symbolic links?

I already learned the 3 sorts of lib :

1. Static library (extension .a) -> code becomes part of final exec
2. Shared Object (extension .so) -> code stays in lib automatically loaded with exec startup (depends on LD conf where to find)
3. Dynamic Link Lib ( extension .so) -> code stays in lib linking when needed at runtime (get func/sym with API)

I also played a bit around with tooling like NM , OBJDUMP , READELF , LDD , LDCONFIG to name a few. All very practical command line programs to investigate objects and libraries more in-depth. Cumming up are the summer months lets hope on good weather but if not I know what todo ;-)

sending mail from the NGW

In the php continuation story I felt the need to add some mail functionality to the NGW. I did some research on lightweight smtp clients and MSMTP came out as perfect candidate to use on the NGW because of his simplicity. No heavy source tree just the basic thing rfc 821 implemented. Cross compilation went smoothly and it's just a single executable to install on the target. I expanded my PHP exercise with this functionality and it worked greatly. I used the popen() PHP function to call msmtp and fed the parameters by file as well as runtime strings both did the job without using a mail agent like mutt or nail. Page can be viewed if NGW is up and running:

http://guyvo.no-ip.biz/php3

I think most of my components are now present on the board and I will carry on with the general proof concept, which was still on the todo list. After that I can begin with my analyzes on the final domotic system. There 're still some other interesting concepts to investigate like inter process communication between the php session and the domotic deamon program but I will take care of these as the analyzes progress. To end this blog let me resume with a list of already installed NGW functionality:

Root FS on SDCARD with swap
OS linux 2.6.24 kernel
µLibc / dev
Busybox shell tools
Web server
Telnet
Ftp
Ssh
Nfs
Samba
Ntp
PHP 5
Smtp client
Extension I2C IO board 40 inputs/40 outputs / 8 dac
Ac97 sound architecture

Yet impressive isn't it ?

Exploring PHP as a candidate for the front end UI

I focused my attention on learning PHP the past 2 weeks. I first struggled a bit around in finding the right tools to test and write PHP/HTML combination. Finally the package XAMPP came out as a great bundle of a web server, a PHP interpreter and a mysql database. Be ware this is not intended to install on the NGW but on the host PC to test written code first. This is a lot easier than always transfer the files to the target. I also installed the version 6.1 of “netbeans early access php” as the IDE. I started to read some e-book based on PHP version 4 to feed the basic skills. It went very smoothly and I saw a lot of good and simple program techniques rising up as I continued reading. The best thing in my opinion is without a doubt making some exercise to master the concepts. The way I prefer is cutting this concepts in to smaller pieces and study them separately first. So over night I dreamt of some small math application covering all my basic learned skills. It was in fact a simple multiplication test with 3 levels of difficulty. I tried to master reading/writing from/to files as I needed it for saving session data. Version 1 was born. An example can be viewed if NGW is running on:

http://guyvo.no-ip.biz/php1/

As this exercise got some final form I rapidly saw that there were a few shortcomings like an overloaded GUI and working with more than one client browser at the same time was not possible. So I continued studying cookies and sessions variables. I adapted version 1 very easily with these concepts. An example can be viewed if NGW is running on:

http://guyvo.no-ip.biz/php2/

Still some important concepts to learn and I plan to buy the book "PHP5 & MySQL" to always have a reference with me. But as I said before the chances are high to go for this solution as the front end domotic interface, and this can only be confirmed now. I get the feeling PHP is capable of doing the job. Using this as a final UI will give us more portability than ever before because HTML is vastly spread now and everyone has at least one browser and PHP (written in C) is easy to port to several popular cpu platforms. (AVR, ARM , MIPS ,....) But I will dedicate a complete topic on the portability of this project in one of my future blogs here.

PS

I can add one more computer languages to my list ;-)

status after holiday

It's been a long time since I wrote my last piece of blog here. Reason was my 7 day of holiday in Portugal. Just before my holiday I tested as much as possible of the previous indicated points:

Writing a test for the DAC (also i2c driven) :
Succeeded but I must take the other supply to have the right levels.

Add interrupt masking to the pca input :
Succeeded but I saw contact glitches to take care off.

Writing a test to catch the interrupt in user space :
Succeeded but it will be better to combine poll/int because of the contact glitches when
push/release the button

Evaluate the level based interrupt and filter (re entrance) :
The linux gpio dev driver definitely stacks the interrupts (level changes) so filtering is needed.

Compiling / installing / testing with lighthttpd:
Succeeded even with the PHP extension as fast-cgi. Also the big pdf issue seems to be solved with this web deamon.

I also extended my overall linux tests on the NGW results can be viewed on my google pages:

http://guyvo67.googlepages.com/index

Still todo are:

-Writing a "covered all" test as proof of concept for the IO board and let it run +24h
-Extend this program including an exec (fork) call towards playing a sound
-Making a documentation of proof of concept

When all that is finished I can finally start the analyzes of the application. As the new web server turns out to be great even with the possibility of the php extension changes are high to go for the web based approach. It would be great to combine my already existing page stuff with the domotics user interface so all is placed in one central spot. And even more it will be located on my server and not one of a provider which brings a certain flexibility and freedom. It sounds very interesting to put some time in learning the PHP language too. To be short things are going Smoothly now. And lot of enjoys in the future weeks to come.

new build

I took the opportunity to make a new buildroot based on the kernel 2.6.24.3 because I upgraded my laptop to ubuntu hardy (8). The installation of ubuntu starting off the live CD went smoothly. And it seems like to run much better on my laptop. The AVR32 related stuff was a bit more difficult to reinstall. I first did it with a wrong tree which was not completely stable but after that I had the official atmel tree straight from the git repository. Of course this took a lot of time to manage but it's up now. I made a personal Google link to memorize what I'd done:

http://guyvo67.googlepages.com/index

It's an excellent aid to have the page maker tool here at Google. This time I even went much further in making the build process almost automatically by a script. This speeds up time. After that I continued in my IO board testing. All the i2c components are now tested and seems to work fine. The patch for the AC97 is also included now with the reset coming from the driver via the PA23. The interrupt from the pca comes in like it should be. Of course this is a level based interrupt and care must be taken in programming this correctly but this is for later.


In the meanwhile I started to play around with some small performance programs based on pthreads. The reason for that is when I tested the httpd and ftp server I noticed problems with large file transfer and because I'm going to use perhaps the httpd to serve my new system. I also introduced a swap partition on sd card. First tests seems great. The test was starting 20 threads and write/read/cmp each 10Mb allocated on the heap. (byte wise) So the swap must be used:

./memc.elf 20 10000

entering thread 20
entering thread 19
entering thread 18
entering thread 17
entering thread 16
entering thread 15
entering thread 14
entering thread 13
entering thread 12
entering thread 11
entering thread 10
entering thread 9
entering thread 8
entering thread 7
entering thread 6
entering thread 5
entering thread 4
entering thread 3
entering thread 2
entering thread 1
start reading thread 20
start reading thread 6
start reading thread 17
start reading thread 15
start reading thread 13
start reading thread 19
start reading thread 16
start reading thread 10
start reading thread 1
start reading thread 5
start reading thread 18
start reading thread 8
start reading thread 3
start reading thread 2
start reading thread 7
start reading thread 11
start reading thread 9
start reading thread 12
start reading thread 4
start reading thread 14
leaving thread 16
leaving thread 5
leaving thread 20
leaving thread 6
leaving thread 8
leaving thread 3
leaving thread 17
leaving thread 13
leaving thread 11
leaving thread 15
leaving thread 7
leaving thread 2
leaving thread 12
leaving thread 10
leaving thread 1
leaving thread 9
leaving thread 4
leaving thread 19
leaving thread 18
leaving thread 14

total used free shared buffers
Mem: 30320 29416 904 0 48
Swap: 240964 176224 64740
Total: 271284 205640 65644

It took 7 minutes which is not bad considering the swap on SD card. I will continue in tests like this and extend them with the use of the network layer.

great progress

Back again to give you some further information on this project. It took a while to test a few proof of concepts. First I adapted the i2c input and output routines to get it stroked with the specification of the PCA9698. I tried both ways ; doing a simple write() and doing ioctl() using the i2c message structure. Both api calls seems to work properly. I wrote a small test program which includes the input as well as the output functionality. This program ran for 24h without any odd behaviour. So now I'm pretty sure that the IO board works as it was meant to be by design. Yesterday I worked a hole day to get the AC97 codec from Cirrus up and running. A few technical conversations can be seen at following link:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=62973

I'd play quit a lot with kernel builds and tests via the procfs systeem. Finally at 21h I managed to play my first sound with aplay as the driving program. It was also indispensable to have the UI alsamixer installed on the NGW. This facilitates the setup of all the codec channels. It's possible todo it via the procfs but quit complex because you must make the link to registers in the specification all the time and of course easy to make a small mistake in setting the bitmasks accordingly. For the moment I only tested the wav format. I will do some quick tests in MP3 using madplay too.

What else do I have the test to be able to say "now I start programming on my new domotic system" ? ( this will be a title some day of one of my blogs here ;-)

1. Writing a test for the DAC (also i2c driven)
2. Add interrupt masking to the pca input
3. Writing a test to catch the interrupt in user space
4. Evaluate the level based interrupt and filter (re entrance)
5. Writing a "covered all" test and let it run +24h
6. Extend this program including a exec call the sound program
7. Making a documentation
8. Compiling / installing / testing with lighthttpd

If these above steps are all behind me than I can proceed with the domotic logic for the final program. I'm still not sure if I will integrate this into web based design. This will depend on the results of step 8.

The horizon is something you can never reach nevertheless continue to try !

connected to NGW and up and running

At last everything on the i2c side works as it should be. Special thanks to Manes for his effort in replacing the components. In fact we had only one error on the board which was a wrong position of the jumper for the external extender pull up, introduced from the start. The rest of our problems was pure invoked by causality reasons. I started a bit of a panic and did some wrong measurements on the board that resulted in fucking up almost all the i2c chips. It was as simple as that. I tested quickly the inputs and outputs already and seems to be ok. In depth testing will be for this coming week. I will post a full test report here at my blog later.

We are back into business finally !

removing the smd pca9698

So here we continue our struggle to solve the hardware problems on the IO board. I took the board with me to my work because of the lack of the expensive equipment at home. On the sides I show you some pictures in sequence on how and with what the removal took place:

Arrival in the lab

Removal pca with hot air

Capillary cleaning

Removal device for SMD and BGA

Cleaning device

The Weller lab

Next episode will be soldering the new PCA9698 and extender on the IO board and testing with the low level assembler routines for the I2C proof of concept.

the hell of PCA9698

Here we go with the continuation of our doom story. In the previous blog I told you that Manes would test the i2c with his logic analyzer. And he kept his promise here are the results.
First of all he'd checked the SCL/SDA signal level/transitions with respect to the i2c general and PCA specific specification. It seemed to be ok except that some ACK didn't arrive, as it had to be in the read process. This was odd and suspicious. In the process of testing with the only good PCA he made a mistake in putting 12V on the inputs. So guess what another chip fucked up !

But more important he tested his bit-banging algorithm on a simple PCF and all signals appeared like in specifications. Conclusion is clear the PCA output chip was also fucked up earlier together with the input PCA. The ordering of 2 new PCAs and one extender is now in progress. We expect to test again with the new chips till the end of this week. This time we take things gradually no doubt about that.

In fact the reason why all chips were fucked up isn't yet totally clear in my opinion. When I first connected the NGW to the IO board, the chips were just soldered on the board and didn't see any of supply. At that time we had already the voltage drop. (1V) So the question here is what caused this drop ? It's true after the uncertainty of all that I started to play with board and did some measurements (eg. capacity); which in fact were not that smart. So it could be that in the process of all that some of the chips suffered badly of unwanted supplies. Nevertheless the previous question remains. I definitely want an answer on that. Maybe things become clearer when we replace the components gradually. I propose replacing in following order and test via bit-banging assembler program:

PCA output
PCA input
Extender

Suppose that after replacing all components everything is working back again than possibly the reason of malfunction was that one chip was already broken before the initial testing with the NGW. But these are speculations for the moment so I leave this conclusion till the end of the week. If tests with 8bit debug AVR went well, I can test with NGW linux bit banging algo's. If these work I finally can build the domotics. If these don't work I probably have to make changes on the existing bit banging algo or considering writing my own device driver from scratch.

In order to remove the two smd PCAs from the board a special suction tool is needed otherwise the board will be irrevocable damaged. This tool, I can use from the firm I work for luckily. I will take some shots of before, while and after for the blog because perhaps it will be a point of change in our luck so far.

error trackings

In the previous blog I mentioned the i2c problems when connecting the IO board to the NGW. The TWI lines of the AVR32 stayed at 3.3V so I had to find a workaround for that in the first place. I rebuild the kernel with the GPIO i2c instead of using the atmel twi driver. First it didn't work when simply selecting the GPIO and deselecting the twi in the menuconfig. I had to comment out the GPIO defines in the setup.c file so it was always taken. This must be a small config bug somewhere in the buildroot I use. After that the GPIO was proper recognized and i2c-0 appeared in the dev list. Even more, the device name was the same as the twi driver so any modification on my user space programs were not necessary. This is a good example of portability if you ask me. I checked out the waves on the bus with my scoop and this seems to be as it should be. Happy for sure because I could continue using the NGW to connect to the IO board.

In the meanwhile Manes started to dive into the IO board measurements as you can see on the picture in this blog. First of all he discovered the same voltage drop when connecting his debug AVR (8 bit) master. He disconnected the extender , put on the board for future use , and start running his output test program for the PCA. The 40 leds started to blink at last ! But he also saw that the signal level on SDA was only ca 2V. So his test program for the DA converter failed. He decreased the pull up a bit and the DA converter test was also running fine. I visited Manes one evening and connected the NGW , now with GPIO, to board in order to check if I could also play with the 40 leds on the output. But none of my tests seemed to work. So making use of the linux i2c driver was indeed not the same as the assembler (also bit-banging) test program of Manes. further investigations needed here.

Just one more test to go : the inputs. First try outs of reading a simple pin change and put it onto the output leds failed. Second test with printing the input read outs constantly on the serial console failed with same behaviors. Manes took the initiative to cut the SDA line of the PCA input. And guess what : our signal drop was gone ! Both SCL/SDA had a proper 3.3V. Than the idea that the PCA input was fucked up was more or less clear. After that, he started to run his input tests on the output PCA. Until now he didn't succeed in getting this working. Even with the addition of the repeated start condition. He will investigate this with logic analyzer this afternoon.

The fucked up list until now:

• AVR32 twi lines
• Extender P82B96
• 1 PCA9698

We have to wait now for the results of the logic analyzer. The moment we have a reference level/transition i2c construction for the PCA to work in both read an write will be very important to make decisions for the future of this project. If this indeed is a kind of a special signal, than changes to the default GPIO driver from linux will be indispensable.

Stay tuned for the thrilling moments to come...

NGW meets IO board

The first thing I did was checking the position of the control signals on J5. I changed the configfs mask and output accordingly. I also added two lines to the script to accomplish the reset for the audio codec and pca. And than the moment arrived to switch on the power of both boards and let the linux kernel boot up. Ok so far so good power led lights up and off we go...

I noticed already in the boot sequence that the audio codec was still not recognized as an ALSA device. This could be due the fact the reset executes after the loading of the kernel module. So I tried with a warm NGW reboot after reset still the same. This means that testing the sound was not possible because I didn't have a DSP in the device list present. Still not sure if the message printed by the audio driver was applicable on the AC97 I posted a question on the freaks forum.

I let the AC97 behind I started to the focus on the I2C communication. I adapted the C program with the proper address of the output PCA. I first tried with a simple write of 6 bytes 1 control and 5 outputs hoping the acks where properly formed. This was not a success. The second thing I tried was sending them using the I2C message struct, which normally takes care of the acks in between before sending a stop condition. Still no success. Last thing I could do was taking back the I2C bus scan routine and see if the board controller was still connected. This test was terrible all 128 address tests failed in giving me the "connection time out" as an error message. If I cut all the flat cables to the IO board the test performed as it should be. At this point 4.7K resistors were used as pull up defaults from NGW. I tried in putting 3.3K in parallel on the IO board because the specification of the PCA recommends even 1.6K pull up. Still no success. After some initial checks on the PCB layout Manes discovered that the RESETs of the PCAs were not connected to the flat cable. So the second wire patch was a fact. Again restart with all tests still the same. Sounds like it had something todo with board itself and it was a good moment to start thinking on scoop measurements. The signal on both SCL and SDA were terribly bad, when the IO board was connected to NGW. I'm talking here of signal droppings from 3.3V to 1V. Of course this was the reason of the malfunction here. The I2C bus was to heavily loaded for the NGW open drain output.

The twi output of the NGW stops after a few seconds when testing a write in loop. The output remains static on SCL ca 0V and SDA ca 1V. And now it's even doing nothing anymore its just stays on 3.3V. It's obvious that these two outputs are broken. It's a pity that on evaluations like NGW apparently nothing is foreseen to protect or buffer the IOs. It was also unexpectedly because the proof of concept with a single PCF worked well. But if the amount of connected twi devices rises the charge on the bus will do the same and modern micro controllers like AVR32 and ARM9 are not that well protected against these loads.

Probably introducing a I2C extender or signal converter (3.3 -> 5V) solves issues like that. But that I can't prove at the moment I’m afraid. As my SDA/SCL is fucked up I must find a workaround. If I can't find it the NGW board will be of no use anymore and can be trashed. The linux is still booting so I think it's only these two outputs that are bad. Buying a new one is of course the only solution if I want to continue using the atmel dedicated twi. If I can go by the GPIO driver (no atmel twi but bit-banging) and switch to some other gpio pin numbers on the connector than there' s a bit of hope left. But the reason of malfunction must still be proved. So a test with extender/converter will be indispensable. A converter is preferred over an extender when a IO board revision will be made because lack of space on the NGW to mount extender.

I'm very disappointed. Maybe Manes could avoid things like that in considering worst-case situations. On the other side it still remains a low cost development kit of less than 100€. Now more and more the question gains presence in my mind:

"Is this a good solution to serve as a 24/7 application in situations where an influence like electrical disturbance is present?"

I still have some hope though.

Day 3 final lay out

40 inputs ( with opto coupling )
40 outputs ( with ULN buffering )

8 analog outputs (0 - 10V)

I2C extender bus ( upto 1M I/O)

Audio AC97 mono (cirrus)

Bus driven I2C / Supply 12V

I2C PCA9698 40 multiple I/O interface up to 1M transfer speed

The only error on the board corrected with a small cable connection

EAGLE AutoRouter Statistics:

Job : c:/eagle projects/domos3/domos3.brd
Start at : 14:24:46 ( 3/01/2008)
End at : 14:50:20 ( 3/01/2008)
Elapsed time : 00:25:34
Signals : 337
RoutingGrid: 3.93701 mil Layers: 2
Connections : 743 predefined: 245 ( 46 Vias )
Router memory : 10817864
Passname : Route
Time per pass : 00:25:34
Number of Ripups : 188
max. Level : 4
max. Total : 27
Routed : 498
Vias : 875
Resolution : 100.0 %
Final : 100.0% finished

Day 2 addendum

This board situation will first be tested. If everything works correctly Manes can proceed with only two chips left to add to the board. Great job man !

If I see the board I'm getting warm to start writing the software for my third domotic system. Everthing is almost prepared so I can dive in the code when I want. The first thing that I must do is testing the I2C as a proof of concept of the PCA because it is a little bit different compared with the PCF.

More board pictures will follow as we continue.

Day 2 soldering

Day 1 soldering

A special thanks to my friend manes for his contribution in the project. I couldn't do this without him. Keep up this beautiful work man ! In the meanwhile I'm preparing a master SD card with everything setup as it should be. When this master is ready I can take some hard copies to have a backup. If the soldering goes as smoothly as this was done on only one day than I can start testing the first of April. (and that's no joke ;-)

The first component brings light into the darkness

Components arrived

Picture PCB back side

Picture PCB front side

Still reading and learning

It's been a while that I wrote some stuff here because in fact there's not much to tell at the moment. I'm waiting for the PCB to finish and the order of the components. In the meanwhile I reorganized my computer parc. I had to reinstall the ubunthu installation on my new laptop. The avr studio is already up and running so I can continue my development.

Concerning the books i'm reading well it's the book on kernel development which is near my bed at the moment. Still much to read i'm half way now. All concepts of the linux operating system get the attention step by step. Not that I need these things directly but the intention is to get a better in depth view on the OS itself.

I also experimented with the general security on the ngw meanwhile. The device drivers I'll use in my final user space program are owned by root as user and I wanted to login with my own user name. I added myself in the root group to be able to have access to these drivers. This works great.

I think in about a month I'll start programming again on this project. As soon the PCB is ready I'll post some picture as promised. Just have some patience now.

My development PC is a laptop now Toshiba P200 dual core with dual boot Vista / linux.
I noticed the linux has some better respons ;-)

Books

Just for the record I publish my 3 books I'm reading for the moment:

GNU/Linux Application Programming (Programming Series) (Purchased on 01/27/2008)
by M. Tim Jones

Linux Kernel Development (2nd Edition) (Novell Press) (Purchased on 01/27/2008)
by Robert Love

CGI Programming in C and Perl (Purchased on 01/27/2008)
by Thomas Boutell

Reviews will follow later on as promised.

Adding audio why not

Due to the fact that I use an audio player with the existing domotic system I checked out the possible ways on the NGW. I was quit surprised to see there were a few possibilities to go for. I had the choice out of:

1. ABDAC
   
2. I2S
3. AC97

I tried the rebuild my kernel with sound enabled. I had to play a bit around with the options in the menuconfig window to finally get some device to play. I also installed the IPKG install tool to get small binary packages more easy already compiled for the AVR32 target. I installed the madplay as a player to try out the sound device. I managed to play a MP3 song from the command line but only to the /dev/null dummy sound driver. Of course this normal because I haven't connect a codec chip yet. I asked a few opinions on the freaks forum and apparently the AC97 was the one to go for. I tested the ABDAC output and that seems to be ok because it has the build-in capacity to convert a 1 bit stream. But the quality of sound is poor. I left alone the I2S option this is used in the other larger development kit STK1000.

So I decided to take the AC97 option widely spread in PC sound cards. I browsed to the Cirrus site and found a suited codec chip that could be easily connected to the AVR32. The drawing in my previous blog must change in order to get the sound on board but this should be finished as we speak. See the final drawing in this log. The board will be soon in production now. It must be said that it will be a large board (10x21cm) but there's plenty on it. I also limited the amount of layers to 2. Al I/Os are very good isolated against any disturbance from the out site so I took the risk.

As soon the board is ready I take some picture and post them.

In the meanwhile I'm still busy reading in my purchased books. The subjects of the books and the reason why I read them:

• GNU application development ( for general development )
  
• Linux kernel development ( to get a better view on the inside )
  
• CGI in C and perl ( to consider the web server possibility )
  

To soon to give a small review on them but I will do it when I finished them all. For the moment it's very important that I get a more in depth view on the linux OS in general because it's my first time that I develop some stuff for linux. I was used to work against the windows win32. But as I already can say now their are plenty of things in common like the use of libc and OS basic principles like processes, threads and synchronization. But still much to learn ! My proof of concept that I have in mind is still growing everyday as we move on learning. I try to do some examples from the accompanied CDs as well. The results of using CGI from a C program on the NGW is quit great I must say. But I will write some dedicated blogs on a few topics that I learned or found amazing to discover from reading the books.

drawing general purpose I/O board for ngw100

design I/O board for ngw100 ready

As promised in one of my previous blogs the I/O board drawing is ready to go in production. I post a complete picture separately for better view. What are the features of this i2c board:

• 40 inputs
• 40 outputs
• 8 digital to analog outputs

The inputs are totally interrupt driven and will be handled by the user space program on the ngw. The board splits up the inputs / outputs by two 26 pin connectors for each. This was done to provide some compatibility with the older system. There will be a main supply of 12V which will also be used for the ngw. Leds are provided for input as well as for the outputs. This is useful specially in the test phase. Finally this board connected with ngw will act as the domotica heart of the system. I will release some more picture when the board is really made and soldered.

preparation of I/O

In anticipation of the brand new PCB that is going to take care of 40 inputs and 40 outputs I did already some useful research. It will be necessary to have not only the related i2c signals available but also some i/o pins which are going to deal with interrupts and output enabling. Therefore I must have 4 signals connected to the gpio of the ngw. To be able to do this kind of signal capturing there are 2 possibilities:

1. Writing a kernel module
2. Userspace access via configfs

I preferred the user space to take. This has the advantage of having everything central and easy to debug if necessary. It took some time to finger it out how the configfs was working but finally it became clear. I wrote a little start up script to add the files under the appropriate directory. I took a c example of the avr freaks site and compiled it in the avr studio. This example showed the different approaches you can have when working with gpio as a character device. So it was excellent to start with. I set things up to work with the dedicated PA pins also needed for my new i/o board. I tested the 4 lines in having 0/1 and all state changes popped up very well on my screen. I was bit scared tough because the 4 pins where located on the same port as i2c. But I ran the led program together with the i/o program for 12 hours and things didn't interfere at all ! This was good news because the proof of concept now is almost complete.
This week I expect some good linux books. They will be used to get a more in-depth view on programming applications using the unix framework/kernel like signals , threads ,... I will have some blogs on them later on to review a few chapters. Now I can start thinking of the program structure I will use to write domotic program.

So always preparing for next steps in small well-aligned pieces is the way I like to make progress in complex systems.

public web access

After having a discussion on the possibilty that the IP address from your ISP was unique or not I investigate this matter in more depth. And I must admit it's unique but taken from a dynamic pool in my case changed every 36h. If you don't have something to solve this, than the option of working remotely on the ngw via a web interface isn't that wonderfull at all. You must have something fix that always points to your address whatever it is at that moment. The solution is finding an instance which hold your IP address and link it to an URL. Also having a client running that at regular basis updates your IP address to that instance.

I took www.no-ip.com as the solution for my problem. Register with your email and fill in the free option of DNS host and off you go. I also downloaded the linux client package which comes with the source of the client. I compiled and linked it against the AVR32 libraries in the avr studio. I installed the new client as a daemon on the board. It works really great ! I tried it from work today and went smoothly.

Now I can be sure the ngw board is accessible from wherever I will be I just need an internet connection and a web browser but these are common things these days. The reason I wanted to investigate this matter is that I'm still thinking on how I'm going to build up the user interface. Now HTML becomes a good candidate to include in the list.

Next step is perhaps a smtp client. Not needed absolutely but still handy if you can send something out there when some events arise. This can of course also be logged and send by the cgi-bin if I like.

Still have to look into some security stuff also. I noticed that the root level directory of the web server isn't protected even if I put user/passw in the config file. And security you must have if you are open to accept connection on port 80 coming from the internet.

GDB on NGW

As stated in previous blog my learning cycle still grows with a reasonable speed. I struggled a few days in finding my way in the world of GDB, the linux debugging tool. Not only GDB was new for me but also the fact of doing the session remotely from within avr32 studio.

So I first started in making the Belkin access point up and running. This was still configured as DHCP and WEP encrypted. I changed my Philips router to the WEP again because I suppressed encryption due to the new ubuntu on my laptop. But in fact this was easy to enable again and now all my network devices work with the same WEP password. I connected the NGW on the access point but it the fix IP was not visible anywhere on the network. After a bit searching I suddenly realized that I didn't add the MAC of the NGW in the remote access table of the router yet. That solved indeed the problem. Happy as I was to have my chain completely set up, as it will be running live. I tried a few basic protocols over the network like a simple telnet session, NFS, samba and HTTP all seems to work properly. Now I don't have the NGW on my desk anymore but it locates in the electrical closet now, which is in the garage. I will shoot a picture later on and post it. Fully operational I must say!

At the same time setting this up I was also experimenting with remote debugging because the linux distribution on the NGW had a gdbserver installed. I tried and tried and tried but still having errors the moment gdbserver started the application. Sometimes I got "cannot access address ..." sometimes "segmentation fault". I changed several properties on the debug tab in the studio but still the same. I posted something on the avrfreaks network but no answer. Yesterday finally I saw where the problem could come from. Until now I always used the default "gdb" as client program to start within the studio. I did a find on my laptop and I got 100 hits on gdb like programs! Of course I had the wrong client, which works only with i86 gdbserver. I changed this by pointing to avr32-linux-gdb and oeps I was in ! This can be signaled as an error to the developers of the avr studio in my opinion. I tried a few debug features and all seems to work, even the viewing of the default register bank of AVR32 like R0-R12, SP,PC and LR. The special AVR32 registers like PIOA were undefined which is kind a normal without a JTAGICE and running in linux user space.

Doing al this I’d realized that a good understanding of the principles of linux permission is indispensable. I noticed for instance that if a C program tries to access a driver by IOCTL function and the user who started this program has no RW permissions on the driver modules all calls fail. It's easy to solve in doing chmod o=rw [driver] so that "others" can access too, assumed that the driver was started by root. But still if you are not familiar with that kind of protection it takes some time to get used to.

In the meanwhile a friend of mine is also started on the new IO board, which will be connected to the NGW. Totally based on the i2c protocol. I will dedicate a few blogs on this item in a few weeks when the PCB is finished and when I can go into details.

Maybe the first I’m going to try now is registering the no-ip.com site to be able to access my webserver on the NGW from anywhere on the internet. This works already but every time my ISP address changes I must use another address. I will start trying to compile and link the client daemon against the AVR32 chain because it’s really necessary to have this running undependably of any laptop or desktop pc.

further exploration

I continued in checking and find my way in the configuration files in the /etc directory. I saw some lines in the smb.conf that I found interesting to uncomment because they had NetBIOS in there name and could be useful when you work with samba server. Doing that had some serious influence on the OS behavior. The NGW went to almost 100% cpu load and the inetd deamon was printing error messages into the /var/log every second. This was certainly not a good thing to do. So I changed these back to original comment. I still not know exactly what causes the inetd daemon to run weird like that, but I was happy to saw the CPU load falling back again to 98% idle.

I also checked the possibility of accessing the web server of the NGW from the outside Internet. Therefore I had the setup the NAT of my router and rout the port 80 to the fixed IP of the NGW. This went smoothly. DMZ is also a solution but far less secure. Maybe I wont use this feature in the future because I have a dynamic IP address given by ISP that changes every 36h. I spoke to some friend of mine and maybe he has a solution for this with some DNS registry you can do in that case. I'll talk more on the subject when I have tried it.

I rewrote the led program, as it should be. Now all combinations of button presses/released are possible even at the same time. I just improved the state checking in the callback routine and introduced some enumerations for clearness and proper code styling. The avr32studio is my development platform I use on my laptop. A pity is that in that environment, based on eclipse, the "code assistant" feature doesn't work properly. Only if I declare includes with full path and not using the short form

this seems to work. Yesterday I tried to manage a remote debug session because the NGW also have a gdbserver installed. The connection seems to work, but in entering the elf executable avrstudio tries to read at address 0 and apparently there are no symbols loaded for that address. I even tried with static linking same result. This feature could be useful as development will progress of the new domotic program and difficulty degree will rise. For now a printf will do.

As you can see there’s plenty new tooling and stuff to explore.

This story continues next month...

Big step forward

My first application using i2c driver was a success. It must be said that the test board was not ideal because of the inputs together with the outputs in one single pcf8574 but I managed to check my proof of concept.

Than it was time to investigate a bit more on my SD card problems. I had to isolate a few possibilities in order to get a clear view.

These were my possible causes of error:

• SD card read/write wrong on my ubuntu host pc
• SD card read/write wrong on NGW using u-boot (1.1.4)
• A faulty distribution of linux using buildroot

So I approached this problem with eliminating as much as possible. I set up a NFS boot from my hard disk on the latop. After seeing the result was fine the old version of u-boot could be more an more the cause. I updated the u-boot holding my hands tight to the table. I restarted the board and saw the u-boot prompt popping up with a fancy 1.3.0 as version. This was great !

I continued in making my kernel and busybox (with fancy prompt) again to be sure I had a new distribution. I put it on the every SD/MMC card I have and guess what all worked properly ! This was indeed a great step forward.

Now I can be sure of the indispensable backup possibilty and the power of making my own distribution if I want too. I continued in configuring the board. I fixed the IP address. A little problem arose with the nameserver but quickly solved by the great avrfreaks forum. One of my next things todo is checking the access point and making it also a fix address. After that I will be able to test the complete network chain. I will do that in writing a small echo server.

Step by step sometimes 2 steps back but if you finally make 10 steps forward it was worth waiting.

Further news on I2C

All leds were up and running with 500000 255 read/writes done yesterday evening. Great news that I really needed to decide to continue in spending time in NGW100 and analyze the replacement possibility for my "domos" system (ATMEGA32)

Yesterday evening I wrote a C program using the POSIX interface. I used a the ualarm() function instead of iTimer because I couldn’t find it into the /avr32-linux/include directory. This was my first contact with callbacks in linux and I must say this is working pretty straightforward. I think if you have the basic knowledge of OS principles (like win32) than you can adapt yourself more quickly.

The program I wrote toggled all leds every 20ms and it worked great. This I did to able to measure with scoop on one of the outputs. The square wave I saw was pretty nice. I reduced the amount of time and ( 10 and 5 ms) I saw a small unevenness in square wave. This is probably due to the overhead on context switching of the kernel. But I considered this as a normal behavior in general purpose OS. This could be solved taking a real-time OS. But 20 ms is more than enough for my application.

I now started to write a small modification on previous program which will capture the state of the 4 buttons and act appropriate in toggling the 4 leds. This can't be too difficult but still as the inputs & outputs are more or less inverted care should be taken.

May the leds be with us.

Goody goody

Wonderful finally see some good results. After a weekend of struggling with i2c I succeeded in a read/write. After reading some code examples on the net I noticed that the address given to the driver was wrong. It must be shifted right by 1 because of the abstraction of the read/write first bit. This is more or less indicated in /linux/i2c.h as 7 bit address but still confused me in seeing only the specified address in front of my eyes. Sometimes indeed it's an excellent idea to just read some other code and suddenly you realize that you did something stupid. Call that the blindness of the idea fix you have. Nevertheless this address thing could be better documented!

Test is running now as we speak in making a verify (write/read/compare) . For a start I let this running for 24h and see the result this evening. Eager as I was this morning I just checked and we did already 200000 verify cycles in a scenario of 255 write/read per loop. Great!

Next step at code level will be investigating the timer object in C/C++. I would like a callback function, which is called every x time. This is not new for me I did plenty of that at win32 level but now i'm starting to learn linux as OS. Sounds like a great exercise.

There is also a lot to discover at the buildroot/kernel level. And I would like to start with flashing the root and usr JFF2 file system into flash. Like that I always have a backup system, the moment the SD card is failing I easily switch to the flash startup. I want to be able to quickly have a system up/running because it will work 24/7. So focus on robustness and backup guaranties is indispensable for me to have.

More news will following on the first real test running now.

Test print connected to NGW100

First tryouts

As the weekend is passed now I have a bit more experience in using the NGW board. First of all I did some testing with using the i2c driver of atmel this can be followed on the avrfreaks:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=58666

As expected, the usual problems that you have with everything for free and fed by a community, is also no exception here. The lack of a good API and functional documentation for instance is a real pain in the ass. You only have the stories of some good souls who wrote on several forum threads to help you out (or not). You always can write a driver yourself of course but that shouldn't be the objective as the linux framework lives long enough to provide something transparent and portable to easy adapt on new target cpu's.

So first you have the above problems in the free world and secondly you have a GCC based framework that sometimes is complex to work with. If I look at the buildroot compilation and linking of the avr32 linux and rootfs well this still has some great lack on documentation too.
As it is normal in this world to use config files it would be great to have a description available to use the several makefiles. This cannot be so hard todo. But still, I notice that people in this world think they are the gods or evangelists of computers and assume that you know all that stuff like them dominating to use linux. Maybe this is because they had to learn all by themselves so they expect that from others too. Yes I know I sound pretty negative here but if you spent almost a whole weekend in just figger out how you must make a call to a simple read/write i2c protocol. What expected to be transparent to the user is totally not case and suddenly you're lost in world full of open questions. You even start to doubt yourself and do some logic analyzer testing to finally be even more unhappy because it's not what you intend as result.

It's also true that i'm still quit a newbie in this stuff and have a long way to go. Good news is that TCP/IP sockets model work without any problem on the board. I tested it with some simple client/server echo model build as managed avr32 linux elf file in the avrstudio.

Also a pitty is that I still can't make any other SD card with linux dist. I even tried a MMC card but no luck. I only have the 512M for now. I even tried with copying the partion with gparted on a 1G SD. The copy succeeded but when u-boot starts up read error in decompressing the kernel. In my opinion the u-boot code can only handle a limited amount of cards although I'm not totally sure of the ubuntu drivers on my laptop.

I will also post a picture of the little I/O board based on PCF8574 I2C to test the NGW100.

Linux kernel up and running !

Since yesterday I succeeded in booting from a 512Mb SD card and having a new kernel running 2.6.23. I noticed that in the process of preparing the SD card with the buildroot distribution sometimes my ubuntu system had some problems with properly unmounting the EXT2 file system. This slowed down the process of testing a bit. Basically whenever I didn't get the message pop-up "you can safely remove" the card was corrupted. Finally I succeded in using a USB card reader in stead of having the internal card slot. I assume the device drivers of ubuntu are not working well on my thosiba for the internal slot.

Finally I saved my boot arguments into the enviroment space of U-BOOT to always start up from SD card. I configured following files:

• /etc/TZ into ETC-1
• /etc/samba/smb.conf to allow network 192.168.1.*
• added /etc/profile with $PWD to show path in busybox prompt

Next things todo still continue configuring the env eg IP fix :

• eth0 192.168.1.6 / eth1 192.168.1.7
• Adapting my router dhcp settings to lease addresses from 10-30 so I have 2-10 free to have them fix setup
• Configuring belkin access point to fix 192.168.1.5 without WEP --> need windows for it??

Perhaps it's also a good idea when I have a nicly setup ready to try to backup this using Ghost 2003.

So as you can see plenty things to write about in the future.

I changed the color to green to see the effect on black background.

Next step linux from SD card

As everything runs smoothly out the of box using the 8Mb parallel flash for root fs and the 8Mb serial flash to mount /usr I think it will be a good idea to move one step forward and try to boot from a SD/MMC media card. I started this process yesterday.

Right now I'm busy to making a linux distribution ready to boot and run from SD card. The buildroot run was quit nice only a bit long. Finally after having the binaries ready I copied the TAR archive to the EXT2 formatted SD card (1GB) from SanDisk. I encountered already some problems with reading this card in the target board. When I changed the SD card to a 256Mb from Pretec the boot was much better but still not running. I subscript the www.avrfreaks.net forums and start an issue on these problems and can be followed clicking this link:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=58549&sid=d74366e69f9ec41056e5e77ecd6d1bee

The reason to make this run possible is partially due ti the fact that the original kernel is a 2.6.18
and is rather old so better to go for the latest 2.6.23 and partially to solved problems in the I2C driver. In my project with the NGW100 I just need the I2C functionallity to interface an extern I/O board. I also need the ethernet in some way but not yet sure what kind of protocol I should use. I did some test already in c using the socket/pthread and there seems to be no problem at all. the first thing that I want to do if I have a fully running linux on SD card is trying to play with the GPIO first from teh linux shell and finally in some c code using simple files attached to the device.

All for now. Till later when I have more (good) news.