From: Darren G. <ts...@ya...> - 2005-02-06 00:29:39
|
On Feb 5, 2005, at 6:36 AM, albertd wrote: > Total of 2346432 bytes were the same Hmmm... this might not mean anything: I just built the latest (350) and when I flashed it onto the gumstix I noticed: GUM> cmp.b a2000000 40000 $filesize Total of 3234148 bytes were the same Have you customized you build to leave a bunch of stuff out? I don't believe I've done anything to increase the size of my build. There's quite a large difference in size... |
From: Craig H. <cr...@hu...> - 2005-02-06 02:48:39
|
On Feb 5, 2005, at 4:29 PM, Darren Gibbs wrote: > > On Feb 5, 2005, at 6:36 AM, albertd wrote: >> Total of 2346432 bytes were the same > > Hmmm... this might not mean anything: > > I just built the latest (350) and when I flashed it onto the gumstix I > noticed: > > GUM> cmp.b a2000000 40000 $filesize > Total of 3234148 bytes were the same > > Have you customized you build to leave a bunch of stuff out? I don't > believe I've done anything to increase the size of my build. There's > quite a large difference in size... Yeah, I've been leaving some of the stuff out while doing some of these builds, to keep size down for faster flashing. I've found 2 possible patchsets out there which might be related to this problem -- one is a patch of RMK's for the memory manager itself, the other is a patch to the JFFS2 driver. The RMK patch didn't solve Albert's problem, but we didn't get a chance to try the other. I've posted http://www.hughes-family.org/craig/root_fs_arm.350-test which includes both patches -- if it works for you guys, then I'll check it in to SVN. C |
From: albertd <alb...@sy...> - 2005-02-06 04:05:20
|
Craig: I'm sorry to say that this load failed for me too. The CRC for this one is 6d2e3cd3, length 2346312. The slab corruption was flagged pretty much immediately: <verbatim> ... Freeing init memory: 60K slab: Internal list corruption detected in cache 'jffs2_full_dnode'(127), slabp c3c0b000(0). Hexdump: 000: 3c 8d 2d c0 3c 8d 2d c0 14 02 00 00 14 b2 c0 c3 010: 00 00 00 00 00 00 00 00 01 00 00 00 02 00 00 00 020: 03 00 00 00 04 00 00 00 05 00 00 00 06 00 00 00 </verbatim> ... And then a few BUGS, Oops' and more slab problem notifications (stacks chopped out): <verbatim> kernel BUG at mm/slab.c:1947! Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c0004000 [00000000] *pgd=00000000 Internal error: Oops: 807 [#1] Modules linked in: CPU: 0 PC is at __bug+0x40/0x54 LR is at 0x1 pc : [<c001df94>] lr : [<00000001>] Not tainted sp : c0357cf4 ip : 00000000 fp : c0357d04 r10: 00000001 r9 : 000000d0 r8 : c02d8d2c r7 : c02d35fc r6 : 00000010 r5 : c02d8d20 r4 : 00000000 r3 : 00000000 r2 : c01a00e4 r1 : c01cff20 r0 : 00000001 Flags: nZCv IRQs off FIQs on Mode SVC_32 Segment kernel Control: 397F Table: A03B0000 DAC: 0000001D Process jffs2_gcd_mtd2 (pid: 57, stack limit = 0xc0356190) Stack: (0xc0357cf4 to 0xc0358000) 7ce0: c3c0b000 c0357d40 c0357d08 7d00: c0060844 c001df60 c005f4e0 170fc2a5 c02d8a80 00000001 c02d8d20 60000013 </verbatim> ... <verbatim> 7fe0: 00000000 00000000 00000000 c0357ff8 c00342e4 c00d322c cc33cc33 cc33cc33 Backtrace: [<c001df54>] (__bug+0x0/0x54) from [<c0060844>] (cache_alloc_refill+0x164/0x930) r4 = C3C0B000 [<c00606e0>] (cache_alloc_refill+0x0/0x930) from [<c0060430>] (kmem_cache_alloc+0x9c/0xb8) [<c0060394>] (kmem_cache_alloc+0x0/0xb8) from [<c00c1b1c>] (jffs2_get_inode_nodes+0xbb0/0x11bc) r7 = C0383A14 r6 = 00000000 r5 = C037ECC0 r4 = C3C0A4E8 [<c00c0f6c>] (jffs2_get_inode_nodes+0x0/0x11bc) from [<c00c6658>] (jffs2_do_read_inode_internal+0x5c/0x90c) [<c00c65fc>] (jffs2_do_read_inode_internal+0x0/0x90c) from [<c00c6fa4>] (jffs2_do_crccheck_inode+0x9c/0xf4) [<c00c6f08>] (jffs2_do_crccheck_inode+0x0/0xf4) from [<c00cfe80>] (jffs2_garbage_collect_pass+0x5fc/0x1264) r7 = 00000000 r6 = C037ECC0 r5 = C0185380 r4 = C0380B40 [<c00cf884>] (jffs2_garbage_collect_pass+0x0/0x1264) from [<c00d34f8>] (jffs2_garbage_collect_thread+0x2d8/0x424) [<c00d3220>] (jffs2_garbage_collect_thread+0x0/0x424) from [<c00342e4>] (do_exit+0x0/0x1104) Code: 1b004e55 e59f0014 eb004e53 e3a03000 (e5833000) <3>Slab corruption: start=c3c1ca78, len=1308 Redzone: 0x5a2cf071/0x5a2cf071. Last user: [<00000000>](0x0) 2a0: 6b 6b 6b 6b 6b 6b 6b 6b 4b 6a 6b 6b 6b 6b 6b 6b Prev obj: start=c3c1c550, len=1308 Redzone: 0x5a2cf071/0x5a2cf071. Last user: [<00000000>](0x0) 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b Unable to handle kernel paging request at virtual address c024f7d8 pgd = c3c7c000 [c024f7d8] *pgd=a020042e(bad) Internal error: Oops: 81d [#2] Modules linked in: CPU: 0 PC is at buffered_rmqueue+0x1f0/0x488 LR is at __alloc_pages+0x104/0x35c pc : [<c005a564>] lr : [<c005a900>] Not tainted sp : c0359e58 ip : 00000000 fp : c0359e98 r10: 00000000 r9 : c034b920 r8 : c01a2b10 r7 : c024f7c0 r6 : c01a2710 r5 : c01a26f4 r4 : 00003b7c r3 : 00100100 r2 : c024f7d8 r1 : c024f7f8 r0 : c01a2720 Flags: nzCv IRQs off FIQs on Mode SVC_32 Segment user Control: 397F Table: A3C7C000 DAC: 00000015 Process init (pid: 58, stack limit = 0xc0358190) Stack: (0xc0359e58 to 0xc035a000) 9e40: 00000000 c034bd20 9e60: 60000013 00000000 60000013 00000000 00003b7c 00000141 00000001 000000d2 </verbatim> ... We'll lick this eventually. I'll try the cpufreg parameter tomorrow. Albert. Craig Hughes wrote: > On Feb 5, 2005, at 4:29 PM, Darren Gibbs wrote: > >> >> On Feb 5, 2005, at 6:36 AM, albertd wrote: >> >>> Total of 2346432 bytes were the same >> >> >> Hmmm... this might not mean anything: >> >> I just built the latest (350) and when I flashed it onto the gumstix >> I noticed: >> >> GUM> cmp.b a2000000 40000 $filesize >> Total of 3234148 bytes were the same >> >> Have you customized you build to leave a bunch of stuff out? I don't >> believe I've done anything to increase the size of my build. There's >> quite a large difference in size... > > > Yeah, I've been leaving some of the stuff out while doing some of > these builds, to keep size down for faster flashing. > > I've found 2 possible patchsets out there which might be related to > this problem -- one is a patch of RMK's for the memory manager itself, > the other is a patch to the JFFS2 driver. The RMK patch didn't solve > Albert's problem, but we didn't get a chance to try the other. I've > posted http://www.hughes-family.org/craig/root_fs_arm.350-test which > includes both patches -- if it works for you guys, then I'll check it > in to SVN. > > C |
From: Craig H. <cr...@hu...> - 2005-02-06 06:31:42
|
On Feb 5, 2005, at 8:03 PM, albertd wrote: > We'll lick this eventually. I'll try the cpufreg parameter tomorrow. I've updated SVN to turn cpufreq off, and built a stripped-down version which is basically just kernel, uclibc plus busybox which is at http://www.hughes-family.org/craig/root_fs_arm.352 if you want to save yourself the build time C |
From: albertd <alb...@sy...> - 2005-02-06 19:43:01
|
This one worked for me too. The delay from the "Freeing init memory: 60K" line to the "Loading modules: " line was a bit tense though :) . If remember correctly that is when jffs2 was building its in-RAM inode tables so I wonder if there is still a lot of now-unecessary paranoic checking going on then? Albert. Craig Hughes wrote: > On Feb 5, 2005, at 8:03 PM, albertd wrote: > >> We'll lick this eventually. I'll try the cpufreg parameter tomorrow. > > > I've updated SVN to turn cpufreq off, and built a stripped-down > version which is basically just kernel, uclibc plus busybox which is > at http://www.hughes-family.org/craig/root_fs_arm.352 if you want to > save yourself the build time > > C > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: mark g. <mar...@th...> - 2005-02-06 20:43:21
|
On Sun, 2005-02-06 at 14:41 -0500, albertd wrote: > This one worked for me too. > > The delay from the "Freeing init memory: 60K" line to the "Loading > modules: " line was a bit tense though :) . > It this wait gets a lot shorter if you have an MMC in the slot. > If remember correctly that is when jffs2 was building its in-RAM inode > tables so I wonder if there is still a lot of now-unecessary paranoic > checking going on then? > > Albert. > > > Craig Hughes wrote: > > > On Feb 5, 2005, at 8:03 PM, albertd wrote: > > > >> We'll lick this eventually. I'll try the cpufreg parameter tomorrow. > > > > > > I've updated SVN to turn cpufreq off, and built a stripped-down > > version which is basically just kernel, uclibc plus busybox which is > > at http://www.hughes-family.org/craig/root_fs_arm.352 if you want to > > save yourself the build time > > > > C > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > > Tool for open source databases. Create drag-&-drop reports. Save time > > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Ralph M. <rj...@me...> - 2005-02-06 22:05:16
|
mark gross writes: > On Sun, 2005-02-06 at 14:41 -0500, albertd wrote: > > This one worked for me too. > > > > The delay from the "Freeing init memory: 60K" line to the "Loading > > modules: " line was a bit tense though :) . > > > > It this wait gets a lot shorter if you have an MMC in the slot. Not directly related to this, but, now that 2.6.10 works for me, I also tried the sdcard patch for 2.6.10 from http://projects.drzeus.cx/wbsd/sd.php and it works nicely on the gumstix. u-boot will still only accept mmc cards of course. Ralph |
From: Craig H. <cr...@hu...> - 2005-02-06 22:41:32
|
On Feb 6, 2005, at 2:05 PM, Ralph Metzler wrote: > mark gross writes: >> On Sun, 2005-02-06 at 14:41 -0500, albertd wrote: >>> This one worked for me too. >>> >>> The delay from the "Freeing init memory: 60K" line to the "Loading >>> modules: " line was a bit tense though :) . >>> >> >> It this wait gets a lot shorter if you have an MMC in the slot. > > > Not directly related to this, but, now that 2.6.10 works for me, I > also tried the sdcard patch for 2.6.10 from > http://projects.drzeus.cx/wbsd/sd.php > and it works nicely on the gumstix. > u-boot will still only accept mmc cards of course. Yeah, I've been reading that thread on the arm-linux mailing list, and have that URL open in a tab in my browser to visit as soon as I get the chance. Was it just a drop-in patch, or did you have to back out any of the existing MMC patches in the buildroot? C |
From: Ralph M. <rj...@me...> - 2005-02-07 10:52:32
|
Craig Hughes writes: > > Not directly related to this, but, now that 2.6.10 works for me, I > > also tried the sdcard patch for 2.6.10 from > > http://projects.drzeus.cx/wbsd/sd.php > > and it works nicely on the gumstix. > > u-boot will still only accept mmc cards of course. > > Yeah, I've been reading that thread on the arm-linux mailing list, and > have that URL open in a tab in my browser to visit as soon as I get the > chance. Was it just a drop-in patch, or did you have to back out any > of the existing MMC patches in the buildroot? You can just drop it in. No rejects. Ralph |
From: Craig H. <cr...@hu...> - 2005-02-07 11:00:14
|
On Feb 7, 2005, at 2:52 AM, Ralph Metzler wrote: > Craig Hughes writes: >>> Not directly related to this, but, now that 2.6.10 works for me, I >>> also tried the sdcard patch for 2.6.10 from >>> http://projects.drzeus.cx/wbsd/sd.php >>> and it works nicely on the gumstix. >>> u-boot will still only accept mmc cards of course. >> >> Yeah, I've been reading that thread on the arm-linux mailing list, and >> have that URL open in a tab in my browser to visit as soon as I get >> the >> chance. Was it just a drop-in patch, or did you have to back out any >> of the existing MMC patches in the buildroot? > > > You can just drop it in. No rejects. Yup, read through it and the various bits I had from elsewhere -- looks like I actually backed just about everything out when moving to 2.6.10 because it was going to require some work to re-merge everything. The patch is now in SVN, and looks pretty good from the basic testing I've done (which includes lots of MMC cards, but only the one SD card I own). C |
From: Darren G. <ts...@ya...> - 2005-02-06 20:25:31
|
This build seems to work fine for me too. On Feb 5, 2005, at 10:31 PM, Craig Hughes wrote: > I've updated SVN to turn cpufreq off, and built a stripped-down > version which is basically just kernel, uclibc plus busybox which is > at http://www.hughes-family.org/craig/root_fs_arm.352 if you want to > save yourself the build time |
From: albertd <alb...@sy...> - 2005-02-05 02:32:00
|
Craig: I'm suffering from the post r306 unpredictable but immediate crash problems too. * Build r162 from sf.net works as far as it does. I want NFS mounting for faster development and the portmapper is not there :) * A local build of r306 boots and mounts jffs2 fine as far as I can tell. UsbNet seems broken as reported by others on this thread. * r312, r344, and r350 (local and your published build thank you) have all failed with unpredictable results after the kernel init code has been freed "Freeing init memory: 52K" but, of course, that is right after "VFS: Mounted root (jffs2 filesystem)." On additional hygine suggestion I have is to do a "cmp.b a2000000 40000 ${filesize}" after each "cp.b a2000000 40000 ${filesize}" to ensure the copy happened correctly. In fact I have that whole copy from ram to flash mantra in a u-boot environment variable ready to run at need: <verbatim> setenv cpram2fl 'era 1:2-31; cp.b a2000000 40000 ${filesize}; cmp.b a2000000 40000 ${filesize}' </verbatim> make this permanent with "saveenv" and you can run it at any time with "run cpram2fl". MAKE SURE TO PAY ATTENTION TO THE RESULTS OF THE TEST! Proceeding blindly will not save you from faulty hardware, and flashing random ram does not work well either :/ Now on to some questions: How do I determine which u-boot I have loaded? The banner upon reset is <verbatim> U-Boot 1.1.1 (Oct 3 2004 - 21:30:21) *** Welcome to Gumstix *** U-Boot code: A3F00000 -> A3F1B01C BSS: -> A3F4CB54 RAM Configuration: Bank #0: a0000000 64 MB erase_region_count = 32 erase_region_size = 131072 Flash: 4 MB Hit any key to stop autoboot: 0 </verbatim> I tried the crc checks you suggested below and they succeeded in producing the same CRC values for flash and Ram as expected. But, I then noticed the 'mw' command in u-boot and wondered if there was a way to save some time here (4mb of download @115.2kbaud is a bit tedious) How would the following methods of generating the 1's and 0's differ from the downloaded files approach? mw.b a2000000 ff 3c0000; crc a2000000 3c0000 mw.b a2000000 0 3c0000; crc a2000000 3c0000 The whole script would then be: <verbatim> era 1:2-31;crc 40000 3c0000 mw.b a2000000 ff 3c0000; crc a2000000 3c0000 mw.b a2000000 0 3c0000; cp.b a2000000 40000 3c0000 crc 40000 3c0000;crc a2000000 3c0000 </verbatim> with two equal pairs of CRC's reported meaning success. Just for the record here is the result from my gumstix 400-bt <verbatim> era 1:2-31;crc 40000 3c0000 Erase Flash Sectors 2-31 in Bank # 1 .............................. done CRC32 for 00040000 ... 003fffff ==> c1169414 GUM> mw.b a2000000 ff 3c0000; crc a2000000 3c0000 CRC32 for a2000000 ... a23bffff ==> c1169414 GUM> mw.b a2000000 0 3c0000; cp.b a2000000 40000 3c0000 Copy to Flash... done GUM> crc 40000 3c0000;crc a2000000 3c0000 CRC32 for 00040000 ... 003fffff ==> 148c0301 CRC32 for a2000000 ... a23bffff ==> 148c0301 GUM> </verbatim> Craig Hughes wrote: > On Feb 4, 2005, at 6:58 AM, mark gross wrote: > >> Sorry I get the crash after freeing init memory with this image :( >> >> Have you reproduced this failure on your hardware yet? This is a >> showstopper. >> >> I wonder if my hardware differs from yours or is defective. > > > Haven't been able to reproduce that on any gumstix I've tried -- about > half a dozen now, including -orig's, -f's and -g's. You may well have > a bad block in flash or something. Try creating a file which is all > 0s, and another which is all 1s, the size of root_fs space of gumstix > flash: > > (in linux): dd if=/dev/zero of=big_zeros bs=128k count=30 > tr '\000' '\377' < big_zeros > big_ones > > Now, in u-boot, era 1:2-31;crc 40000 3c0000 > > That will give you the CRC of the wiped flash, which *should* all be > 1's. So check: > > loadb [now send big_ones];crc a2000000 3c0000 <-- should be same > CRC. If not, you have a bit or more in flash which won't erase > > If that worked, then loadb the big_zeros file, and cp it to flash > loadb;cp.b a2000000 40000 3c0000;crc 40000 3c0000;crc a2000000 3c0000 > > If those two crcs differ, then you have at least one bit which won't > reset. > > If both CRCs match, then problem is probably somewhere else -- what > version of u-boot are you using? > > C > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Craig R H. <cr...@gu...> - 2005-02-05 08:17:38
|
albertd wrote: a> Craig: a> a> I'm suffering from the post r306 unpredictable but immediate crash problems a> too. a> * Build r162 from sf.net works as far as it does. I want NFS mounting for a> faster development and the portmapper is not there :) a> * A local build of r306 boots and mounts jffs2 fine as far as I can tell. a> UsbNet seems broken as reported by others on this thread. a> * r312, r344, and r350 (local and your published build thank you) have all a> failed with unpredictable results after the kernel init code has been freed a> "Freeing init memory: 52K" but, of course, that is right after "VFS: Mounted a> root (jffs2 filesystem)." Shucks -- that means there might be a bug in there. Do you get the same or similar oopses each time? I'll compile a more instrumented kernel for you guys to try out, see if we can't figure out where the bug is. a> How would the following methods of generating the 1's and 0's differ from the a> downloaded files approach? a> mw.b a2000000 ff 3c0000; crc a2000000 3c0000 a> mw.b a2000000 0 3c0000; crc a2000000 3c0000 a> a> a> The whole script would then be: a> <verbatim> a> era 1:2-31;crc 40000 3c0000 a> mw.b a2000000 ff 3c0000; crc a2000000 3c0000 a> mw.b a2000000 0 3c0000; cp.b a2000000 40000 3c0000 a> crc 40000 3c0000;crc a2000000 3c0000 a> </verbatim> a> with two equal pairs of CRC's reported meaning success. Yup -- that should work great! I was trying to think of a way of generating the 0's and 1's in uboot but that didn't occur to me. C |
From: albertd <alb...@sy...> - 2005-02-05 19:39:34
|
Craig Hughes wrote: > On Feb 5, 2005, at 6:36 AM, albertd wrote: > >> /sbin/init: can't handle reloc type 0x7 > > > Uh -- that's messed up. uClibc is reading some ELF header and finds > that the thing is claiming to be a binary targeting the Hitachi SH > processor family... > > Something is definitely getting corrupted, either in flash or in RAM, > since my gumstixen definitely recognize /sbin/init as being an ARM > binary. Let's see if we can track down the difference between your > setup and mine. First up: the compile environment (not really relevant for the downloaded http://www.hughes-family.org/craig/root_fs_arm.350 , but I want to be complete: * Debian GNU/Linux 3.0 A.K.A sarge A.K.A testing, with daily updates to track the ongoing bugfixes. and a 2.6.10-i686 kernel from unstable * gcc version 3.3.5 (Debian 1:3.3.5-5) * kernel "Linux version 2.6.10-1-686 (dil...@to...) (gcc version 3.3.5 (Debian 1:3.3.5-6))#1 Tue Jan 18 04:34:19 EST 2005" from unstable > Can you read the numbers off the CPU on the gumstix? That's the > square chip in the middle of the board. Then there are 2 identical > chips towards one end, and one chip all the way on the end which is > different. The pair are RAM and the lonely end one is flash -- could > you please read me the numbers off those as well. > This was sold to me as a 400bt around a week ago :) CPU: PXA255A0D400 L4160462 INTEL (M) (c) '01 KOREA Z416I100A Both RAM chips: 4HD41 DWHDF (in small print in one corner) 8N6T FLASH 28F320J3C110 A3527408 Z40220318 (M) (c)'03 Board Rev (between the RAM chips) GUMSTIK ?0.6 > Thanks > > C > > PS I'm assuming that every time you boot, you get the same error. With my recent download from you, yes. On previous loads no. On a whim I protected the whole flash and mounted root read-only for my homegrown r344, r350, and the first load you published this week, and I would get different failures each boat. Annoying! Would shifting the root fs around in flash tell us anything? Albert. |
From: Ralph M. <rj...@me...> - 2005-02-05 21:00:34
|
albertd writes: > This was sold to me as a 400bt around a week ago :) > > CPU: > PXA255A0D400 > L4160462 > > INTEL (M) (c) '01 > > KOREA > Z416I100A > > Both RAM chips: > 4HD41 > DWHDF > (in small print in one corner) 8N6T > > FLASH > 28F320J3C110 > A3527408 > Z40220318 > (M) (c)'03 > > Board Rev (between the RAM chips) > GUMSTIK ?0.6 > Since I have the same problems, here is what's on mine: CPU: PXA255A0C400 L4210342 INTEL (M)(C)'01 PHILIPPINES 2420S43CB 421 RAM: 4KD41 DWHDF 96XJ FLASH: 28F320J3C110 A3527408 Z40220318 (M)(C)'03 also GUMSTIK 0.6 > > Thanks > > > > C > > > > PS I'm assuming that every time you boot, you get the same error. > > With my recent download from you, yes. On previous loads no. On a whim > I protected the whole flash and mounted root read-only for my homegrown > r344, r350, and the first load you published this week, and I would get > different failures each boat. Annoying! > > Would shifting the root fs around in flash tell us anything? I renamed init so that nothing is executed after boot, only a shell. This seems to work every time, at least up to getting a prompt. Then things get weird. Sometimes I can e.g. execute "dmesg" and I get normal output, sometimes some characters seem to be mangled, most of the times I get some kind of kernel crash. Similar things happen if use other commands. Ralph |
From: mark g. <mar...@th...> - 2005-02-06 06:46:50
|
On Sat, 2005-02-05 at 22:31 -0800, Craig Hughes wrote: > On Feb 5, 2005, at 8:03 PM, albertd wrote: > > > We'll lick this eventually. I'll try the cpufreg parameter tomorrow. > > I've updated SVN to turn cpufreq off, and built a stripped-down version > which is basically just kernel, uclibc plus busybox which is at > http://www.hughes-family.org/craig/root_fs_arm.352 if you want to save > yourself the build time > > C > This image works well for my on my gumstix. Thanks. --mgross Uncompressing Linux................................................. done, booting the kernel. Linux version 2.6.10gum (craig@azazel) (gcc version 3.4.2) #1 Sat Feb 5 22:26:38 PST 2005 CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE) CPU: D VIVT undefined 5 cache CPU: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets CPU: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets Machine: The Gumstix Platform Memory policy: ECC disabled, Data cache writeback Memory clock: 99.53MHz (*27) Run Mode clock: 398.13MHz (*4) Turbo Mode clock: 398.13MHz (*1.0, inactive) Built 1 zonelists Kernel command line: console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 reboot=cold,hard PID hash table entries: 512 (order: 9, 8192 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 64MB = 64MB total Memory: 63360KB available (1214K code, 221K data, 60K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 NetWinder Floating Point Emulator V0.97 (double precision) JFFS2 version 2.2. (C) 2001-2003 Red Hat, Inc. ttyS0 at MMIO 0x40100000 (irq = 15) is a FFUART ttyS1 at MMIO 0x40200000 (irq = 14) is a BTUART ttyS2 at MMIO 0x40700000 (irq = 13) is a STUART ttyS3 at MMIO 0x41600000 (irq = 0) is a HWUART io scheduler noop registered elevator: using noop as default io scheduler physmap flash device: 400000 at 0 phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled cmdlinepart partition parsing not available RedBoot partition parsing not available Probing Gumstix Flash ROM at physical address 0x00000000 (16-bit bankwidth) Gumstix Flash ROM: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled Using static partitions on Gumstix Flash ROM Creating 2 MTD partitions on "Gumstix Flash ROM": 0x00000000-0x00040000 : "Bootloader" 0x00040000-0x00400000 : "RootFS" NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) VFS: Mounted root (jffs2 filesystem). Freeing init memory: 60K Loading modules: mmc_block pxamci vfat nls_iso8859-1 nls_cp437 : Loaded. Initializing random number generator... done. Starting network... pxa2xx_udc: version 14-Dec-2003 usb0: Ethernet Gadget, version: Equinox 2004 usb0: using pxa2xx_udc, OUT ep2out-bulk IN ep1in-bulk STATUS ep6in-bulk usb0: MAC 02:00:c2:3f:50:60 usb0: HOST MAC 02:00:c2:3f:50:60 usb0: RNDIS ready NET: Registered protocol family 17 udhcpc (v0.9.9-pre) started Dec 31 16:00:27 udhcpc[187]: udhcpc (v0.9.9-pre) started Backgrounding Dec 31 16:00:28 udhcpc[187]: Backgrounding Dec 31 16:00:28 udhcpc[200]: Sending discover... NET: Registered protocol family 1 Welcome to the Gumstix Linux Distribution! gumstix login: root Password: # df Filesystem Size Used Available Use% Mounted on /dev/mtdblock2 3.8M 2.4M 1.4M 63% / # free total used free shared buffers Mem: 63436 3476 59960 0 0 Swap: 0 0 0 Total: 63436 3476 59960 # lsmod Module Size Used by unix 23608 8 - Live 0xbf036000 af_packet 17192 9 - Live 0xbf030000 g_ether 21372 0 - Live 0xbf029000 pxa2xx_udc 13220 1 g_ether, Live 0xbf024000 gumstix_gadget 1376 1 pxa2xx_udc, Live 0xbf022000 nls_cp437 5504 0 - Live 0xbf01f000 nls_iso8859_1 3840 0 - Live 0xbf01d000 vfat 11584 0 - Live 0xbf019000 fat 36892 1 vfat, Live 0xbf00e000 nls_base 6528 4 nls_cp437,nls_iso8859_1,vfat,fat, Live 0xbf00b000 pxamci 5728 0 - Live 0xbf008000 |
From: Ralph M. <rj...@me...> - 2005-02-06 12:13:35
|
mark gross writes: > On Sat, 2005-02-05 at 22:31 -0800, Craig Hughes wrote: > > On Feb 5, 2005, at 8:03 PM, albertd wrote: > > > > > We'll lick this eventually. I'll try the cpufreg parameter tomorrow. > > > > I've updated SVN to turn cpufreq off, and built a stripped-down version > > which is basically just kernel, uclibc plus busybox which is at > > http://www.hughes-family.org/craig/root_fs_arm.352 if you want to save > > yourself the build time > > > > C > > > > This image works well for my on my gumstix. Thanks. Yes, works fine here too. Thanks. Now the big question is, what does "CPU_FREQ" do that could cause problems on some gumstix and not on others. Ralph |
From: mark g. <mar...@th...> - 2005-02-06 16:20:20
|
On Sun, 2005-02-06 at 13:13 +0100, Ralph Metzler wrote: > mark gross writes: > > On Sat, 2005-02-05 at 22:31 -0800, Craig Hughes wrote: > > > On Feb 5, 2005, at 8:03 PM, albertd wrote: > > > > > > > We'll lick this eventually. I'll try the cpufreg parameter tomorrow. > > > > > > I've updated SVN to turn cpufreq off, and built a stripped-down version > > > which is basically just kernel, uclibc plus busybox which is at > > > http://www.hughes-family.org/craig/root_fs_arm.352 if you want to save > > > yourself the build time > > > > > > C > > > > > > > This image works well for my on my gumstix. Thanks. > > > Yes, works fine here too. > Thanks. > > Now the big question is, what does "CPU_FREQ" do that could cause > problems on some gumstix and not on others. > Indeed, I feel that I deserve to know why this is the case. Its possible we have a newer or older stepping of the PXA part, is there an errata? --mgross |
From: Craig H. <cr...@hu...> - 2005-02-03 17:49:17
|
Bleargh -- side effect of working at 1am is that you post things to the wrong server... Try http://www.hughes-family.org/craig/root_fs_arm.550 C On Feb 3, 2005, at 7:10 AM, mark gross wrote: > On Thu, 2005-02-03 at 01:05 -0800, Craig R Hughes wrote: >> Ok, I just found the problem, which sneaked in betwen r275 and r276. >> I failed >> to merge over one sub-patch to the USB code. It's not back in there >> with r350, >> and Works For Me. I've built a stripped-down r350 just to verify >> that USB >> works -- http://www.rungie.com/craig/root_fs_arm.350 -- full kernel >> but light on >> the TARGETS for faster flashing... >> > > Not Found > The requested URL /craig/root_fs_arm.350 was not found on this server. > > :( > > --mgross > >> Thanks, >> >> C >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IntelliVIEW -- Interactive >> Reporting >> Tool for open source databases. Create drag-&-drop reports. Save time >> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >> Download a FREE copy at http://www.intelliview.com/go/osdn_nl >> _______________________________________________ >> gumstix-users mailing list >> gum...@li... >> https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting > Tool for open source databases. Create drag-&-drop reports. Save time > by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. > Download a FREE copy at http://www.intelliview.com/go/osdn_nl > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |