You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(79) |
Aug
(27) |
Sep
(64) |
Oct
(202) |
Nov
(31) |
Dec
(59) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(125) |
Feb
(173) |
Mar
(13) |
Apr
(140) |
May
(75) |
Jun
(1) |
Jul
(37) |
Aug
(14) |
Sep
|
Oct
(20) |
Nov
(9) |
Dec
(2) |
2003 |
Jan
(51) |
Feb
(12) |
Mar
(18) |
Apr
(24) |
May
(1) |
Jun
|
Jul
|
Aug
(72) |
Sep
(12) |
Oct
(18) |
Nov
(60) |
Dec
(26) |
2004 |
Jan
(1) |
Feb
(40) |
Mar
(3) |
Apr
(3) |
May
|
Jun
(1) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(5) |
2006 |
Jan
(13) |
Feb
(5) |
Mar
(8) |
Apr
(13) |
May
(7) |
Jun
(6) |
Jul
(10) |
Aug
(6) |
Sep
(6) |
Oct
(35) |
Nov
(20) |
Dec
(10) |
2007 |
Jan
(13) |
Feb
(9) |
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(54) |
Jun
(78) |
Jul
(35) |
Aug
(21) |
Sep
(21) |
Oct
(29) |
Nov
(10) |
Dec
(5) |
2010 |
Jan
|
Feb
|
Mar
(26) |
Apr
(55) |
May
(73) |
Jun
(63) |
Jul
(38) |
Aug
(39) |
Sep
(19) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2011 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Erik M. <er...@us...> - 2002-01-29 17:47:26
|
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 |
From: Erik M. <er...@us...> - 2002-01-29 17:08:24
|
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 |
From: Erik M. <er...@us...> - 2002-01-29 17:08:24
|
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 |
From: Erik M. <J.A...@it...> - 2002-01-29 16:56:17
|
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/ |
From: Erik M. <er...@us...> - 2002-01-29 16:27:45
|
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@ |
From: Erik M. <er...@us...> - 2002-01-29 16:22:49
|
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 |
From: Abraham vd M. <ab...@2d...> - 2002-01-29 15:09:30
|
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 |
From: Abraham vd M. <ab...@2d...> - 2002-01-29 14:46:35
|
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 |
From: Abraham vd M. <ab...@2d...> - 2002-01-29 14:36:25
|
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 |
From: Tim R. <Ti...@Ri...> - 2002-01-29 03:11:28
|
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. |
From: Erik M. <J.A...@it...> - 2002-01-29 00:59:16
|
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/ |
From: Tim R. <Ti...@Ri...> - 2002-01-28 23:02:35
|
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. |
From: Erik M. <J.A...@it...> - 2002-01-28 22:17:25
|
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/ |
From: Tim R. <Ti...@Ri...> - 2002-01-28 21:31:16
|
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. |
From: Erik M. <J.A...@it...> - 2002-01-28 00:10:30
|
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/ |
From: Tim R. <Ti...@Ri...> - 2002-01-27 18:58:55
|
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. |
From: Erik M. <J.A...@it...> - 2002-01-27 18:23:27
|
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/ |
From: Tim R. <tim...@us...> - 2002-01-27 10:03:56
|
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 |
From: Tim R. <tim...@us...> - 2002-01-27 09:06:20
|
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) |
From: Tim R. <tim...@us...> - 2002-01-27 07:13:49
|
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) |
From: Tim R. <tim...@us...> - 2002-01-27 07:07:48
|
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) |
From: Russ D. <Rus...@as...> - 2002-01-23 20:46:49
|
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. |
From: Christopher H. <ch...@mu...> - 2002-01-23 18:14:12
|
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/ > |
From: Christopher H. <ch...@us...> - 2002-01-23 18:09:46
|
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 }, |
From: Christopher H. <ch...@us...> - 2002-01-23 18:09:46
|
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 |