Menu
▾
▴
blob README,1.1.1.1.2.1,1.1.1.1.2.2
|
From: Erik M. <er...@us...> - 2001-07-17 14:19:46
|
Update of /cvsroot/blob/blob
In directory usw-pr-cvs1:/tmp/cvs-serv12242
Modified Files:
Tag: blob_1_0_9_hack
README
Log Message:
- updated documentation
- added a blob porting guide
Index: README
===================================================================
RCS file: /cvsroot/blob/blob/README,v
retrieving revision 1.1.1.1.2.1
retrieving revision 1.1.1.1.2.2
diff -u -r1.1.1.1.2.1 -r1.1.1.1.2.2
--- README 2001/07/07 19:24:39 1.1.1.1.2.1
+++ README 2001/07/17 14:19:43 1.1.1.1.2.2
@@ -18,20 +18,44 @@
other people also contributed to blob.
Blob started its life as a boot loader for the LART, but nowadays it
-has been ported to the Intel Assabet SA-1110 evaluation platform by
-Jeff Sutherland and Chester, to the Intel Brutus SA-1100 evaluation
-platform by Erik Mouw, and to the PLEB Linux board by Adam Wiggins.
+has been ported to the Intel Assabet SA-1110 evaluation platform, the
+Intel Brutus SA-1100 evaluation platform, the PLEB board, the Nesa
+board, the TuxScreen (aka Shannon), and to the CreditLART board.
+** Where is the latest blob source available?
+---------------------------------------------
+
+The latest and greatest blob source is available from SourceForge, see
+http://www.sourceforge.net/projects/blob/ . The latest source is
+available from anonymous CVS. First log in to the CVS server:
+
+ cvs -d:pserver:ano...@cv...:/cvsroot/blob login
+
+There is no password, so just press enter. Now check out the blob source:
+
+ cvs -z3 -d:pserver:ano...@cv...:/cvsroot/blob co blob
+
+If you're using the blob CVS source, it's a good idea to subscribe to
+the blob-cvs-commit mailing list so you know about blob patches. See
+http://lists.sourceforge.net/lists/listinfo/blob-cvs-commit . The
+general blob discussion is done on the LART mailing list, see
+http://www.lart.tudelft.nl/list/ for more information.
+
+Blob also has a home page: http://www.lart.tudelft.nl/lartware/blob/ .
+
+
+
+
** So what is LART?
-------------------
LART is the Linux Advanced Radio Terminal, a small low power computing
-element used in the MMC project and the Ubiquitous Communications
-programme (see http://www.lart.tudelft.nl, http://www.mmc.tudelft.nl/ ,
-and http://www.ubicom.tudelft.nl/).
+element used in the MMC project and the Ubiquitous Communications
+programme (see http://www.lart.tudelft.nl, http://www.mmc.tudelft.nl,
+and http://www.ubicom.tudelft.nl ).
LART features:
@@ -85,9 +109,9 @@
- Run "./configure --with-linux-prefix=/path/to/armlinux/source \
--with-board=boardname arm-lart-linux-gnu"
- There are currently four valid board names, choose from: assabet,
- brutus, lart, or pleb. If the board name is ommited, lart will be
- choosen as a default.
+ There are currently a couple of valid board names, choose from:
+ assabet, brutus, creditlart, lart, nesa, pleb, or shannon. If the
+ board name is ommited, lart will be chosen as a default.
If you want to do some serious hacking on blob, consider using the
"--enable-maintainer-mode" flag. This will automatically regenerate
@@ -102,12 +126,12 @@
- Run "./configure --with-board=boardname"
- Run "make"
-
-The binary image is in src/blob, src/blob-elf32 is the image with
-complete ELF headers. To disassemble "blob-elf32", use:
+The binary image is in src/blob, src/blob-start-elf32 and
+src/blob-rest-elf32 are the two parts of the images with complete ELF
+headers. To disassemble "blob-start-elf32", use:
- objdump --disassemble-all blob-elf32
+ arm-linux-objdump -D -S blob-start-elf32
To see the actual hex codes of blob, use:
@@ -121,12 +145,24 @@
*** LART
--------
+
+The current wisdom to install blob on a LART is:
-Use whatever tool you need to download the blob image (src/blob) at
-address 0x00000000 of your SA-1100 target. The LART project currently
-uses the following wisdom to install blob:
+- Connect the JTAG dongle to the LART
+- Connect the other end of the JTAG dongle to the parallel port of
+ your PC
+- Power up the LART
+- Use the jflash utility (available from the LART web site) to write
+ blob (you usually need to be root for this): jflash blob
+The JTAG flash burn code however is now worked out as a set of Linux
+executables provided by the JTAG flash project located at the LART page
+as well as JTAG executables ported to support the TuxScreen screen phone.
+
+The LART project initially used the following wisdom to install blob:
+
Required hardware & software:
+
- The LART itself with 4 Mbyte flash memory
- An external 128 kbyte flash board
- A PCI 7200 (???) digital I/O card with a Linux driver
@@ -136,7 +172,7 @@
written into the flash memory using the flash burn program. The
external flash board is connected to the LART low speed interface. The
external flash chip is mapped at address 0x00000000, and the internal
-flash is remapped at 0x08000000. As soon as the LART boots, the
+flash is re-mapped at 0x08000000. As soon as the LART boots, the
external flash is copied to the first 128 kbyte of the internal
flash. The next time the LART is started without external flash board,
it starts from its internal flash which now contains the just
@@ -149,9 +185,6 @@
we say more?). To meet a deadline, we decided to make a special board
with 128 kbyte external flash memory (and an LCD interface).
-The JTAG flash burn code however is now worked out as a set of Linux
-executables provided by the jtag flash project located at the LART page
-as well as JTAG executables ported to support the TuxScreen screen phone.
*** Assabet
-----------
@@ -166,21 +199,9 @@
*** SHANNON (TuxScreen phone)
-----------
-
-Try these steps for use on a tuxscreen. Replace /usr/src/linux with the
-location of your arm linux kernel sources that you will be running on the
-tuxscreen:
-
-If you got the sources from CVS you will need to do:
-
-tools/rebuild-gcc && tools/rebuild-gcc
-
-(Yes, twice) Then do:
-
-CC=arm-linux-gcc ./configure --with-linux-prefix=/usr/src/linux \
- --enable-maintainer-mode --with-board=shannon arm-linux
-make
+The idea is to write the SHANNON flash via the jflash utility in much
+the same way as you would do it on LART or Assabet.
** Making a distribution
@@ -263,8 +284,6 @@
* status Display current status
-
-
*** "boot"
----------
@@ -282,8 +301,6 @@
...
-
-
*** "clock"
-----------
@@ -301,8 +318,6 @@
say that we didn't warn you!
-
-
*** "download"
--------------
@@ -342,8 +357,6 @@
command.
-
-
*** "flash"
-----------
@@ -352,14 +365,12 @@
with:
blob> flash kernel
- Saving kernel to flash ..... .................... done
+ Saving kernel to flash ..... .... done
-Currently this command only works when blob is started from the
-external flash board.
+Currently this command only works for LART, we are working on support
+for the other architectures.
-
-
*** "reload"
------------
@@ -373,8 +384,6 @@
The "reload command" will overwrite a just downloaded a kernel or ramdisk.
-
-
*** "reset"
-----------
@@ -383,8 +392,6 @@
emulator back to 9600 baud after downloading a kernel or ramdisk.
-
-
*** "speed"
-----------
@@ -396,8 +403,6 @@
Download speed set to 19200 baud
-
-
*** "status"
------------
@@ -414,3 +419,168 @@
Depending on what commands you used before, these values may or may
not be different.
+
+
+
+
+* Porting blob
+==============
+
+Porting blob to a new SA11x0 platform is quite easy and consist of
+four steps:
+
+1. Define the features of the architecture
+2. Write some architecture specific code
+3. Test the new architecture
+4. Submit the patch
+
+The next couple of paragraphs describe the process of porting blob to
+the "foobar" platform.
+
+
+** Define the architecture in configure.in
+------------------------------------------
+
+First you need two know a couple of things: the name of the board,
+what kind of CPU the board uses (SA1100 or SA1110), what kind of RAM
+it uses (EDODRAM or SDRAM), and which serial port will be the console
+(port 1 or 3). Let's assume the foobar platform has an SA1100 CPU,
+uses EDODRAM, and serial port 1 as console. The correct lines for
+configure.in will be:
+
+ foobar)
+ AC_MSG_RESULT(foobar)
+ AC_DEFINE(FOOBAR)
+ AC_DEFINE(USE_SA1100)
+ AC_DEFINE(USE_EDODRAM)
+ AC_DEFINE(USE_SERIAL1)
+ ;;
+
+Put this just after the CreditLART definition.
+
+
+** Define the architecture in acconfig.h
+----------------------------------------
+
+Because configure.in was instructed to define FOOBAR for the foobar
+platform, we have to define the symbol in acconfig.h as well. Add the
+following two lines to acconfig.h, just after the CLART define:
+
+ /* Define for foobar boards */
+ #undef FOOBAR
+
+
+** Update the build system
+--------------------------
+
+Run the following commands to update the configure script,
+include/config.h.in, and the Makefile.in files:
+
+ tools/rebuild-gcc
+ tools/rebuild-gcc
+
+(yes, twice)
+
+
+** Configure blob
+-----------------
+
+Configure blob for the new foobar architecture:
+
+ setenv CC arm-linux-gcc
+ ./configure --with-linux-prefix=/path/to/armlinux/source \
+ --with-board=foobar --enable-maintainer-mode \
+ --enable-blob-debug arm-unknown-linux-gnu
+
+We're using maintainer-mode and debug information to help the
+port. See the section about "Configuring and compiling the package"
+for general information.
+
+
+** Select correct clock speed
+-----------------------------
+
+Open src/start.S in an editor, and add a line to select the correct
+clock speed (just before the SHANNON definition):
+
+ #if defined FOOBAR
+ cpuspeed: .long 0x09 /* 190 MHz */
+
+
+** Edit memory settings
+-----------------------
+
+Edit src/memsetup.c and add the correct memory setting for the foobar
+architecture. Add these (example) settings right before the PLEB
+definitions:
+
+ #if defined FOOBAR
+ mdcas0: .long 0x1c71c01f
+ mdcas1: .long 0xff1c71c7
+ mdcas2: .long 0xffffffff
+ mdcnfg: .long 0x0334b21f
+ #endif
+
+Note that the SA1110 memory settings are not as modular as the SA1100
+settings, so you'll have to use your imagination over there to get
+proper memory settings.
+
+Right now, the basic blob functionality is ported to your board and
+you should be able to compile blob by running "make".
+
+
+** Edit LED defines
+-------------------
+
+If your board has a LED on a GPIO pin, edit src/ledasm.S in an editor
+to switch it on early in the boot stage. Let's assume the foobar board
+has the LED on GPIO pin 1, so add the following lines just before the
+PLEB definition:
+
+ #elif defined FOOBAR
+ LED: .long 0x00000002
+
+
+** Compile blob
+---------------
+
+Now compile blob by running:
+
+ make
+
+If everything went right, you have a new blob binary in src/blob.
+
+
+** Test blob
+------------
+
+You are now ready to flash blob to your board and test it. If
+something goes wrong in the early boot process, blob will flash the
+LED (that's why you should always have a LED on your board), or not
+work at all. As soon as you get character on the serial port the most
+difficult part is done and you should be ready to port arm-linux to
+your board.
+
+
+** Submit the patch
+-------------------
+
+First run "make distclean" in your blob tree so you'll get a clean
+source tree. Now rename your current tree and untar the original blob
+source (assuming that you're hacking on blob-2.0.3):
+
+ cd ..
+ mv blob-2.0.3 blob-2.0.3-foobar
+ gzip -dc blob-2.0.3.tar.gz | tar xvf -
+
+Diff the two trees and create a patch file:
+
+ diff -urN blob-2.0.3 blob-2.0.3-foobar > foobar.diff
+
+Now send the patch to me (er...@us...) and be sure to
+CC a couple of other blob developers (for the current list of blob
+developers, see
+https://sourceforge.net/project/memberlist.php?group_id=30155 ). The
+best way to send the patch is to attach it as plain text to your
+message because in that way email clients have less chance to corrupt
+the patch.
|
