blob-cvs-commit — blob CVS commit messages list

CVS: blob configure.in,1.37,1.38

[Erik M. <er...@us...>]

Update of /cvsroot/blob/blob
In directory usw-pr-cvs1:/tmp/cvs-serv11717

Modified Files:
	configure.in 
Log Message:
Add a directory for the commands. The idea is to have a single file per
command so the linker will automatically link in the correct object files
from libcommands.a.


Index: configure.in
===================================================================
RCS file: /cvsroot/blob/blob/configure.in,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -d -r1.37 -r1.38
--- configure.in	2002/01/29 16:27:42	1.37
+++ configure.in	2002/01/29 17:47:23	1.38
@@ -479,6 +479,7 @@
 include/blob/arch/Makefile
 src/Makefile
 src/blob/Makefile
+src/commands/Makefile
 src/diag/Makefile
 src/lib/Makefile
 tools/Makefile

CVS: blob/src/diag Makefile.am,1.7,1.8

[Erik M. <er...@us...>]

Update of /cvsroot/blob/blob/src/diag
In directory usw-pr-cvs1:/tmp/cvs-serv1769/src/diag

Modified Files:
	Makefile.am 
Log Message:
Generate link map file.


Index: Makefile.am
===================================================================
RCS file: /cvsroot/blob/blob/src/diag/Makefile.am,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- Makefile.am	2002/01/07 17:04:02	1.7
+++ Makefile.am	2002/01/29 17:08:21	1.8
@@ -64,7 +64,8 @@
 	ld-script
 
 diag_elf32_LDFLAGS	+= \
-	-Wl,-T,${srcdir}/ld-script
+	-Wl,-T,${srcdir}/ld-script \
+	-Wl,-Map,diag-elf32.map
 
 
 diag_elf32_LDADD	+= \
@@ -85,7 +86,7 @@
 	ld-script
 
 
-CLEANFILES	= ${srcdir}/*~
+CLEANFILES	= ${srcdir}/*~ *.map
 
 
 DISTCLEANFILES	= ${builddir}/.deps/*.P

CVS: blob/src/blob Makefile.am,1.17,1.18

[Erik M. <er...@us...>]

Update of /cvsroot/blob/blob/src/blob
In directory usw-pr-cvs1:/tmp/cvs-serv1769/src/blob

Modified Files:
	Makefile.am 
Log Message:
Generate link map file.


Index: Makefile.am
===================================================================
RCS file: /cvsroot/blob/blob/src/blob/Makefile.am,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- Makefile.am	2002/01/15 22:52:11	1.17
+++ Makefile.am	2002/01/29 17:08:20	1.18
@@ -70,7 +70,8 @@
 	start-ld-script
 
 blob_start_elf32_LDFLAGS	+= \
-	-Wl,-T,${srcdir}/start-ld-script
+	-Wl,-T,${srcdir}/start-ld-script \
+	-Wl,-Map,blob-start-elf32.map
 
 blob_start_elf32_LDADD	+= \
 	@MEMSETUP@ \
@@ -99,7 +100,8 @@
 	start-ld-script
 
 blob_start_chain_elf32_LDFLAGS	+= \
-	-Wl,-T,${srcdir}/start-ld-script
+	-Wl,-T,${srcdir}/start-ld-script \
+	-Wl,-Map,blob-start-chain-elf32.map
 
 blob_start_chain_elf32_LDADD	+= \
 	-lgcc
@@ -172,7 +174,8 @@
 
 
 blob_rest_elf32_LDFLAGS	+= \
-	-Wl,-T,rest-ld-script
+	-Wl,-T,rest-ld-script \
+	-Wl,-Map,blob-rest-elf32.map
 
 
 blob_rest_elf32_LDADD	+= \
@@ -228,7 +231,7 @@
 	rest-ld-script.in
 
 
-CLEANFILES	= ${srcdir}/*~ rest-ld-script
+CLEANFILES	= ${srcdir}/*~ rest-ld-script *.map
 
 
 DISTCLEANFILES	= ${builddir}/.deps/*.P

Re: Memory settings

[Erik M. <J.A...@it...>]

On Tue, Jan 29, 2002 at 04:47:54PM +0200, Abraham vd Merwe wrote:
> 1. This is actually a general ARM question I guess, but this is probably the
> best list to ask. If you calculate the DRAM settings using the Intel
> configuration thingy (http://appzone.intel.com/hcd/sa1110/memory/index.asp)
> you get values for MDCNFG, SMCNFG, MDREFR, MDCAS00, MDCAS01, MDCAS02, and
> MSC0, but blob also needs MSC1 and MECR. From the SA-1110 datasheet it seems
> these are using for expansion memory, etc. which is optional. Can I just set
> this to anything in blob? (I set it to zero and it seems to work, but I'm
> not sure if this is wise)

If you don't use it, you can set it to anything.

> 2. Also what should I expect to go wrong when my settings don't match the
> processor speed. I worked out above settings for 206.4MHz, but it seems to
> work fine for any clock speed (I tried 59.0MHz and 221.2MHz). Is this safe
> or not?

It's safe as long as the caches are disabled. You'll see strange
lockups when the kernel starts and enables the full MMU tricks cause in
that case you'll get burst access to the RAM which are much more
critical to good timings.

> 3. It seems that if the CPU runs at > 200MHz then the memory is accessed at
> 1/4 of the core cpu speed (for 100MHz SDRAM), but if the CPU runs < 200Mhz
> it is 1/2 the core cpu speed, so at 206.4MHz you get 51.6Mhz, but at
> 191.7MHz you get 95.9MHz ram (almost twice as fast). Isn't it better to run
> the CPU at a bit slower speed then or does the 20 odd Mhz make such a big
> difference (in which case you should be running at 221.2MHz I guess).

Depends on the application. We have a nice paper about that on the
"Clock scaling" page on the LART website.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

CVS: blob configure.in,1.36,1.37 acconfig.h,1.12,1.13

[Erik M. <er...@us...>]

Update of /cvsroot/blob/blob
In directory usw-pr-cvs1:/tmp/cvs-serv21207

Modified Files:
	configure.in acconfig.h 
Log Message:
The configure framework for cramfs and jffs2. Doesn't trigger any extra
compiles, yet.


Index: configure.in
===================================================================
RCS file: /cvsroot/blob/blob/configure.in,v
retrieving revision 1.36
retrieving revision 1.37
diff -u -d -r1.36 -r1.37
--- configure.in	2002/01/12 01:45:57	1.36
+++ configure.in	2002/01/29 16:27:42	1.37
@@ -306,7 +306,17 @@
 [md5_flag=$enable_md5],
 [md5_flag=no])
 
+AC_ARG_ENABLE(jffs2,
+[  --enable-jffs2          Enable support for loading kernel from jffs2],
+[jffs2_flag=$enable_jffs2],
+[jffs2_flag=no])
 
+AC_ARG_ENABLE(cramfs,
+[  --enable-cramfs         Enable support for loading kernel from cramfs],
+[cramfs_flag=$enable_cramfs],
+[cramfs_flag=no])
+
+
 dnl Check if the user wants *all* features
 AC_ARG_ENABLE(all-features,
 [  --enable-all-features   Enable all features],
@@ -319,6 +329,8 @@
 	debug_flag=yes
 	lcd_flag=yes
 	md5_flag=yes
+	jffs2_flag=yes
+	cramfs_flag=yes
 fi
 
 
@@ -372,6 +384,17 @@
         AC_DEFINE(CONFIG_MD5_SUPPORT)
 fi
 
+dnl Check wether or not JFFS2 support is wanted
+if test "x$jffs2_flag" = "xyes" ; then
+	AC_MSG_WARN("JFFS2 support is only dummy code")
+	AC_DEFINE(CONFIG_JFFS2_SUPPORT)
+fi
+
+dnl Check wether or not cramfs support is wanted
+if test "x$cramfs_flag" = "xyes" ; then
+	AC_MSG_WARN("cramfs support is only dummy code")
+	AC_DEFINE(CONFIG_CRAMFS_SUPPORT)
+fi
 
 dnl Check wether or not additional platform source code
 dnl for is needed
@@ -480,5 +503,7 @@
 echo "Debugging commands support  ${debug_flag}"
 echo "LCD support                 ${lcd_flag}"
 echo "MD5 support                 ${md5_flag}"
+echo "JFFS2 support               ${jffs2_flag}"
+echo "cramfs support              ${cramfs_flag}"
 echo "Run-time debug information  ${blob_debug_flag}"
 echo ""

Index: acconfig.h
===================================================================
RCS file: /cvsroot/blob/blob/acconfig.h,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- acconfig.h	2002/01/07 14:58:16	1.12
+++ acconfig.h	2002/01/29 16:27:42	1.13
@@ -53,6 +53,9 @@
 /* Define the board name over here */
 #undef BOARD_NAME
 
+/* Define the CPU type */
+#undef CPU
+
 /* Define to enable run-time debug information */
 #undef BLOB_DEBUG
 
@@ -101,8 +104,11 @@
 /* Define if MD5 support is wanted */
 #undef CONFIG_MD5_SUPPORT
 
-/* Define the CPU type */
-#undef CPU
+/* Define if JFFS2 support is wanted */
+#undef CONFIG_JFFS2_SUPPORT
+
+/* Define if cramfs support is wanted */
+#undef CONFIG_CRAMFS_SUPPORT
 
 @BOTTOM@
 

CVS: blob/src/commands - New directory

[Erik M. <er...@us...>]

Update of /cvsroot/blob/blob/src/commands
In directory usw-pr-cvs1:/tmp/cvs-serv19167/commands

Log Message:
Directory /cvsroot/blob/blob/src/commands added to the repository

Re: Memory test routines in blob

[Abraham vd M. <ab...@2d...>]

Hi Stefan!

> I've not looked at this lately, but consider this: You have to be=20
> careful not running
> into the mem area where blob's stack and code is.
>=20
> I thought I have done this correctly, tough.
>=20
> Could you please validate that there's no code/stack in the area you=20
> test?

I'm using the same locations as with the Assabet board:

#define BLOB_RAM_BASE       (0xc0100000)
#define KERNEL_RAM_BASE     (0xC0008000)
#define PARAM_RAM_BASE      (0xc0110000)
#define RAMDISK_RAM_BASE    (0xC0400000)

> And, what board/configuration do you use? Is memory detected correctly=20
> (i.e
> sizes, adresses etc.)?

At the moment I'm working with a new board/custom board. SA-1110, 2x 32M
SDRAM chips (i.e. 64M total). The memory is detected correctly with
testmem2.S and blob is running fine on it.

I've also tried the chkmem tests on a LART board and I run into the same
problems. With what board did you test with?

--=20

Regards
 Abraham

After 14 non-maintainer releases, I'm the S-Lang non-maintainer.
	-- Ray Dassen

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: ab...@2d...         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Memory settings

[Abraham vd M. <ab...@2d...>]

Hi!

1. This is actually a general ARM question I guess, but this is probably the
best list to ask. If you calculate the DRAM settings using the Intel
configuration thingy (http://appzone.intel.com/hcd/sa1110/memory/index.asp)
you get values for MDCNFG, SMCNFG, MDREFR, MDCAS00, MDCAS01, MDCAS02, and
MSC0, but blob also needs MSC1 and MECR. From the SA-1110 datasheet it seems
these are using for expansion memory, etc. which is optional. Can I just set
this to anything in blob? (I set it to zero and it seems to work, but I'm
not sure if this is wise)

2. Also what should I expect to go wrong when my settings don't match the
processor speed. I worked out above settings for 206.4MHz, but it seems to
work fine for any clock speed (I tried 59.0MHz and 221.2MHz). Is this safe
or not?

3. It seems that if the CPU runs at > 200MHz then the memory is accessed at
1/4 of the core cpu speed (for 100MHz SDRAM), but if the CPU runs < 200Mhz
it is 1/2 the core cpu speed, so at 206.4MHz you get 51.6Mhz, but at
191.7MHz you get 95.9MHz ram (almost twice as fast). Isn't it better to run
the CPU at a bit slower speed then or does the 20 odd Mhz make such a big
difference (in which case you should be running at 221.2MHz I guess).

My sincere apologies if some of the questions is off topic.

--=20

Regards
 Abraham

Rule #1:
	The Boss is always right.

Rule #2:
	If the Boss is wrong, see Rule #1.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: ab...@2d...         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Memory test routines in blob

[Abraham vd M. <ab...@2d...>]

Hi!

Is all the memory test routines working properly? I'm using a cvs snapshot
of a couple of days ago and I've tried the move-inverse test, address test,
and hardcore test on two different boards and they all seem to hang after a
while.

E.g. with the hardcore test I get:

------------< snip <------< snip <------< snip <------------
blob> chkmem 2 1 5
*** argv[0] =3D chkmem
*** argv[1] =3D 2
*** argv[2] =3D 1
*** argv[3] =3D 5
chkmem: display every 0x00000002 bytes

chkmem: hardcore test method
ChkMem: start(0xc0200000) - end(0xc4000000)
03e00000
01f00000
chkmem: method: test_or_comparison
        p1=3D0xc0200000 p2=3D0xc2100000 count=3D0x007c0000
c2103650
------------< snip <------< snip <------< snip <------------

and it just sits there.

with the address test I get:

------------< snip <------< snip <------< snip <------------
blob> chkmem 1 9 5
*** argv[0] =3D chkmem
*** argv[1] =3D 1
*** argv[2] =3D 9
*** argv[3] =3D 5
chkmem: display every 0x00000200 bytes

chkmem: address test method
ChkMem: start(0xc0200000) - end(0xc4000000)
ChkMem: fillup
------------< snip <------< snip <------< snip <------------

and the same thing happens. I tried the move-inverse test a while ago on
LART as well and that didn't get far either.

Am I doing something stupid or is the memory checking broken?

--=20

Regards
 Abraham

On a paper submitted by a physicist colleague:

"This isn't right.  This isn't even wrong."
		-- Wolfgang Pauli

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: ab...@2d...         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa

Re: null bytes?

[Tim R. <Ti...@Ri...>]

just to confirn, if you hexedit your lart blob you do not what are the
last 100 bytes or so?

I'm building with:

./configure  \
        --with-linux-prefix=/home/timr/work/vercel/linux \
        --enable-maintainer-mode \
        --enable-clock-scaling \
        --enable-memtest \
        --enable-debug \
        --enable-lcd \
        --enable-jffs2 \
        --enable-md5 \
        --with-board=idr \
        --enable-all-features \
        arm-linux
make

lcd and clock scale are not yet supported.

Erik Mouw wrote:
> 
> On Mon, Jan 28, 2002 at 03:44:24PM -0700, Tim Riker wrote:
> > hmm...
> >
> > I have not touched that file. Compiling for idr from cvs I see:
> >
> > timr@localhost:~/work/vercel/blob/src/blob$ ls -l blob*
> > -rwxr-xr-x    1 timr     timr        46520 Jan 28 14:12 blob
> > -rwxr-xr-x    1 timr     timr        46520 Jan 28 14:12 blob-chain
> > -rwxr-xr-x    1 timr     timr        45496 Jan 28 14:12 blob-rest
> > -rwxr-xr-x    1 timr     timr        77029 Jan 28 14:12 blob-rest-elf32
> > -rwxr-xr-x    1 timr     timr          852 Jan 27 01:30 blob-start
> > -rwxr-xr-x    1 timr     timr          196 Jan 27 01:30 blob-start-chain
> > -rwxr-xr-x    1 timr     timr        34179 Jan 27 01:30 blob-start-chain-elf32
> > -rwxr-xr-x    1 timr     timr        35805 Jan 27 01:30 blob-start-elf32
> >
> > where blob has 13k of nulls on the end.
> >
> > blob-rest-elf32 contains this same block on the end of the code before
> > the debug blocks.
> 
> I currently can't compile for idr because of compiler errors (SBI_SKCR
> undeclared in sa1111_init()), but this is the output from the last time
> I compiled it:
> 
> erik@arthur:idr/src/blob >pwd
> /home/erik/src/sourceforge/build/idr/src/blob
> erik@arthur:idr/src/blob >ls -l blob*
> -rwxr-xr-x    1 erik     users       32148 Jan 18 23:43 blob
> -rwxr-xr-x    1 erik     users       32148 Jan 17 00:22 blob-chain
> -rwxr-xr-x    1 erik     users       31124 Jan 17 00:22 blob-rest
> -rwxr-xr-x    1 erik     users       76596 Jan 17 00:22 blob-rest-elf32
> -rwxr-xr-x    1 erik     users         852 Jan 18 23:43 blob-start
> -rwxr-xr-x    1 erik     users         196 Jan  9 00:31 blob-start-chain
> -rwxr-xr-x    1 erik     users       34465 Jan  9 00:31 blob-start-chain-elf32
> -rwxr-xr-x    1 erik     users       36382 Jan 18 23:43 blob-start-elf32
> 
> And this is with today's CVS version for LART (compiled with
> --enable-md5):
> 
> erik@arthur:lart/src/blob >pwd
> /home/erik/src/sourceforge/build/lart/src/blob
> erik@arthur:lart/src/blob >ls -l blob*
> -rwxr-xr-x    1 erik     users       24632 Jan 21 22:51 blob
> -rwxr-xr-x    1 erik     users       24632 Jan 21 22:51 blob-chain
> -rwxr-xr-x    1 erik     users       23608 Jan 21 22:51 blob-rest
> -rwxr-xr-x    1 erik     users       65826 Jan 21 22:51 blob-rest-elf32
> -rwxr-xr-x    1 erik     users         640 Jan 19 00:47 blob-start
> -rwxr-xr-x    1 erik     users         196 Jan 19 00:47 blob-start-chain
> -rwxr-xr-x    1 erik     users       34466 Jan 19 00:47 blob-start-chain-elf32
> -rwxr-xr-x    1 erik     users       36162 Jan 19 00:47 blob-start-elf32
> 
> I can't really repeat your problem. I am using both my gcc-2.95.2
> toolchain (available from the LART site) and the gcc-2.95.3 toolchain
> (available from LART site and arm-linux FTP site).
> 
> Unless something is defining a non-null byte somewhere in the .bss
> segment or on the stack, I can't really see what's wrong.
> 
> Erik
> 
> > Erik Mouw wrote:
> > >
> > > On Mon, Jan 28, 2002 at 02:13:45PM -0700, Tim Riker wrote:
> > > > Anyone know why blob has close to 14k of nulls on the end?
> > >
> > > It doesn't, unless you have put a segment definition *after* the .bss
> > > segment in src/blob/rest-ld-script.in .
> 
> --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
> of Information Technology and Systems, Delft University of Technology,
> PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
> Fax: +31-15-2781843  Email: J.A...@it...
> WWW: http://www-ict.its.tudelft.nl/~erik/
> 
> _______________________________________________
> blob-cvs-commit mailing list
> blo...@li...
> https://lists.sourceforge.net/lists/listinfo/blob-cvs-commit

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Re: null bytes?

[Erik M. <J.A...@it...>]

On Mon, Jan 28, 2002 at 03:44:24PM -0700, Tim Riker wrote:
> hmm...
> 
> I have not touched that file. Compiling for idr from cvs I see:
> 
> timr@localhost:~/work/vercel/blob/src/blob$ ls -l blob* 
> -rwxr-xr-x    1 timr     timr        46520 Jan 28 14:12 blob
> -rwxr-xr-x    1 timr     timr        46520 Jan 28 14:12 blob-chain
> -rwxr-xr-x    1 timr     timr        45496 Jan 28 14:12 blob-rest
> -rwxr-xr-x    1 timr     timr        77029 Jan 28 14:12 blob-rest-elf32
> -rwxr-xr-x    1 timr     timr          852 Jan 27 01:30 blob-start
> -rwxr-xr-x    1 timr     timr          196 Jan 27 01:30 blob-start-chain
> -rwxr-xr-x    1 timr     timr        34179 Jan 27 01:30 blob-start-chain-elf32
> -rwxr-xr-x    1 timr     timr        35805 Jan 27 01:30 blob-start-elf32
> 
> where blob has 13k of nulls on the end.
> 
> blob-rest-elf32 contains this same block on the end of the code before
> the debug blocks.

I currently can't compile for idr because of compiler errors (SBI_SKCR
undeclared in sa1111_init()), but this is the output from the last time
I compiled it:

erik@arthur:idr/src/blob >pwd
/home/erik/src/sourceforge/build/idr/src/blob
erik@arthur:idr/src/blob >ls -l blob*
-rwxr-xr-x    1 erik     users       32148 Jan 18 23:43 blob
-rwxr-xr-x    1 erik     users       32148 Jan 17 00:22 blob-chain
-rwxr-xr-x    1 erik     users       31124 Jan 17 00:22 blob-rest
-rwxr-xr-x    1 erik     users       76596 Jan 17 00:22 blob-rest-elf32
-rwxr-xr-x    1 erik     users         852 Jan 18 23:43 blob-start
-rwxr-xr-x    1 erik     users         196 Jan  9 00:31 blob-start-chain
-rwxr-xr-x    1 erik     users       34465 Jan  9 00:31 blob-start-chain-elf32
-rwxr-xr-x    1 erik     users       36382 Jan 18 23:43 blob-start-elf32

And this is with today's CVS version for LART (compiled with
--enable-md5):

erik@arthur:lart/src/blob >pwd
/home/erik/src/sourceforge/build/lart/src/blob
erik@arthur:lart/src/blob >ls -l blob*
-rwxr-xr-x    1 erik     users       24632 Jan 21 22:51 blob
-rwxr-xr-x    1 erik     users       24632 Jan 21 22:51 blob-chain
-rwxr-xr-x    1 erik     users       23608 Jan 21 22:51 blob-rest
-rwxr-xr-x    1 erik     users       65826 Jan 21 22:51 blob-rest-elf32
-rwxr-xr-x    1 erik     users         640 Jan 19 00:47 blob-start
-rwxr-xr-x    1 erik     users         196 Jan 19 00:47 blob-start-chain
-rwxr-xr-x    1 erik     users       34466 Jan 19 00:47 blob-start-chain-elf32
-rwxr-xr-x    1 erik     users       36162 Jan 19 00:47 blob-start-elf32

I can't really repeat your problem. I am using both my gcc-2.95.2 
toolchain (available from the LART site) and the gcc-2.95.3 toolchain
(available from LART site and arm-linux FTP site).

Unless something is defining a non-null byte somewhere in the .bss
segment or on the stack, I can't really see what's wrong.


Erik

> Erik Mouw wrote:
> > 
> > On Mon, Jan 28, 2002 at 02:13:45PM -0700, Tim Riker wrote:
> > > Anyone know why blob has close to 14k of nulls on the end?
> > 
> > It doesn't, unless you have put a segment definition *after* the .bss
> > segment in src/blob/rest-ld-script.in .

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: null bytes?

[Tim R. <Ti...@Ri...>]

hmm...

I have not touched that file. Compiling for idr from cvs I see:

timr@localhost:~/work/vercel/blob/src/blob$ ls -l blob* 
-rwxr-xr-x    1 timr     timr        46520 Jan 28 14:12 blob
-rwxr-xr-x    1 timr     timr        46520 Jan 28 14:12 blob-chain
-rwxr-xr-x    1 timr     timr        45496 Jan 28 14:12 blob-rest
-rwxr-xr-x    1 timr     timr        77029 Jan 28 14:12 blob-rest-elf32
-rwxr-xr-x    1 timr     timr          852 Jan 27 01:30 blob-start
-rwxr-xr-x    1 timr     timr          196 Jan 27 01:30 blob-start-chain
-rwxr-xr-x    1 timr     timr        34179 Jan 27 01:30
blob-start-chain-elf32
-rwxr-xr-x    1 timr     timr        35805 Jan 27 01:30 blob-start-elf32

where blob has 13k of nulls on the end.

blob-rest-elf32 contains this same block on the end of the code before
the debug blocks.

Erik Mouw wrote:
> 
> On Mon, Jan 28, 2002 at 02:13:45PM -0700, Tim Riker wrote:
> > Anyone know why blob has close to 14k of nulls on the end?
> 
> It doesn't, unless you have put a segment definition *after* the .bss
> segment in src/blob/rest-ld-script.in .
> 
> Erik
> 
> --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
> of Information Technology and Systems, Delft University of Technology,
> PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
> Fax: +31-15-2781843  Email: J.A...@it...
> WWW: http://www-ict.its.tudelft.nl/~erik/
> 
> _______________________________________________
> blob-cvs-commit mailing list
> blo...@li...
> https://lists.sourceforge.net/lists/listinfo/blob-cvs-commit

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Re: null bytes?

[Erik M. <J.A...@it...>]

On Mon, Jan 28, 2002 at 02:13:45PM -0700, Tim Riker wrote:
> Anyone know why blob has close to 14k of nulls on the end?

It doesn't, unless you have put a segment definition *after* the .bss
segment in src/blob/rest-ld-script.in .


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

null bytes?

[Tim R. <Ti...@Ri...>]

Anyone know why blob has close to 14k of nulls on the end?
-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Re: CVS: blob/src/blob debug.c,1.9,1.10

[Erik M. <J.A...@it...>]

On Sun, Jan 27, 2002 at 11:47:45AM -0700, Tim Riker wrote:
> I just got a few people saying what does bitch-g do? ;-)

Ah, doh! I didn't look at it that way :)


Erik

> Erik Mouw wrote:
> > 
> > On Sun, Jan 27, 2002 at 02:03:56AM -0800, Tim Riker wrote:
> > > Update of /cvsroot/blob/blob/src/blob
> > > In directory usw-pr-cvs1:/tmp/cvs-serv5027/src/blob
> > >
> > > Modified Files:
> > >       debug.c
> > > Log Message:
> > > stop people from looking over my shoulder and asking why my app is swearing
> > 
> > Could you explain this cryptic comment? The code change is obviously
> > correct, but I don't see the relation with the comment.

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: CVS: blob/src/blob debug.c,1.9,1.10

[Tim R. <Ti...@Ri...>]

I just got a few people saying what does bitch-g do? ;-)

Erik Mouw wrote:
> 
> On Sun, Jan 27, 2002 at 02:03:56AM -0800, Tim Riker wrote:
> > Update of /cvsroot/blob/blob/src/blob
> > In directory usw-pr-cvs1:/tmp/cvs-serv5027/src/blob
> >
> > Modified Files:
> >       debug.c
> > Log Message:
> > stop people from looking over my shoulder and asking why my app is swearing
> 
> Could you explain this cryptic comment? The code change is obviously
> correct, but I don't see the relation with the comment.
> 
> Erik
> [confused]
> 
> --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
> of Information Technology and Systems, Delft University of Technology,
> PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
> Fax: +31-15-2781843  Email: J.A...@it...
> WWW: http://www-ict.its.tudelft.nl/~erik/

-- 
Tim Riker - http://rikers.org/ - short SIGs! <g>
All I need to know I could have learned in Kindergarten
... if I'd just been paying attention.

Re: CVS: blob/src/blob debug.c,1.9,1.10

[Erik M. <J.A...@it...>]

On Sun, Jan 27, 2002 at 02:03:56AM -0800, Tim Riker wrote:
> Update of /cvsroot/blob/blob/src/blob
> In directory usw-pr-cvs1:/tmp/cvs-serv5027/src/blob
> 
> Modified Files:
> 	debug.c 
> Log Message:
> stop people from looking over my shoulder and asking why my app is swearing

Could you explain this cryptic comment? The code change is obviously
correct, but I don't see the relation with the comment.


Erik
[confused]

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty
of Information Technology and Systems, Delft University of Technology,
PO BOX 5031, 2600 GA Delft, The Netherlands  Phone: +31-15-2783635
Fax: +31-15-2781843  Email: J.A...@it...
WWW: http://www-ict.its.tudelft.nl/~erik/

CVS: blob/src/blob debug.c,1.9,1.10

[Tim R. <tim...@us...>]

Update of /cvsroot/blob/blob/src/blob
In directory usw-pr-cvs1:/tmp/cvs-serv5027/src/blob

Modified Files:
	debug.c 
Log Message:
stop people from looking over my shoulder and asking why my app is swearing

Index: debug.c
===================================================================
RCS file: /cvsroot/blob/blob/src/blob/debug.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- debug.c	2002/01/06 15:44:23	1.9
+++ debug.c	2002/01/27 10:03:54	1.10
@@ -378,7 +378,7 @@
 __commandlist(dump, "dump", dumphelp );
 
 /*********************************************************************
- * BitChange
+ * ChangeBit
  *
  * AUTOR:		SELETZ
  * REVISED:
@@ -386,7 +386,7 @@
  * Modifies bits of an given memory location
  *
  */
-static int BitChange( int argc, char *argv[] )
+static int ChangeBit( int argc, char *argv[] )
 {
 	int		ret		= 0;
 	u32		adr		= 0L;
@@ -437,8 +437,8 @@
 	return ret;
 }
 
-static char bitchghelp[] = "bitchg address value {and|or|xor|set|clear}\n";
-__commandlist(BitChange, "bitchg", bitchghelp );
+static char chgbithelp[] = "chgbit address value {and|or|xor|set|clear}\n";
+__commandlist(ChangeBit, "chgbit", chgbithelp );
 
 /*********************************************************************
  * Call

CVS: blob/src/blob idr.c,1.6,1.7

[Tim R. <tim...@us...>]

Update of /cvsroot/blob/blob/src/blob
In directory usw-pr-cvs1:/tmp/cvs-serv28842/src/blob

Modified Files:
	idr.c 
Log Message:
sa1111 debug

Index: idr.c
===================================================================
RCS file: /cvsroot/blob/blob/src/blob/idr.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- idr.c	2002/01/20 17:09:08	1.6
+++ idr.c	2002/01/27 09:06:18	1.7
@@ -88,11 +88,23 @@
 	 * since we are planning jffs2, flash_enable should always be set. but
 	 * there is no accounting for taste. Tim Riker <Ti...@Ri...>
 	 */
-	PA_DDR &= ~(GPIO_GPIO2);
+	PA_DDR &= ~GPIO_GPIO2;
 	PA_DWR |= GPIO_GPIO2;
+
+	/*
+	 * for debug, we turn the backlight on here
+	 */
+	PA_DDR &= ~GPIO_GPIO3;
+	PA_DWR |= GPIO_GPIO3;
+#if 0
+	/* off reboots the machine, don't know why */
+	msleep(1000);
+	PA_DWR &= ~GPIO_GPIO3;
+#endif
 }
 
-__initlist(sa1111_init,		INIT_LEVEL_OTHER_HARDWARE);
+/* we still are not getting ID on serial, perhaps erik knows why */
+__initlist(sa1111_init,		INIT_LEVEL_OTHER_HARDWARE + 1);
 
 
 static void init_idr_flash_driver(void)

CVS: blob/include/blob/arch idr.h,1.4,1.5

[Tim R. <tim...@us...>]

Update of /cvsroot/blob/blob/include/blob/arch
In directory usw-pr-cvs1:/tmp/cvs-serv2973/include/blob/arch

Modified Files:
	idr.h 
Log Message:
work around

Index: idr.h
===================================================================
RCS file: /cvsroot/blob/blob/include/blob/arch/idr.h,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- idr.h	2002/01/27 07:07:45	1.4
+++ idr.h	2002/01/27 07:13:46	1.5
@@ -54,7 +54,11 @@
 #define KERNEL_FLASH_BASE	(PARAM_FLASH_BASE + PARAM_FLASH_LEN)
 #define KERNEL_FLASH_LEN	((1024 - 128) * 1024)
 #define RAMDISK_FLASH_BASE	(KERNEL_FLASH_BASE + KERNEL_FLASH_LEN)
+#ifdef FULL_RAMDISK_SIZE /* blob tries to load the whole image. ugh */
 #define RAMDISK_FLASH_LEN	(16 * 1024 * 1024 - BLOB_FLASH_LEN - PARAM_FLASH_LEN - KERNEL_FLASH_LEN)
+#else
+#define RAMDISK_FLASH_LEN	(4 * 1024 * 1024)
+#endif
 
 /* the position of the kernel boot parameters */
 #define BOOT_PARAMS		(0xc0000100)

CVS: blob/include/blob/arch idr.h,1.3,1.4

[Tim R. <tim...@us...>]

Update of /cvsroot/blob/blob/include/blob/arch
In directory usw-pr-cvs1:/tmp/cvs-serv32385/include/blob/arch

Modified Files:
	idr.h 
Log Message:
flash partitions

Index: idr.h
===================================================================
RCS file: /cvsroot/blob/blob/include/blob/arch/idr.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- idr.h	2002/01/20 05:15:53	1.3
+++ idr.h	2002/01/27 07:07:45	1.4
@@ -48,13 +48,13 @@
 
 /* and where do they live in flash */
 #define BLOB_FLASH_BASE		(0x00000000)
-#define BLOB_FLASH_LEN		(256 * 1024)
+#define BLOB_FLASH_LEN		(128 * 1024)
 #define PARAM_FLASH_BASE	(BLOB_FLASH_BASE + BLOB_FLASH_LEN)
-#define PARAM_FLASH_LEN		(256 * 1024)
+#define PARAM_FLASH_LEN		(0 * 1024) /* not used yet */
 #define KERNEL_FLASH_BASE	(PARAM_FLASH_BASE + PARAM_FLASH_LEN)
-#define KERNEL_FLASH_LEN	(1024 * 1024)
+#define KERNEL_FLASH_LEN	((1024 - 128) * 1024)
 #define RAMDISK_FLASH_BASE	(KERNEL_FLASH_BASE + KERNEL_FLASH_LEN)
-#define RAMDISK_FLASH_LEN	(4 * 1024 * 1024)
+#define RAMDISK_FLASH_LEN	(16 * 1024 * 1024 - BLOB_FLASH_LEN - PARAM_FLASH_LEN - KERNEL_FLASH_LEN)
 
 /* the position of the kernel boot parameters */
 #define BOOT_PARAMS		(0xc0000100)

RE: Regression?

[Russ D. <Rus...@as...>]

On Wed, 2002-01-23 at 11:14, Christopher Hoover wrote:
> 
> Good call.  It was indeed the new parameter code.  Flashing in a newly
> minted parameter block fixed things.

send me your old paramater block, b0rked paramater blocks should
*definately* not lock blob.

RE: Regression?

[Christopher H. <ch...@mu...>]

Good call.  It was indeed the new parameter code.  Flashing in a newly
minted parameter block fixed things.

-ch

> -----Original Message-----
> From: Erik Mouw [mailto:J.A...@it...] 
> Sent: Wednesday, January 23, 2002 12:44 AM
> To: Christopher Hoover
> Cc: blo...@li...
> Subject: Re: Regression?
> 
> 
> On Tue, Jan 22, 2002 at 06:44:36PM -0800, Christopher Hoover wrote:
> > On the BadgePAD platform, the code in CVS as of 1/17 works 
> just fine. 
> > The latest code on the trunk doesn't work as far as "reblob" is 
> > concerned  -- it just hangs.  Perhaps the code works from a proper 
> > reset, but just not via "reblob" -- I can't test that 
> scenario right 
> > now without risking turning my BadgePad into a paperweight 
> as I don't 
> > have access to my JTAG rig at this moment.
> 
> Hmm. Just did a "cvs diff -D 'last week' -D 'today'" to see 
> the differences.
> 
> The major change that affects all platforms is the split up 
> of the first stage loader in a machine dependent and a 
> machine independent part, but that shouldn't bite you with 
> reblob because we use blob-chain in that case. I tested the 
> new first stage loader on LART and Assabet and it shouldn't 
> break any platform because it is functionally the same (it 
> only moves the code around).
> 
> The other major change I can see is the parameter block 
> stuff. Both LART and Assabet have PARAM_START not defined, so 
> the ptag stuff doesn't get executed on those platforms. Could 
> you comment out
> parse_ptag() in main() and see if that fixes your problem?
> 
> 
> Erik
> 
> -- 
> J.A.K. (Erik) Mouw, Information and Communication Theory 
> Group, Faculty of Information Technology and Systems, Delft 
> University of Technology, PO BOX 5031, 2600 GA Delft, The 
> Netherlands  Phone: +31-15-2783635
> Fax: +31-15-2781843  Email: J.A...@it...
> WWW: http://www-ict.its.tudelft.nl/~erik/
> 

CVS: blob/src/blob badge4.c,1.4,1.5

[Christopher H. <ch...@us...>]

Update of /cvsroot/blob/blob/src/blob
In directory usw-pr-cvs1:/tmp/cvs-serv16437/src/blob

Modified Files:
	badge4.c 
Log Message:
tweak partitions

Index: badge4.c
===================================================================
RCS file: /cvsroot/blob/blob/src/blob/badge4.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- badge4.c	2002/01/15 01:45:01	1.4
+++ badge4.c	2002/01/23 18:09:42	1.5
@@ -38,13 +38,13 @@
 {
 	{
 		/* Eight 4 KW Parameter Bottom Blocks (64K bytes) */
-		size: 2 * 4 * 1024,
+		size: 2 * 4 * 1024,         /* 8 KiB */
 		num: 8,
 		lockable: 1
 	},
 	{
 		/* Sixty three 32 KW Main Blocks (4032K bytes) */
-		size: 2 * 32 * 1024,
+		size: 2 * 32 * 1024,        /* 64 KiB */
 		num: 63,
 		lockable: 1
 	},

CVS: blob/include/blob/arch badge4.h,1.2,1.3

[Christopher H. <ch...@us...>]

Update of /cvsroot/blob/blob/include/blob/arch
In directory usw-pr-cvs1:/tmp/cvs-serv16437/include/blob/arch

Modified Files:
	badge4.h 
Log Message:
tweak partitions

Index: badge4.h
===================================================================
RCS file: /cvsroot/blob/blob/include/blob/arch/badge4.h,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -d -r1.2 -r1.3
--- badge4.h	2002/01/15 01:45:01	1.2
+++ badge4.h	2002/01/23 18:09:42	1.3
@@ -48,9 +48,9 @@
 
 
 /* where do various parts live in RAM */
-#define BLOB_RAM_BASE		(0xc0100000)
+#define BLOB_RAM_BASE		(0XC0100000)
 #define KERNEL_RAM_BASE		(0xC0008000)
-#define PARAM_RAM_BASE		(0xc0110000)
+#define PARAM_RAM_BASE		(0XC0110000)
 #define RAMDISK_RAM_BASE	(0xC0600000)
 
 /* and where do they live in flash */
@@ -59,9 +59,9 @@
 #define PARAM_FLASH_BASE	(BLOB_FLASH_BASE + BLOB_FLASH_LEN)
 #define PARAM_FLASH_LEN		(0x00002000 * 2)
 #define KERNEL_FLASH_BASE	(PARAM_FLASH_BASE + PARAM_FLASH_LEN)
-#define KERNEL_FLASH_LEN	(0x00010000 * 20)
+#define KERNEL_FLASH_LEN	(0x00010000 * 16)
 #define RAMDISK_FLASH_BASE	(KERNEL_FLASH_BASE + KERNEL_FLASH_LEN)
-#define RAMDISK_FLASH_LEN	(0x00010000 * 43)
+#define RAMDISK_FLASH_LEN	(0x00010000 * 47)
 
 #define PARAM_START PARAM_FLASH_BASE
 #define PARAM_LEN PARAM_FLASH_LEN