Latest History Entry
Got the GNU-ARM toolset from the Australian web site. There are only binaries in the ZIP file so I need to get the rest of the toolchain in source code. Also started to get the documentation for the GNU toolset.
Obtained Atmel EB01 ARM development board.
Installed ARM Tools and setup laptop to start doing ARM development using the GNU Toolset.
Loaded up the ARM SDT onto the laptop and got some of the required Apps Notes from ARM.
Got the ARM SDT talking to the EB01. Generated the library files under the SDT and also got the led blink example working. The SDT requires the files to be in ELF format so the GNU toolset will require recompiling to allow ELF file formats to be generated.
Started porting the AT91 library to the GNU toolset. The C has ported without problems but all the assembler will require putting into GNU format and this will take a while to sort out the new commands.
Now got some of the include files sorted, still need to continue getting the library ported. At the moment the macros do not function and the layouts for the memory mapped I/O still need a lot of work doing to them. Want to also add the ability of different devices to the include files so they become generic.
Put the glibc files onto the laptop so that I have a reference to the way in which the lib files are built and it should help with the syntax of some of the assemble code.
Got all the library files compiling under the GCC toolchain. Now need to get the make file producing both ARM and THUMB versions of the libraries. Also want to put the objects into directories below the library files.
Got the ecos toolset source from CYGNUS, this will need compiling to produce a GNU Toolset capable of generating arm-elf type files. Haven't been able to make it compile yet due to problems with the configuration.
Lee Mitchell has contacted me (met him at the ATMEL Seminar in Blackburn), he has sent me a test file built using the GNU Toolchain under Linux to try. Must get back to him with my progress so far.
Got the library files compiling into ARM and THUMB versions, still need to checkout the couple of instructions in the IRQ.MAC file that are not liked under the GNU toolset. Also the IRQ*.S files do not compile under the thumb instruction set.
The missing instructions have now been made to work under the GNU assembler. Also the IRQ*.S files have been removed from the thumb library as they require ARM instructions to function. They must therefore be ARM type files. The next job is to go through all the SDT projects and convert their makefiles into GNU toolchain make files. Also required is to produce GNU tool versions that will support both ARM and THUMB instruction sets.
The Wriggler turned up today from Greenhills, so I need to get that tested and working on my main machine and then see if GDB will support it.
All the makefiles for the ATMEL library have now been built. Currently though the libraries are missing from the makefiles so they do not create running code.
The WEB pages have now been built, and are to be uploaded to my pages at U-net. I will also upload the current zip of the ATMEL libraries for the GNU toolset.
Have now built the ecos toolset. Still have to rename the binary files so that they have the normal GNU filenames. Then I will start using the tools to generate the AT91 Library stuff and then to build the examples. I need to add the ANGEL library so that the ANGEL debugger can be called by the examples and any other code written. I need to check the built files and then upload them to the web pages in the download section. I need to set up the files and only upload the required files all the others need to be removed.
Tested the ARM toolset on the EB01, had a small problem with the GDB locking up when talking to the board. There was a note about this on the comp.sys.arm newsgroup and a temporary fix. The fix works but the speed of comms is too slow to be useful. Have posted to the newsgroup to see if an answer has been found. Must now get the library ported and the example code running through the GNU toolset. The toolset filenames are staying the same and not being renamed. The makefiles will be changed so that arm-elf-xx filenames can stay. This should make the use of the toolset code OK.
Rebuilt the toolset after getting mod for GDB to stop it hanging when running., thanks to Grant Edwards for the mod. This works with the demo s/w so now waiting for the other code tweaks from Grant. When I have finished porting the example code then I will upload a zip of the toolset files that are required to build the s/w. This should allow others to follow in my footsteps.
Now started to get the first of the Examples in the Atmel library working. The first example compiles and links but the loader line needs tidying up, and then the code needs to be running on the development board. Once the first code example works then getting the reset to function should only be a matter of building the makefiles. This maybe a job for Sunday evening.
Built an angel.lib, this provides function calls for C that call into the ANGEL monitor. These functions should allow the generation of library functions that will ensure the code can be used through the current monitor. I need to get the examples running so that I can complete the library mods. Then they will need tidying up and history comments adding.
Got the angel lib functioning and got some more code ready. Rewrote the makefile for the led-blink example it now makes and produces files of only 20K instead of 80K.
Rewrote all the makefiles so that they all build and produce binaries. The next job is to start testing the binaries. The angel lib now has a scanf as well as a printf in it using the angel library. All the binaries now are very much smaller as they don't link the GCC runtime anymore. Must look at getting the GCC toolset compiling as a Cross compiler from the distribution files rather than the ecos toolset as this will allow the tools to be built better and from more modern sources. Also need to look at getting the GDB shell from CYGNUS running the arm version of GDB not the windows version.
Created a CD-ROM with the GNUsource tree on it expanded, this will allow me to get at the source from the laptop without having to install 500MB of source onto the laptop. I need to get round to creating build structures for the GNU toolset without the use of the ecos toolchain. Need to get the real McCoy running and compiling. Then it will be easier to contribute mods to the tools if required for the ARM EB01 board.
Also need to look at the possibility of generating a documentation CD with just the docs and the html docs for the ARM and the GNU toolset along with any other documents that are useful.
Starting to get the insight GDB shell rebuilt for an ARM target. So far have hit problems with the configure of the build not getting all the dependencies correct when building some of the tcl/tck libraries. It has a habit of trying to build the UNIX libraries and so the makefiles that are generated are then messed up and won't compile. Joined the insight mailing lists in order to find out if this is a problem or if it has been solved with later releases. Need to apply the Grant Edwards patches to the GDB source in the insight stuff.
Made the documentation directory of the GNU Source Tree have a proper HTML front end based on these pages. Now the documentation can be looked from a page and new docs can be added to the index structure.
Applied Grant Edwards patches to the ecos toolset by hand. Am currently rebuilding the toolset. <setlinebuf> in devsw.c is not in the code so have commented it out until its function can be determined.
Got the code for the LED_BLINK example so that it now runs under GDB. Also got the code running under the latest insight running on the simulator. Needed to add a command line switch to generate the debug code for the stuff. Also moved the contents of one of the files around so that the right code is run. The code to detect the end of the RAM in the EB01 will not run in the simulator as it overwrites the code and destroys it. Have tried to rewrite the code but this also is not liked by the simulator. Must have another go at the code.
Tried the new Insight it still would not connect to the target correctly, so have sent off an e-mail to insight to get details on the next move. Got the code to compile and load using the command line GDB, but the code would not single step, this also still needs some work.
Need to start looking at the hardware side of things so need to come up with a bus structure for the design, possibly looking at the use of a 72 Pin SIMM socket as the connector similar to the SIMM Stick stuff. Needs to be more than the 32 Pin SIMM Stick due to the extra number of data and address lines required. Also will require ports for the JTAG port and to get the useful digital I/O lines out to the real world.
Insight is now connecting to the target correctly. The problem was due to the cygwin1.dll not being the latest. Retrieved it from CYGNUS and my problems disappeared. Thank to Fernando Nasser at CYGNUS for the fix.
Now getting the code to run on the target shows that the InitResetStacks code is not appearing in the final binary at the address the rest of the code is expecting. It appears that the code for the InitTableStack is being put in its place. I am currently investigating these problems and hope to spend next Sunday isolating the fault and then getting the code to run.
At last some real progress is being made on this project.
Have now recompiled all the code with the defines required for the target I am using (AT91_ANGEL_DEBUG) and now the code works and runs. It debugs on Insight and runs on the target hardware. The next job is to modify the makefiles so that any version of the software can be built and then to change all the other makefiles to match this one. Lastly the ANGEL_LIB needs to be tested so that the angel calls can be made. This will also mean that the Insight-Angel interface will be checked for full functionality.
The modifications to the makefiles to allow the automatic generation of the different files has started. The make utility with CYGNUS b20.1 is only 3.75 ad it does not support the target dependent variables required to build the multiple versions so I have got make-3.77 from the mingw32 site to use. This works but I have yet to get the objects into separate directories.
Got the source for the latest make facility 3.78.1 and rebuilt under CYGNUS. The version of 3.77 does not allow the rebuilding of the Insight stuff. Got the new Insight source and rebuilt, this still allows the functioning of the EB01. Cut a CD with the source tree for GNU toolchain. Still need to rebuild all the toolchain from scratch and the GNU sources rather than the packaged ECOS stuff. Have not yet looked at the object code into separate directories.
Now got the basis of the makefiles running. The led-blink example has a makefile that will make angel,ice and release versions of the software. The object code is held in separate directories and there is a general makefile, make.make, that holds all the base stuff for all the example makefiles and can be included into them. The next job is to modify all the makefiles to use this new method and then to check the examples run under insight.
The latest set of insight source code patches are available and have been patched into the source tree. The tree is currently, as I type, being built to generate the new code.
Now got the latest insight running. It still has a problem if you reload the source files into it, it does not display the source at all but will still run. Must post this as an error into the insight mail lists. The angel lib does work and the output will appear on the console window if it is displayed. The makefile for the led-blink example has been further modified and the rest of the makefiles are now being modified to match.
Have now completed the makefiles for the examples. The main example directory has a makefile that will rebuild all the examples in all versions. The library and the tools directories now need the treatment to get the files building correctly. The zip file has been rebuilt and will be posted back onto the net tonight.
Have now obtained the latest sources for the GNU toolset. This includes binutils, GDB, newlib glib and egcs. These have all been unpacked and put into my CVS system so I can track the changes and update the source each week before rebuilding the sources. This will enable me to ensure the latest set of tools are on my site.
Have rebuilt binutils and newlib. Am currently rebuilding egcs but have needed to get a copy of gperf before the compile would function. Have also got the latest copy of the GCC tools for b20.1 from Mummit's site. Now the system is recompiling. But have found a missing ')' in fp-bit.c at line 1391, fixing this allow the build to continue.
There is a definite order in which the parts have to be compiled. Once I have sorted out and got working the build process I will document it and add to the web site, so that others can follow in my foot steps.
Still having problems building egcs. There is no autoconf in the b20.1 CYGNUS release, so got the latest from CYGNUS (autoconf-2.13) and built and installed it under b20.1. The install goes into /usr/local/bin so this needed to be added to the path details for bash to work but now the egcs compile is running again. When this finishes then I will rebuild the latest insight since last weeks did not build. Once all the builds are done then I will package them up and put them on the web site in the downloads area as separate packages, then try to keep them up to date with the snapshots as they occur.
Built automake after getting binary distribution of Perl 5.005.03 from cygwin pages. Still having problems with compiling egcs. Got latest Insight last night, the full tar. This has compiled correctly without a problem so must have been a problem with my source tree. The new source tree has been placed into my CVS tree for logging.
Still trying to get egcs to compile. Have now picked up suggestion from the net to make all-gcc but this still fails with problems in fixinc and the texi documents. Have just removed the doc dependency in the main make file to see if it will get past the documents area.
Problems with fixinc sub-directory are due to the code not exporting exeext to the makefile and so the makefile assumes no extension on the executables. I have fixed the makefile in the build process but the makefile.in in fixinc needs to be modified to pick up the extension I probably ought to e-mail the GCC list with this problem and so get it fixed in the source tree. I need to get the compile to run first and then e-mail what I have done so as to give the maintainers as much info as possible.
Still can't get the code to compile so have sent off e-mail to gcc-help maillist to see if anyone else has any ideas.
Have got egcs to compile with a number of mods to the source code tree. These allow the code to compile as a cross to NT. I have started work on getting my RTOS kernel running on the ARM processor. So far the startup code now exists and the processor dependent parts are now taking shape. The SWI handler is taking shape but simulating it via the ARM Simulator in Insight-GDB is not working due to the simulator having the ANGEL and DEMON monitors built-in. All attempts to remove these from the simulator have failed.
I am having problems with Insight not wanting to run reliably It appears to be due to the wrong libraries being linked into the source. I have downloaded the latest cygwin install stuff but cannot replace the old stuff as bash then fails to run. I am currently trying to install the libs into a separate directory and then to link them separately. These problems appear to be due to the hell of DLLs. Bash tools fail with the latest cygwin1.dll, but the a new bash cannot be built without access to the new libs and DLL but they cause the old bash to fail, catch 22. Maybe I will have to purchase a copy of cygwin1.0 to remove the problem.
Building the new version of Insight-GDB has shown a number of problems with the makefiles. The new stuff has sections for all-gdbtk where the $srcdir should have been $(srcdir) to ensure that the directories are correct. Also the link destination file gdbtcl already exists and then the link operation fails. By changing both these the build succeeds.
The current build of binutils generates an LD file that fails building the egcs compiler, copying the old LD file across fixes this problem. Will wait for the next snapshot of the binutils before having a look at the problem.
The latest GDB source snapshot build without problem, as does the egcs snapshot. This needs to be tested before it is OK.
Have now signed up with BTInternet so will be transferring my web site across to BT as this gives me unlimited web space so I can put up the builds of the GNU tools that I am currently doing for others to use. In particular the Insight-GDB system that I am using.
Finally got my new web pages up and running along with a new web counter that should allow me to see how many visits I get. I have also uploaded a re-director to my U-net pages to transfer visitors here. This coming weekend I should be able to get the GNU toolsets I have been building up onto my web site, at the very least Insight-GDB should go up.
Problems with the cross-arm download file. It would appear that it did not get onto the web page intact. I have withdrawn it until I can reload it onto the page over the weekend. I must remember to check the uploaded files to ensure they get up OK.
Over the weekend I will also attempt to get the Insight stuff tested and onto the web page. Hopefully on Sunday I will have time to sort this out.
The problems with the cross-arm file now sorted. The file is now available for download. The problems were due to the web server not accepting the file in one go and the resume was emptying the contents of the file already uploaded. Did the upload at 5am this morning and it has gone up without problem, must be a loading problem with my ISP.
Have removed the doc dependency in the egcs/GCC/makefile for cross-GCC target. This allows the compile to complete.
Have also rebuilt the cygwin1.dll from the latest sources (16/3/00) so that I can now try to debug some problems with Insight. There has been an e-mail conversation with CYGNUS and Fernando Nasser about the select call in the comms code. I will be trying to debug this code to send the results back to CYGNUS.
Have now got the problem with cygwin1.dll sorted. Chris Faylor from CYGNUS has been helping and rebuilding the cygwin with a patch from him has sorted out the problem. The cause of the problem is an array getting damaged because its not being defined correctly. By changing the definition to a fixed max length the problem has gone away. I need to do some more tests for Chris but will now be able to put a copy of insight onto my web page as a pre-built binary for win NT
The Insight.tar.bz2 file has been upload to my download section. I have downloaded the file to check that it will unpack correctly. This file includes the copy of cygwin1.dll that I built to get round the problems with serial downloads to the Angel debugger.
Have rebuilt the latest sources for the GNU toolset. However, egcs will still not rebuild with the latest binutils. Also the configure has put the GCC tree under liberty, moving the tree out to the main egcs directory allows the GCC to remake. Still need to get the install to work, will try it after compile finishes.
Done tests for Chris Faylor @ CYGNUS and mailed him results.
Have now changed to the latest net release of the CYGNUS toolset. Big problems running my make files to generate the toolset for the ARM processor. The remembered that the makefile has to be in UNIX format not DOS format with CR/LF. Converted make file and are now trying to rebuild the tools. Have to re-config the tools first as all the include files and other misc. files are now in different places so cannot run make files until after a ./configure.
Have just rebuilt the current sources for Insight, GDB, Binutils and EGCS. However, in order to build EGCS a download and build of autoconf was required. Also the current release of Binutils will not allow EGCS to build as LD fails with an internal error, copying across an old version of ld.exe from 1999 (actually the ecos version from my website) allows the build to complete. Must get round to building a release bzip and then uploading to my site.
Major problems with heat and what appears to be a failing hard disk have prevented me from building versions of the toolset over the past 2 months. Have, however, been looking at a sourceforge project on JTAG debugging for the ARM processor that will allow me to get code onto the EB01 and run it independent of Insight. This project will eventually be part of GDB according to the author, it can be found at http://sourceforge.net/projects/gdbice/ .
Have also today sent off the ARM board that I have been working on as I will be needing it for my MSc. Project.
Have spent all day working on the JTAG debug stuff for the ARM, using my Programmable logic programmer code. Have got the wiggler software running on my laptop by turning off the ECP port and making it a normal parallel port. Have got JTAG getting the ID and starting to get the other bits of code running. Had problems with the reset on the EB01 development board and ended up modding the board. Still have problems with the NT version of my JTAG code as it needs direct access to the hardware presently.
Got board back from PCB-POOL last week and have now got it up and running. Currently only has the processor and oscillator on the board, still waiting for the other chips.
Now have got the full regs download code into the JTAG code but is not yet tested. Next step will be to restore the registers and then to start code running. The JTAG stuff need to allow the changing of registers and then to get the reading and writing of memory working. At this point it will allow me to send code across to the ARM board without the need of the Flash working. Currently GD Technik are trying to get me a sample of the Hitachi SRAM chip I need for the ARM board and ANGLIA are trying to get me an alternative Flash part. The ST M29W160 has the same pinout as the SST part originally n the design.
The latest source code for the GNU toolset have been produced and probably need to be bzipped up and placed on the website for all to use. Each week I download the latest patches and apply them to my source tree. The sources are then built for the binutils, egcs, GDB and insight, all to run under the latest net release of cygwin under NT.
Have uploaded the latest Insight snapshot and it can be found on the download pages.
Have created a new AT-GNU.ZIP file with all the files in UNIX format with only lf and not cr-lf. Also have discovered that the old toolset on the web site does not work under the new cygwin net release. I am currently trying to build a new release to put up on the web site that will function under the latest net release.
I will build a new entry into the makefile so that I can build a binary distribution easily.
Have uploaded the new files and created the entry in the makefile to enable updating of the files on the web.
Have now got NT version of the JTAG stuff working. I have used a copy of printio.sys to allow me access to the printer port I/O registers and this has allowed the code to work. At least I can now use my NT machine to develop the code and not have to suffer the laptop and win95.
Still haven't got round to updating the at-gnu.zip code as there are currently some files missing from the latest zip. I need to build a method of generating the zip file automatically to make life easier.
Have now built the latest at-gnu.zip with the missing files to allow anyone to rebuild the EB01 examples.
Have had a number of comments from other users of my toolset that code built with it does not run under GDB. Investigation by one user has shown that the branch addresses have been corrupted and are 0x1000002 byte to many. It is as if the Linker has not been linking the files correctly. As part of the investigation I got the latest binutils from Cygnus 18/11/00. These have been built and they appear to work according to objdump that now shows the right addresses being linked. I am currently reconfiguring my binutils source tree to see if this will cure my problem. If not I will known it is my current tree and so will get the latest weekly snapshot on Wednesday and start my tree again.
As part of the investigation I got a full copy of the latest GCC sources and have compiled them to run under cygwin. During this time I have found a number of bugs in the build process. Firstly the exxext macro is not being passed into gcc/fixinc or gcc/f so the build function makefile.in in fix inc and make-lang.in have been altered. Also in make-lang.in the intdoc dependent does not have exeext on the end of the object or the exe file, this has been fixed.
I am going to remove the current release of the toolset from this website so that I can put up this tested version that currently seems to function.
Have got the latest sources for the GNU Toolset, built a complete new version of the code and got ready to send it to the Web site for all to use. Tried to build a copy of the EB01 examples led_blink but could not get it to run under ANGEL using either GDB or Insight. Tried to rebuild newlib but one of the files complains about using pointers in a case statement. Then I realised that the newlib stuff should be copied into the gcc tree and then the command line --with-newlib used to rebuild the library. This is currently reconfiguring so that a build can be attempted. This also means that the current release of the toolset will be delayed until I have proven that this code works.
I am also about to change the downloads page so that the information is presented better as it is currently a bit jumbled.
SRAM chips arrived from Silicon Concepts for the prototype ARM system. Hopefully at the week end the last of the missing chips can be placed on my ARM board, then I just need to get the Motherboard laid out so that I can use my EPROM emulators with the ARM board to get some code running. Need to start thinking about how the bootstrap code is going to work.
The latest newlib source code is available and will be downloaded to see if this fixes the problems I have been having getting the led_blink example code running on my EB01.
Have finally built a copy of the toolset that works and gives me the led_blink example in the at-gnu.zip code that runs on my EB01. This has been packaged up and is currently being uploaded to the web site. The latest newlib has been added to my system and it compiles without a problem. This is what has allowed the examples to now run. It appears that the library's have to be built with the GCC and BINUTILS that use the libraries or else the libraries crash. Now that I have this sorted out I an continue to rebuild the latest snapshots each week when they become available. The methods of copying the newlib code into the gcc tree are not required, it just needs to be built with the latest toolset before the toolset can be used as a whole. I had not been recompiling the library source after each snapshot was downloaded.
Have put the SRAM part onto my ARM board, and have just got the first test program running out of the internal RAM within the ARM processor, even got flashing lights to show it working. Now I can start getting code running on my board. I am using the Wriggler and the Macraigor OCD software to load in the software and to start and debug the code. Once you get the hang of the software it is fairly easy to get the software to do as required.
Have been rebuilding the latest GCC and it stops with an error in the fastjar/jartool.c file. This shouldn't be compiled as I only ask for the files for the c and c++ compilers, there must be a problem with the configuration of the build now the Java stuff has been incorporated. Not a problem as the c has already been installed by this point. So the sources from the 18/12/00 build OK.
One of the newsgroups showed a new site that has pre-compiled binaries for the GNU toolset from Macraigor, the Wiggler JTAG people. They have binaries for the GDB/Insight that support the wiggler connected to the parallel port. I have downloaded the tools and put them on my laptop running win95. The Insight works but does not allow the target selection of the Wiggler without resorting to the command window. I have modified the targetselection.itb file so that the wiggler can now be picked from the target selection box without resorting to the command window. This all runs without a problem on my win95 laptop. I am currently running a test program on my ARM processor board and using the wiggler to run and load the code. It won't however run on my NT box, it complained about not being able to use a DMA channel.
Have been playing with the code that Macraigors sent me for the wiggler changes to the Insight stuff. Have finnaly got them to compile but they won't talk to the wiggle itself due to the lpt port problems under NT. There must be a something done by the installer of the Maccraigor toolset as it works without a problem. Will email them to find out what it is they do.
Have now got a re-mapper for the flash and sram programmed into the ARM board of mine. It merely rempas the chip select lines so that I can use the SRAM for programs. A programmer has been written, there are two versions, the first runs in the internal ram whe the flash is empty of corrupted so that the re-mapper can be put back into the flash. The second runs from the re-mapped ram and allows the flash to be re-written. All this has be done from the Macraigor wiggler toolset and insight. I now have a development board that functions and does not need emulators for the rom space. I used the Macraigors OCD program to single step the Flash code to ensure that it worked and to get the bootup sequence correct.
Got the weekly patches for the toolset last week and again this week and have hit the same problem. The build complains about missing windows.h. Have been through and the files are in the w32api sub-dir of the includes. Have copied the files into the include and modified the winnt.h file to remove an #ifndef VOID selection in order to get the program to re-build.
On other fronts I have now got an RS232 inteface formy ARM micro board. The board consists of an ATMEL AT91M40400 with flash and static ram on-board and pins to take all the signals of board. I have built a small test board that it plugs into and have put an RS232 port on the board. This works and I test code to show it working. So now I have a full development system into which I should now be able to get my operating system ported. Some of the porting has alrady taken place but there is still all the task switching to get functional, that has not been completly debugged yet. I must try and get some pictures and schematics up onto the web pages so others can also build.
I have also discovered that Intel in europe are giving away samples of the StrongARM, I have registered and await the postman to see what, if anything arrives. If samples are forthcoming then I may re-design my ARM board to take a StrongARM, then I can run Linux on it.
The problems with the build of the Toolset continue. have tried re-inatlling the Cygwin tools, but this is still causing problems. Have copied just windows.h into the include directory and now going through all the w32api includes changing any icludes to use the w32api sub-directory. Maybe there is a way of making gcc use a search path for the include files, this would be a neater method but for now this will have to suffice.
Have now got Insight to build correctly, the problems have been with _WIN32 not being defined and so the system building the wrong version of software. Also note that the libtool function generated in some of the subdirectories does not function correctly. Have used the one generated by the GDB source tree last week and that appears to function OK. The bfd and opcodes directories do not get the right build of libtool. It is now compiling and functioning correctly. Cannot get EGCS to function correctly, it won't build with numerous errors. But there was no snapshot this week so will wait until the new snapshot appears next week and then do a great deal of testing next weekend.
Updated the web pages with a hardware section. Also changed the pictures on the main page to one of my own designed hardware, this is the hardware mentioned in this diary. The new page talks about the hardware but the schematics are not yet available, they still need some tweaking to get round the SRAM problems I had with HITACHI and there non-exsistant 1Mx16 SRAM for which they have a datasheet but no parts. I am also looking at the possibility of adding an upgrade card with more RAM and FLASH on board. There is also an Ethernet interface in schematic form but not yet laid out to board.
Have got the sources for the new release of the GCC compiler 2.95.3. This has been building all afternoon along with the binutil and newlib support. I need to test it before putting it up onto the website. I will seperate out the GDB as a seperate download file in order to make life easier for those with small capacity links.
Finally finished v3 of my ATMEL ARM processor board. The PCB layout and schematic are both completed, they should be available from the download section on this web site. The zipped file includes the schematic and board layout in Eagle format, and it should be readable using the free version of the software available from cadsoft. I also have an ethernet board that the micro board plugs into but have not as yet had any made, the schematics and board layout however, do exists as they have been finished today. I have some software to program the flash chip on the micro board but as yet it has not been documented. When the flash program is documented then it will be uploaded onto the downloads page. The flash program comes in two parts, the first runs from internal ram for the situation where the flash is empty or corrupted, the second runs from the SRAM once the flash program has re-mapped the memory. Both versions have been tested using Insight and JTAG debugging using a Maccraigor Wiggler.
Have uploaded a zip file containing the FLASH programmer I am using to update the FLASH on my processor board, hopefully others will find it useful. Also the documentation for the FLASH programmer has been uploaded and the hardware page ahs a link to the documentation. The hardware page has also been modified to have a feature section on the new processor hardware.
I have been trying to compile the latest snapshots of Insight and GDB but it keep failing not built the library files. Checking the make .out file shows that a Microsoft file lib.exe is being run.Checked the paths and found that Visual C was on the search path and so I am assuming that the configure process is picking up the lib.exe fileand then building the make files appropriately. Have now removed lib.exe from the path and trying again to build the latest files. I have a tar.bz2 of the GCC 2.95.3 and binutils 2.11, once they have been tested I will upload for all to enjoy. I am alos looking at seperating out GDB into a seperate directory so that the downloadable files become much smaller. It will also mean that people downloading files will only download the files and tools they want, this is especially true if Insight is being used instead of GDB.
Have been trying to get the latest copies of the toolset to compile. Binutils and GCC have both compiled without an a error but Insight/GDB has not been so easy. Insight failed during the build in the tcl and tk sub-directories. Eventually tracked down to the flags being passed into the makefiles. The configure scripts were not setting the cygwin flags correctly as they were checking for a target of cygwin not a host. This has been changed and patches submitted via Chis Faylor. Now the tcl and tk directories compile OK and the next problem is the final link of GDB whereby there is a problem with 2 functions from gdb/utils.c not being defined, tgetent() and tgetnum().
Now got to the bottom of the functins that change their names after compilation. Ended up using -E instead of -c in the compile line on gdb/utils.c and then found that term.h was defining the missing functions as being in a dll. This meant that GCC changed the function names to __imp__tget*() and so the link failed. Have renamed the term.h file in /usr/include and am now re-configuring and re-building Insight/GDB to see if this will fix the problem. Hopefully, I will then be able to get a working Insight.
Renaming the file allowed the build to finish, unfortuantly a working Insight does not ocour. The source code loads into insight but then the UI stops taking any more input. Will get the latest CVS before trying again and then reporting the problem to the Insight mailing list.
OK so now I have the answer to the lack of dialog boxes. Ian Roxborough has been trying to track down the problem and has sent me the following 2 patches. When applied to the right files the system now runs and will simulate code.
>P.S.: This is my fix for the modal dialog problem, I'll formally submit it once I've got the
>crashing problem solved. Index: managedwin.itb
>RCS file: /cvs/src/src/gdb/gdbtk/library/managedwin.itb,v retrieving revision 1.17 diff-r1.17
>managedwin.itb 258c258 < wm transient $top . --- > wm transient $top [winfo toplevel
>[namespace tail [lindex [ManagedWin::find SrcWin] 0]]]
>In the "ModalDialog::post" method in modal.tcl you need to change the line at the end of
>the method (~line 100) which reads:
>::delete object $this
>wm withdraw [winfo toplevel >[namespace tail $this]]
Now I need to get the latest cvs of the GCC and Binutils and re-build those.
The latest GCC will not build correctly. I get a segfault within the fix-headers.exe code. Changed the fixproto command file to print out the lines calling fix-headers (line 275) and that got the command that was causing the failure. Then eventualy after some mail list discussion modifed gcc/gcc/cppfiles.c function open_file to print out the files that it was opening. this shows that the dirent.h files are including them selevs and therefore getting into a recursive loop. Have now modified the last of the included files to remove the include of the base file and now the segfault no longer happens. Will send an email off to the mail list to give the answer in case anyone else has the same problem.
GCC has now re-built OK.
Curent CVS builds for all the toolset and insight. Now making the config makefile entry for newlib and proving it.
Problems building gcc for the ARM processor under cygwin under win2k. The build was failing on the temp file that existed and also had the filetype .exe on the end. The install script did not have the .exe appended to it and this caused the istall to fail. Changed the line in gcc/install-sh to read:
and the problem has gone away and the install completes. Now all the parts except the newlib stuff is building correctly. Still can't get the newlib to build but this is probably due to an install issue where newlib is not in the right part of the source tree.
Have also been working on a program to interface between GDB and the wiggler JTAG port. Currently have got GDB talking to my code using TCP connections and also got the code talking to the wiggler hardware and an AT91 ARM. Can load code into the ARM and run it. Can also read from the memory and get register values from the ARM. Still need to implement single step and breakpoints and then I will have a fully functional GDB-JTAG interface ad I can upload it to the web site for others to use. Now I have a new PC this code should not take very long to get finished, but we have to move house first.
Long time and no progress report, so here it is. I had been working on a GDB - JTAG interface and then someone pointed out that Macraigor ahd released one. The good news is that it works, but not on my Dual ATHLON machine. Instead I run it on the laptop (a P133) and then connect via TCP/IP from my main machine. This has enabled me to start on RedBoot. As of tonight I now have RedBoot RAM running on my hardware. I can also switch to debug mode and use Insight via a serial RDI connection onto the target hardware. I have to say that the JTAG is very very slow < 1kbits per second. But then I am using a parrallel port wiggler. My new plan is to get RedBoot into the flash on my hardware and then I can use the serial GDB to get eCos up and running. I also want to get an ethernet interface working on my hardware and a compact flash adapter. Big progress at last.
I am now looking at my flash programmer to add some more intelligent reporting about what it is doing and then will put RedBoot into the data area so that I can then program RedBoot into flash.
Also finally got newlib building and also the other libraries required by eCos and RedBoot.
Now got the flash programmer working with a serial output so that it can be seen working. The next job is to create a RedBoot flash file so that RedBoot can be put into the flash to run at start-up. This will have its own program file so that the whole of the RedBoot and flash programmer can be built from source using the makefile. It also means that one distributible file holds the programmer and the RedBoot file for the processor. Need to look at creating a ROM-RAM RedBoot and then will look at creating a seperate target for my board as opposed to using the EB01 target.
Finally got RedBoot running from RAM. The problem is that being my hardware the I/O was not setup with my small stub so that the uart was controlling the output pins, if I ran the flash programmer first that would set up the uart output and then RedBoot would work. Have set up my main makefile to create a RedBoot ram and rom varient and have also built a new version of the flash programmer that contains the RedBoot rom varient. This has been programmed into falsh and now my board starts up with RedBoot.
I did have some problems with RedBoot and had to modify the linker script so that the RedBoot was linked at 0 and not with an offset as per the ATMEL EB01 code. I will need to create a new target for my board at some point, but I need to wait for the revised AT91 source tree before doing to much work. I also had to change the memory setup to suit my chips.
I now have a board that is running RedBoot at start-up and so I can now start to look at eCos in whole and maybe the ethernet card I designed some time ago. RedBoot is recognizing the lack of ATMEL flash when booting and is complaining and shutting down the driver, so I need to look at the flash driver and determine how to ensure the correct driver is installed.
Unfortunately last night I managed blow up my AT91 processor whilst trying to get the redboot comms running and a set of new serial ports added on a new slave board. I made the mistake of soldering whilst the system was powered up, an extremely stupid beginners trick. I have managed to take the old processor of the board without to much damage so hopefully with a new processor chip I should be able to get up and running again. I do have redboot running on the ROM and communicating with Insight, but have not yet got the flash driver working. This should only be a small change in the flash driver to recognise the flash chip I am using.
I have also uploaded a new version of my flash programmer and this version contains the program that flashes redbot into the base of the ROM.
Have now re-built the toolset to get it up to date. Encountered 2 problems, the first was gcc not installing correctly under CYGWIN due to a missing .exe suffix on a file copy. So gcc/gcc/makefile.in was modified to add $(exeext) to the filename of fixincl when it is being installed in the intsall-mkheaders target. Also modified strerror.c and strsignal.c in gcc/libiberty to remove libiberty.h as an include from these files as it was causing a problem when compiling the files with the cross compiler when building the libraries.
Also have ordered another PCB yesterday to replace my processor board that I managed to blow up. That should be with me in 2 weeks time and then I will get hold of some AT91 processors to go on the board.
The new PCB arrived 4 days early and this morning I receieved 2 new AT91M40800 to populate the PCB. I now have a working processor just need to add the RAM and FLASH and I should be back working again. I also need to check to see if the 40800 has got any different registers from the 40400 I was using before.At least I should be able to get RedBoot running n it again and then can look at the flash side of it.
Have just finished the new board and now have RedBoot running on my new hardware. The RedBoot is as per my last board without any changes. The next job is finish putting the connectors on the board and then to get the flash recognised by RedBoot.
Completed the modifications to the eCos source tree to add the APS01 processor board (my processor board) to the tree. Can now use the eCos config tools to create a version of RedBoot specifically for the APS01 processor card. I am now looking at addig support for the SST flash chips I use into the eCos tree so that the flash drivers for RedBoot will function. This will involve the adding of the SST parts to the flash drivers list and also adding the APS01 to the arm portion of the devs/flash tree. I will use the example of the eb40a development card as a model to get the structure correct. This may take a while to get the flash functional but at least it is easier now RedBoot and Insight communicate across the serial port, I can use a RAm version of the new RedBoot under the ROM version and debug it this way.
I have added the RedBoot make commands for both the config and make steps into my main makefile, this is the one that I use to get the cvs updates and to build the GNU toolset for my machine. It makes creating files much easier and repeatable, I don't have to remember all the steps I take to create the files they are all written down and thus can be emailed to interested parties.
Have now completed the SST flash drivers and now my RAM version of RedBoot recognises the SST flash on my board. Now need to complete the deal by producing a ROM version of the code and blowing that code into the on-board flash.
Tested the SST flash drivers and produced a ROM versio of RedBoot. I now have a fully functional RedBoot capable of placing code into the flash. Looking at the flash programming code there is a verify piece of code that cannot work due to a size having been set to 0 during the programming cycle. I need to look at this problem and fix it for the release version.
Previous versions of RedBoot have only allowed the flash filing system to write the flash. Have now implemented al of the fis commands so that files can be saved to flash and then loaded again before running. This has been achieved by turning on the CYGOPT_REDBOOT_FIS option within the reboot_*.ecm files within the hal for the APS01. Also modified was the start-up configuration of the APS01 so that the flash is now 16MB is size rather than only 1 which gave bus errors when accessing the fis commands and accessing flash that was not mapped into the memory map of the processor.
The new versions of RedBoot and my flash programmer have not yet been put up onto the web site, I need to do this.
Have just finished the first version of the test software to prove my new network card for the ARM processor card. The test software displays the registers of the cs8900 and then initialises the chip before looping looking for incoming packets. It currently deals with ARP requests and also pings. Testing with a win2k host shows that it responds to pings within 10mS normally 1 in 4 responses drift to 15mS. This indicates that the hardware now functions and that I am ready to get RedBoot to start using the network port. I will put the schematics and board layouts up on the web site as soon as I have finalised the drawings. Also the test software for anyone else following in my footsteps will be here.
Just got RedBoot with network support working on my new hardware. Still don't have the network interrupts running yet but that will also mean that eCos will need to be brought up. Turns out that the only thing that needed setting up was the gap between registers (called step in the RedBoot network sources). Also I needed to build the GCC3.2.1 toolset in order to be aboe to build RedBoot and have it work. The version of GCC that I had previously used for RedBoot did not like the I/O to the network card, but to be fair it did not work completely on the test code, I had some extra code to make the calls into the hardware work. Changing to 3.2.1 made these additions removeable. Now I need to look at how I get IP addresses into RedBoot and the role of the startup file required to make this easy. I do not have a bootp server on my system to pass an IP address across to RedBoot. Probably need to look at getting a bootp server running on my main machine jsut to make life a little easier. Even managed to telnet into the ARM processor board.
Now have got the ROM version of RedBoot running on my hardware and put in the flash so I can now connect via the network to my processor board. I also am runing a bootp server on my man development machine to supply RedBoot with an address. Next I need to look at the DHCP stuff that is currently being developed for RedBoot, so I can get rid of the bootp server. I also need to start looking at packaing up my mods to the eCos tree so that I can publish them on my web site particularly as my copyright assignments seem to have gone astray on their way to Redhat.
A couple of other issues are to look at how I can auto-detect the address of my network board and get the address passed into the RedBoot system, the code to do this already exists in my test software but I haven't got to putting it into RedBoot yet. I need to get the schematics for the network card up onto this site so that others can use the design, particularly as I have found out tonight that someone else has built some of my hardware.I also need to update my eCos tree with the latest CVS, to take advantage of the latest patches.
Spent the Christmas holidays working on a remote JTAG adapter. This connects to the JTAG debug software that I had written to talk to the MacCraigor wiggler, it never worked on my dual athlon box but did function on a laptop. So added an AVR to sit between a serial port and the JTAG lines from my ARM. I now can access the ID and debug registers of the ARM processor, the intention is to replace the serial conection with a USB connection and then to update the PC software so that the code I wrote to talk to GDB/Insight will use the new comms and allow debugging on the target hardware. Currently the system is a little slow across a serial link (even at 38400) and the comms protocol is currently a little flakey (it drops messages every now and then). I may actually get to turn it into a real product one day.
Also I had a quick look at uCLinux running on ARM7. Got the CVS installed on my win2k box and started a compile. It got all the way to linking and then barfed telling me that it needed soft floating point and the gcc library was compiled with hard floating point.This appears to be a problem with the toolset and I need to get the libraries compiled with the soft float marked, it is not easy and there a large number of scripts to create the appropriate toolset, but they are all for running under Linux and I am using cygwin, I need to find a method of generating the toolset. I will take one of these scripts and twist it into my build system. I don't want to use a pre-built toolset as then I can't track the tools changes and build my own toolset, plus most pre-built toolsets use Linux and I need to stay with win2k.
I have also uploaded the schematic and board layout for my ethernet board, that can be found on the downloads page.
Have now got uClinux compiling, had to add the following to the top level make file so that it would ignore the soft and hard floating point mismatch in the compiler and Linux.
$(LINUX): include/linux/version.h $(CONFIGURATION) init/main.o init/version.o
$(LD) $(LINKFLAGS) --no-warn-mismatch $(HEAD) init/main.o init/version.o init/do_mounts.o \
The extra bit is the ' --no-warn-mismatch ' and originally came from an email from Russell King. Now all I need to do is produce a RAM version so that I can test it.