From: Peter L. <pl...@gm...> - 2007-07-25 15:00:55
|
Hi, I'm trying to load a new rootfs to my Gumstix and hitting a "bad magic" error in uboot. I followed the instructions to re-write flash via tftp per: http://docwiki.gumstix.org/Replacing_the_filesystem_image and the process completed without error. I've tried both the .jffs2 I built as well as the pre-built one at sourceforge: http://sourceforge.net/project/showfiles.php?group_id=98784 I've googled this issue and found a couple of similar issues others had, but have not been able to find any relevant solution. Thanks for any help. ====== U-Boot 1.1.4 (Aug 1 2006 - 10:47:14) *** Welcome to Gumstix *** U-Boot code: A3F00000 -> A3F25D1C BSS: -> A3F5AE38 RAM Configuration: Bank #0: a0000000 64 MB Flash: 16 MB SMC91C1111-0 Can't overwrite "serial#" Net: SMC91C1111-0 Hit any key to stop autoboot: 0 Emable Power ## Booting image at a2000000 ... Bad Magic Number GUM> md a2000000 a2000000: 20031985 0000000c e41eb0b1 e0011985 ... ............ a2000010: 0000002b 7d266ee6 00000001 00000000 +....n&}........ a2000020: 00000002 46a5b099 00000403 12386f25 .......F....%o8. a2000030: 556683ff ff6e6962 e0021985 00000044 ..fUbin.....D... |
From: Peter L. <pl...@gm...> - 2007-07-25 15:09:45
|
Hi, I looked at my u-boot environment variables and the root seems to be set at 140000 rather than 40000. The instructions for flashing rootfs uses 40000 for the cp.b. Could someone clarify to me what should be done with the .jffs2 file once I download it to a2000000? Thanks. === U-boot environment variables GUM> printenv baudrate=115200 ethaddr=00:0A:95:A5:47:3A verify=no ethact=SMC91C1111-0 serial#=66D68FA522DAC5B3 clearflash=pro on 1:0-1 && era all toflash=cp.b a2000000 $destaddr $filesize reflash=tftp $destaddr $bootfile && run clearflash && run toflash flashkernel=setenv destaddr 40000 && setenv bootfile uImage && tftp && run toflh flashroot=setenv destaddr 140000 && setenv bootfile rootfs.arm_nofpu.jffs2&& th retarget_fast=setenv bootargs $bootargs_fast && setenv bootcmd $bootcmd_fast &&v fastboot=run clearflash && run flashkernel && run flashroot && run retarget_fast destaddr=140000 bootfile=rootfs.arm_nofpu.jffs2 filesize=9ee2bc fileaddr=A2000000 bootargs_fast=console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 reboot=cold,har3 bootargs=console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 reboot=cold,hard ro 3 pwr_gpio=mw 40e00058 a4254010 ; mw 40e00024 10000000 ; mw 40e0000c d182b9f8 pwr_on=mw 40e00018 10000000 preboot=echo Emable Power ; run pwr_gpio ; run pwr_on bootcmd=run preboot ; cp.b 40000 a2000000 100000 && bootm bootdelay=1 serverip=172.16.10.11 ipaddr=172.16.10.10 stdin=serial stdout=serial stderr=serial Environment size: 1420/4092 bytes GUM> On 7/25/07, Peter Lu <pl...@gm...> wrote: > > Hi, > > I'm trying to load a new rootfs to my Gumstix and hitting a "bad magic" > error in uboot. I followed the instructions to re-write flash via tftp per: > > http://docwiki.gumstix.org/Replacing_the_filesystem_image > > and the process completed without error. > > I've tried both the .jffs2 I built as well as the pre-built one at > sourceforge: > > http://sourceforge.net/project/showfiles.php?group_id=98784 > > I've googled this issue and found a couple of similar issues others had, > but have not been able to find any relevant solution. > > Thanks for any help. > > > ====== > > U-Boot 1.1.4 (Aug 1 2006 - > 10:47:14) > > > *** Welcome to Gumstix > *** > > > U-Boot code: A3F00000 -> A3F25D1C BSS: -> > A3F5AE38 > RAM > Configuration: > Bank #0: a0000000 64 > MB > Flash: 16 > MB > SMC91C1111-0 > > Can't overwrite > "serial#" > Net: > SMC91C1111-0 > Hit any key to stop autoboot: > 0 > Emable > Power > ## Booting image at a2000000 > ... > Bad Magic > Number > GUM> md > a2000000 > a2000000: 20031985 0000000c e41eb0b1 e0011985 ... > ............ > a2000010: 0000002b 7d266ee6 00000001 00000000 > +....n&}........ > a2000020: 00000002 46a5b099 00000403 12386f25 > .......F....%o8. > a2000030: 556683ff ff6e6962 e0021985 00000044 ..fUbin.....D... > > > > > |
From: Dave H. <dhy...@gm...> - 2007-07-25 15:16:50
|
Hi Peter, > I looked at my u-boot environment variables and the root seems to be set at > 140000 rather than 40000. The instructions for flashing rootfs uses 40000 > for the cp.b. Could someone clarify to me what should be done with the > .jffs2 file once I download it to a2000000? protect on 1:0-1 jerase all cp.b a2000000 40000 ${filesize} Actually, this looks like an attempt to do partitions, with the kernel located at 40000 and rootfs starting at 14000000, which would require some modifications to the kernel to accomodate. And if that's the case, then you can't use the instructions as provided. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Peter L. <pl...@gm...> - 2007-07-25 16:32:52
|
Hi, It looks like my set-up simply puts uImage at 40000 and rootfs at 140000, so the instructions I needed were: protect on 1:0-1 && erase all tftp a2000000 uImage cp.b a2000000 40000 ${filesize} tftp a2000000 rootfs.arm_nofpu.jffs2 cp.b a2000000 140000 ${filesize} Thanks for help. === On 7/25/07, Dave Hylands <dhy...@gm...> wrote: > > Hi Peter, > > > I looked at my u-boot environment variables and the root seems to be set > at > > 140000 rather than 40000. The instructions for flashing rootfs uses > 40000 > > for the cp.b. Could someone clarify to me what should be done with the > > .jffs2 file once I download it to a2000000? > > protect on 1:0-1 > jerase all > cp.b a2000000 40000 ${filesize} > > Actually, this looks like an attempt to do partitions, with the kernel > located at 40000 and rootfs starting at 14000000, which would require > some modifications to the kernel to accomodate. > > And if that's the case, then you can't use the instructions as provided. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@gu...> - 2007-07-25 19:45:55
|
On Jul 25, 2007, at 9:32 AM, Peter Lu wrote: > It looks like my set-up simply puts uImage at 40000 and rootfs at > 140000, so the > instructions I needed were: > > protect on 1:0-1 && erase all > tftp a2000000 uImage > cp.b a2000000 40000 ${filesize} > tftp a2000000 rootfs.arm_nofpu.jffs2 > cp.b a2000000 140000 ${filesize} That's basically what the new katinstall/katload stuff does (I imagine this was done by someone before that came along) -- I'd recommend switching to using the katinstall/katload system, with the uImage at the top of flash instead of the low end of flash, and JFFS2 in the middle of flash. I forget why I decided to do it that way rather than the way you've got it now, but I had a reason... Anyway though, if you do switch to doing it the katinstall/katload way, then you can dump a lot of your complexity and just use the same system a lot of other gumstix users do too now. C |
From: Peter L. <pl...@gm...> - 2007-07-26 16:05:45
|
Hi, The method of booting I described works for Gumstix rev 1090 but I'm now using rev 1479 and things break. Previously, because uImage gets loaded to RAM at a2000000 from flash 40000 (rootfs then loads to a2100000), bootm just worked. However, I believe the new setup requires: Using static partitions on Gumstix Flash ROM Creating 3 MTD partitions on "Gumstix Flash ROM": 0x00000000-0x00040000 : "Bootloader" 0x00040000-0x00f00000 : "RootFS" 0x00f00000-0x01000000 : "Kernel" so I believe the new flashing commands should be: protect on 1:0-1 && erase all tftp a2000000 uImage cp.b a2000000 f00000 ${filesize} tftp a2000000 rootfs.arm_nofpu.jffs2 cp.b a2000000 40000 ${filesize} But I don't know what the new bootcmd and bootargs environment variables should be. The _old_ ones (corresponding to uImage@40000 and rootfs@140000) were: bootargs=console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 reboot=cold,hard ro 3 bootcmd=run preboot ; cp.b 40000 a2000000 100000 && bootm I've tried "cp.b f00000 a2000000 100000 && bootm" and "cp.b f00000 a2ec0000 100000 && bootm a2ec0000" but end up with kernel panics because the rootfs is not found. Do I need to change root= in bootargs? I will look at katinstall/katload when I have time, but I just want to understand the nitty-gritty basics right now. Thanks for the info and any help. On 7/25/07, Craig Hughes <cr...@gu...> wrote: > > On Jul 25, 2007, at 9:32 AM, Peter Lu wrote: > > > It looks like my set-up simply puts uImage at 40000 and rootfs at > > 140000, so the > > instructions I needed were: > > > > protect on 1:0-1 && erase all > > tftp a2000000 uImage > > cp.b a2000000 40000 ${filesize} > > tftp a2000000 rootfs.arm_nofpu.jffs2 > > cp.b a2000000 140000 ${filesize} > > That's basically what the new katinstall/katload stuff does (I > imagine this was done by someone before that came along) -- I'd > recommend switching to using the katinstall/katload system, with the > uImage at the top of flash instead of the low end of flash, and JFFS2 > in the middle of flash. I forget why I decided to do it that way > rather than the way you've got it now, but I had a reason... Anyway > though, if you do switch to doing it the katinstall/katload way, then > you can dump a lot of your complexity and just use the same system a > lot of other gumstix users do too now. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Dave H. <dhy...@gm...> - 2007-07-26 16:10:40
|
Hi Peter, > bootargs=console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 reboot=cold,hard > ro 3 You at least need root=1f01 instead of 1f02 I don't recall exactly when that changed, but that could explain why your rootfs isn't being found. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Peter L. <pl...@gm...> - 2007-07-26 16:56:03
|
Hi, The root=1f01 seems to get me further, with rootfs found, but I'm still stuck on: XScale DSP coprocessor detected. VFS: Mounted root (jffs2 filesystem) readonly. Freeing init memory: 120K This is the case with either "cp.b f00000 a2000000 100000 && bootm" or "cp.b f00000 a2ec0000 100000 && bootm a2ec0000" Are there other bootcmd or bootargs things I need to change/add? I think the code built properly, so it should be just issues with code loading and execution. Thanks for help. On 7/26/07, Dave Hylands <dhy...@gm...> wrote: > > Hi Peter, > > > bootargs=console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 > reboot=cold,hard > > ro 3 > > You at least need root=1f01 instead of 1f02 > > I don't recall exactly when that changed, but that could explain why > your rootfs isn't being found. > > -- > Dave Hylands > Vancouver, BC, Canada > http://www.DaveHylands.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@gu...> - 2007-07-26 17:48:24
|
On Jul 26, 2007, at 9:56 AM, Peter Lu wrote: > Hi, > > The root=1f01 seems to get me further, with rootfs found, but I'm > still stuck on: > > XScale DSP coprocessor detected. > VFS: Mounted root (jffs2 filesystem) readonly. > Freeing init memory: 120K That's because you're using "erase" to erase the rootfs space in flash, rather than jerase. jerase writes the JFFS2 "cleanmarker" into empty sectors, which means linux doesn't need to scan all of that space, erase it, then write the cleanmarkers in before mounting the FS for the first time. If you let the thing run for a few minutes when you get to this point in your booting, it'll work -- it just needs time to scan all of flash and erase/write cleanmarkers in there. C |
From: Peter L. <pl...@gm...> - 2007-07-26 20:14:42
|
Hi, I used jerase instead of erase and the Bad Magic Number error crops up again. The bootcmd does a "cp.b f00000 a2000000 100000 && bootm" so the contents at a2000000 are: ## Booting image at a2000000 ... Bad Magic Number GUM> md a2000000 a2000000: 00010105 00000008 8414a000 986a0d00 ..............j. a2000010: 008000a0 008000a0 8a12feeb 00020205 ................ a2000020: 616d4975 00006567 00000000 00000000 uImage.......... a2000030: 00000000 00000000 00000000 00000000 ................ a2000040: e1a00000 e1a00000 e1a00000 e1a00000 ................ a2000050: e1a00000 e1a00000 e1a00000 e1a00000 ................ a2000060: ea000002 016f2818 00000000 000d6a98 .....(o......j.. a2000070: e1a07001 e1a08002 e10f2000 e3120003 .p....... ...... a2000080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... .. a2000090: e38220c0 e121f002 e3cf201f e2823801 . ....!.. ...8.. a20000a0: e4920020 e1320003 1afffffc ee070f9a .....2......... a20000b0: ee070f17 ee110f10 e3c00005 e3c00a01 ................ a20000c0: ee010f10 00000000 00000000 00000000 ................ a20000d0: 00000000 00000000 00000000 00000000 ................ a20000e0: e28f00cc e890307e e0500001 0a00000a ....~0....P..... a20000f0: e0855000 e0866000 e08cc000 e0822000 .P...`....... .. GUM> ls Scanning JFFS2 FS: ............... done. drwxr-xr-x 0 Thu Jul 26 08:37:56 2007 bin drwxr-xr-x 0 Thu Jul 26 08:35:43 2007 dev drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 etc drwxr-xr-x 0 Mon Nov 22 17:20:58 1999 home drwxr-xr-x 0 Thu Jul 26 08:37:45 2007 include drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 lib drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 mnt drwxr-xr-x 0 Mon Nov 22 17:21:08 1999 opt drwxr-xr-x 0 Wed Nov 03 00:54:07 1999 proc drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 root drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 sbin drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 sys drwxr-xr-x 0 Thu Jun 29 23:20:38 2000 tmp drwxr-xr-x 0 Thu Jul 26 06:53:52 2007 usr It looks like the rootfs can be found via the u-boot ls scan. I don't know why jerase would work differently from erase as far as detection of the uImage is concerned, since it seems to apply only to the rootfs scan. My autoscr script to program flash is: protect on 1:0-1 && jerase all tftp a2000000 uImage cp.b a2000000 f00000 ${filesize} tftp a2000000 rootfs.arm_nofpu.jffs2 cp.b a2000000 40000 ${filesize} Thanks for any suggestions. On 7/26/07, Craig Hughes <cr...@gu...> wrote: > > On Jul 26, 2007, at 9:56 AM, Peter Lu wrote: > > > Hi, > > > > The root=1f01 seems to get me further, with rootfs found, but I'm > > still stuck on: > > > > XScale DSP coprocessor detected. > > VFS: Mounted root (jffs2 filesystem) readonly. > > Freeing init memory: 120K > > That's because you're using "erase" to erase the rootfs space in > flash, rather than jerase. jerase writes the JFFS2 "cleanmarker" > into empty sectors, which means linux doesn't need to scan all of > that space, erase it, then write the cleanmarkers in before mounting > the FS for the first time. If you let the thing run for a few > minutes when you get to this point in your booting, it'll work -- it > just needs time to scan all of flash and erase/write cleanmarkers in > there. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Craig H. <cr...@gu...> - 2007-07-26 23:27:40
|
On Jul 26, 2007, at 1:14 PM, Peter Lu wrote: > jerase all Can't do that. Only jerase the part where the rootfs is going. You need to use regular erase for the part where your uImage is going, and for where you install u-boot (which you're not doing here, but you'd need erase not jerase if you were). If you are using a recent u-boot from the buildroot, the best way to go is use the "katinstall" command to write uImage to the right place and erase that space properly first. C |
From: Peter L. <pl...@gm...> - 2007-07-26 20:29:49
|
Somehow, after doing erase verses jerase, the write to flash results in different data for the first 3 longwords. Note how after erase, the flash to f00000 has 56190527 4399384a 9434a846 while after jerase, the flash has 00010105 00000008 8414a000. So, the u-boot software is doing something different for jerase or erase even on operations like cp.b that ensue the erasure. I'm confused. Please help me. Copy to Flash... done GUM> md f00000 00f00000: 56190527 4399384a 9434a846 986a0d00 '..VJ8.CF.4...j. 00f00010: 008000a0 008000a0 8a12feeb 00020205 ................ 00f00020: 616d4975 00006567 00000000 00000000 uImage.......... 00f00030: 00000000 00000000 00000000 00000000 ................ 00f00040: e1a00000 e1a00000 e1a00000 e1a00000 ................ 00f00050: e1a00000 e1a00000 e1a00000 e1a00000 ................ 00f00060: ea000002 016f2818 00000000 000d6a98 .....(o......j.. 00f00070: e1a07001 e1a08002 e10f2000 e3120003 .p....... ...... 00f00080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... .. 00f00090: e38220c0 e121f002 e3cf201f e2823801 . ....!.. ...8.. 00f000a0: e4920020 e1320003 1afffffc ee070f9a .....2......... 00f000b0: ee070f17 ee110f10 e3c00005 e3c00a01 ................ 00f000c0: ee010f10 00000000 00000000 00000000 ................ 00f000d0: 00000000 00000000 00000000 00000000 ................ 00f000e0: e28f00cc e890307e e0500001 0a00000a ....~0....P..... 00f000f0: e0855000 e0866000 e08cc000 e0822000 .P...`....... .. GUM> cp.b f00000 a2000000 100000 GUM> md a2000000 a2000000: 56190527 4399384a 9434a846 986a0d00 '..VJ8.CF.4...j. a2000010: 008000a0 008000a0 8a12feeb 00020205 ................ a2000020: 616d4975 00006567 00000000 00000000 uImage.......... a2000030: 00000000 00000000 00000000 00000000 ................ a2000040: e1a00000 e1a00000 e1a00000 e1a00000 ................ a2000050: e1a00000 e1a00000 e1a00000 e1a00000 ................ a2000060: ea000002 016f2818 00000000 000d6a98 .....(o......j.. a2000070: e1a07001 e1a08002 e10f2000 e3120003 .p....... ...... a2000080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... .. On 7/26/07, Peter Lu <pl...@gm...> wrote: > > Hi, > > I used jerase instead of erase and the Bad Magic Number error crops up > again. The bootcmd does a "cp.b f00000 a2000000 100000 && bootm" so the > contents at a2000000 are: > > ## Booting image at a2000000 > ... > Bad Magic > Number > GUM> md > a2000000 > a2000000: 00010105 00000008 8414a000 986a0d00 > ..............j. > a2000010: 008000a0 008000a0 8a12feeb 00020205 > ................ > a2000020: 616d4975 00006567 00000000 00000000 > uImage.......... > a2000030: 00000000 00000000 00000000 00000000 > ................ > a2000040: e1a00000 e1a00000 e1a00000 e1a00000 > ................ > a2000050: e1a00000 e1a00000 e1a00000 e1a00000 > ................ > a2000060: ea000002 016f2818 00000000 000d6a98 > .....(o......j.. > a2000070: e1a07001 e1a08002 e10f2000 e3120003 .p....... > ...... > a2000080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... > .. > a2000090: e38220c0 e121f002 e3cf201f e2823801 . ....!.. > ...8.. > a20000a0: e4920020 e1320003 1afffffc ee070f9a > .....2......... > a20000b0: ee070f17 ee110f10 e3c00005 e3c00a01 > ................ > a20000c0: ee010f10 00000000 00000000 00000000 > ................ > a20000d0: 00000000 00000000 00000000 00000000 > ................ > a20000e0: e28f00cc e890307e e0500001 0a00000a > ....~0....P..... > a20000f0: e0855000 e0866000 e08cc000 e0822000 .P...`....... > .. > GUM> > ls > Scanning JFFS2 FS: ............... > done. > drwxr-xr-x 0 Thu Jul 26 08:37:56 2007 > bin > drwxr-xr-x 0 Thu Jul 26 08:35:43 2007 > dev > drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 > etc > drwxr-xr-x 0 Mon Nov 22 17:20:58 1999 > home > drwxr-xr-x 0 Thu Jul 26 08:37:45 2007 > include > drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 > lib > drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 > mnt > drwxr-xr-x 0 Mon Nov 22 17:21:08 1999 > opt > drwxr-xr-x 0 Wed Nov 03 00:54:07 1999 > proc > drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 > root > drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 > sbin > drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 > sys > drwxr-xr-x 0 Thu Jun 29 23:20:38 2000 > tmp > drwxr-xr-x 0 Thu Jul 26 06:53:52 2007 > usr > > It looks like the rootfs can be found via the u-boot ls scan. > > I don't know why jerase would work differently from erase as far as > detection of the uImage is concerned, since it seems to apply only to the > rootfs scan. My autoscr script to program flash is: > > protect on 1:0-1 && jerase all > tftp a2000000 uImage > cp.b a2000000 f00000 ${filesize} > tftp a2000000 rootfs.arm_nofpu.jffs2 > cp.b a2000000 40000 ${filesize} > > Thanks for any suggestions. > > > On 7/26/07, Craig Hughes <cr...@gu...> wrote: > > > > On Jul 26, 2007, at 9:56 AM, Peter Lu wrote: > > > > > Hi, > > > > > > The root=1f01 seems to get me further, with rootfs found, but I'm > > > still stuck on: > > > > > > XScale DSP coprocessor detected. > > > VFS: Mounted root (jffs2 filesystem) readonly. > > > Freeing init memory: 120K > > > > That's because you're using "erase" to erase the rootfs space in > > flash, rather than jerase. jerase writes the JFFS2 "cleanmarker" > > into empty sectors, which means linux doesn't need to scan all of > > that space, erase it, then write the cleanmarkers in before mounting > > the FS for the first time. If you let the thing run for a few > > minutes when you get to this point in your booting, it'll work -- it > > just needs time to scan all of flash and erase/write cleanmarkers in > > there. > > > > C > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > |
From: Peter L. <pl...@gm...> - 2007-07-26 20:53:09
|
It's clear that after a jerase, the first 3 longwords are mangled on a cp.b, so they are neither the original values 20031985 0000000c e41eb0b1 nor the expected new values 56190527 4399384a 9434a84, ending up as 00010105 00000008 8414a000. I suppose I should do a separate, independent erase of the f00000 region so that the uImage header is not corrupted. Is this scheme documented anywhere? Am I interpreting things correctly? BTW, the init memory hang problem did not resolve itself even after some 15 minutes, so I think it's a permanent failure. GUM> md a2000000 a2000000: 56190527 4399384a 9434a846 986a0d00 '..VJ8.CF.4...j. a2000010: 008000a0 008000a0 8a12feeb 00020205 ................ a2000020: 616d4975 00006567 00000000 00000000 uImage.......... a2000030: 00000000 00000000 00000000 00000000 ................ a2000040: e1a00000 e1a00000 e1a00000 e1a00000 ................ a2000050: e1a00000 e1a00000 e1a00000 e1a00000 ................ a2000060: ea000002 016f2818 00000000 000d6a98 .....(o......j.. a2000070: e1a07001 e1a08002 e10f2000 e3120003 .p....... ...... a2000080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... .. a2000090: e38220c0 e121f002 e3cf201f e2823801 . ....!.. ...8.. a20000a0: e4920020 e1320003 1afffffc ee070f9a .....2......... a20000b0: ee070f17 ee110f10 e3c00005 e3c00a01 ................ a20000c0: ee010f10 00000000 00000000 00000000 ................ a20000d0: 00000000 00000000 00000000 00000000 ................ a20000e0: e28f00cc e890307e e0500001 0a00000a ....~0....P..... a20000f0: e0855000 e0866000 e08cc000 e0822000 .P...`....... .. GUM> md f00000 00f00000: 20031985 0000000c e41eb0b1 ffffffff ... ............ 00f00010: ffffffff ffffffff ffffffff ffffffff ................ 00f00020: ffffffff ffffffff ffffffff ffffffff ................ 00f00030: ffffffff ffffffff ffffffff ffffffff ................ 00f00040: ffffffff ffffffff ffffffff ffffffff ................ 00f00050: ffffffff ffffffff ffffffff ffffffff ................ 00f00060: ffffffff ffffffff ffffffff ffffffff ................ 00f00070: ffffffff ffffffff ffffffff ffffffff ................ 00f00080: ffffffff ffffffff ffffffff ffffffff ................ 00f00090: ffffffff ffffffff ffffffff ffffffff ................ 00f000a0: ffffffff ffffffff ffffffff ffffffff ................ 00f000b0: ffffffff ffffffff ffffffff ffffffff ................ 00f000c0: ffffffff ffffffff ffffffff ffffffff ................ 00f000d0: ffffffff ffffffff ffffffff ffffffff ................ 00f000e0: ffffffff ffffffff ffffffff ffffffff ................ 00f000f0: ffffffff ffffffff ffffffff ffffffff ................ GUM> cp.b a2000000 f00000 ${filesize} Copy to Flash... done GUM> md f00000 00f00000: 00010105 00000008 8414a000 986a0d00 ..............j. 00f00010: 008000a0 008000a0 8a12feeb 00020205 ................ 00f00020: 616d4975 00006567 00000000 00000000 uImage.......... 00f00030: 00000000 00000000 00000000 00000000 ................ 00f00040: e1a00000 e1a00000 e1a00000 e1a00000 ................ 00f00050: e1a00000 e1a00000 e1a00000 e1a00000 ................ 00f00060: ea000002 016f2818 00000000 000d6a98 .....(o......j.. 00f00070: e1a07001 e1a08002 e10f2000 e3120003 .p....... ...... 00f00080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... .. 00f00090: e38220c0 e121f002 e3cf201f e2823801 . ....!.. ...8.. 00f000a0: e4920020 e1320003 1afffffc ee070f9a .....2......... 00f000b0: ee070f17 ee110f10 e3c00005 e3c00a01 ................ 00f000c0: ee010f10 00000000 00000000 00000000 ................ 00f000d0: 00000000 00000000 00000000 00000000 ................ 00f000e0: e28f00cc e890307e e0500001 0a00000a ....~0....P..... 00f000f0: e0855000 e0866000 e08cc000 e0822000 .P...`....... .. GUM> On 7/26/07, Peter Lu <pl...@gm...> wrote: > > Somehow, after doing erase verses jerase, the write to flash results in > different data for the first 3 longwords. Note how after erase, the flash > to f00000 has 56190527 4399384a 9434a846 while after jerase, the flash has > 00010105 00000008 8414a000. So, the u-boot software is doing something > different for jerase or erase even on operations like cp.b that ensue the > erasure. > > I'm confused. Please help me. > > Copy to Flash... > done > GUM> md > f00000 > 00f00000: 56190527 4399384a 9434a846 986a0d00 > '..VJ8.CF.4...j. > 00f00010: 008000a0 008000a0 8a12feeb 00020205 > ................ > 00f00020: 616d4975 00006567 00000000 00000000 > uImage.......... > 00f00030: 00000000 00000000 00000000 00000000 > ................ > 00f00040: e1a00000 e1a00000 e1a00000 e1a00000 > ................ > 00f00050: e1a00000 e1a00000 e1a00000 e1a00000 > ................ > 00f00060: ea000002 016f2818 00000000 000d6a98 > .....(o......j.. > 00f00070: e1a07001 e1a08002 e10f2000 e3120003 .p....... > ...... > 00f00080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... > .. > 00f00090: e38220c0 e121f002 e3cf201f e2823801 . ....!.. > ...8.. > 00f000a0: e4920020 e1320003 1afffffc ee070f9a > .....2......... > 00f000b0: ee070f17 ee110f10 e3c00005 e3c00a01 > ................ > 00f000c0: ee010f10 00000000 00000000 00000000 > ................ > 00f000d0: 00000000 00000000 00000000 00000000 > ................ > 00f000e0: e28f00cc e890307e e0500001 0a00000a > ....~0....P..... > 00f000f0: e0855000 e0866000 e08cc000 e0822000 .P...`....... > .. > GUM> cp.b f00000 a2000000 > 100000 > GUM> md > a2000000 > a2000000: 56190527 4399384a 9434a846 986a0d00 > '..VJ8.CF.4...j. > a2000010: 008000a0 008000a0 8a12feeb 00020205 > ................ > a2000020: 616d4975 00006567 00000000 00000000 > uImage.......... > a2000030: 00000000 00000000 00000000 00000000 > ................ > a2000040: e1a00000 e1a00000 e1a00000 e1a00000 > ................ > a2000050: e1a00000 e1a00000 e1a00000 e1a00000 > ................ > a2000060: ea000002 016f2818 00000000 000d6a98 > .....(o......j.. > a2000070: e1a07001 e1a08002 e10f2000 e3120003 .p....... > ...... > a2000080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... > .. > > On 7/26/07, Peter Lu <pl...@gm...> wrote: > > > > Hi, > > > > I used jerase instead of erase and the Bad Magic Number error crops up > > again. The bootcmd does a "cp.b f00000 a2000000 100000 && bootm" so the > > contents at a2000000 are: > > > > ## Booting image at a2000000 > > ... > > Bad Magic > > Number > > GUM> md > > a2000000 > > a2000000: 00010105 00000008 8414a000 986a0d00 > > ..............j. > > a2000010: 008000a0 008000a0 8a12feeb 00020205 > > ................ > > a2000020: 616d4975 00006567 00000000 00000000 > > uImage.......... > > a2000030: 00000000 00000000 00000000 00000000 > > ................ > > a2000040: e1a00000 e1a00000 e1a00000 e1a00000 > > ................ > > a2000050: e1a00000 e1a00000 e1a00000 e1a00000 > > ................ > > a2000060: ea000002 016f2818 00000000 000d6a98 > > .....(o......j.. > > a2000070: e1a07001 e1a08002 e10f2000 e3120003 .p....... > > ...... > > a2000080: 1a000001 e3a00017 ef123456 e10f2000 ........V4... > > .. > > a2000090: e38220c0 e121f002 e3cf201f e2823801 . ....!.. > > ...8.. > > a20000a0: e4920020 e1320003 1afffffc ee070f9a > > .....2......... > > a20000b0: ee070f17 ee110f10 e3c00005 e3c00a01 > > ................ > > a20000c0: ee010f10 00000000 00000000 00000000 > > ................ > > a20000d0: 00000000 00000000 00000000 00000000 > > ................ > > a20000e0: e28f00cc e890307e e0500001 0a00000a > > ....~0....P..... > > a20000f0: e0855000 e0866000 e08cc000 e0822000 .P...`....... > > .. > > GUM> > > ls > > Scanning JFFS2 FS: ............... > > done. > > drwxr-xr-x 0 Thu Jul 26 08:37:56 2007 > > bin > > drwxr-xr-x 0 Thu Jul 26 08:35:43 2007 > > dev > > drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 > > etc > > drwxr-xr-x 0 Mon Nov 22 17:20:58 1999 > > home > > drwxr-xr-x 0 Thu Jul 26 08:37:45 2007 > > include > > drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 > > lib > > drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 > > mnt > > drwxr-xr-x 0 Mon Nov 22 17:21:08 1999 > > opt > > drwxr-xr-x 0 Wed Nov 03 00:54:07 1999 > > proc > > drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 > > root > > drwxr-xr-x 0 Thu Jul 26 08:37:57 2007 > > sbin > > drwxr-xr-x 0 Thu Jul 26 04:25:30 2007 > > sys > > drwxr-xr-x 0 Thu Jun 29 23:20:38 2000 > > tmp > > drwxr-xr-x 0 Thu Jul 26 06:53:52 2007 > > usr > > > > It looks like the rootfs can be found via the u-boot ls scan. > > > > I don't know why jerase would work differently from erase as far as > > detection of the uImage is concerned, since it seems to apply only to the > > rootfs scan. My autoscr script to program flash is: > > > > protect on 1:0-1 && jerase all > > tftp a2000000 uImage > > cp.b a2000000 f00000 ${filesize} > > tftp a2000000 rootfs.arm_nofpu.jffs2 > > cp.b a2000000 40000 ${filesize} > > > > Thanks for any suggestions. > > > > > > On 7/26/07, Craig Hughes <cr...@gu... > wrote: > > > > > > On Jul 26, 2007, at 9:56 AM, Peter Lu wrote: > > > > > > > Hi, > > > > > > > > The root=1f01 seems to get me further, with rootfs found, but I'm > > > > still stuck on: > > > > > > > > XScale DSP coprocessor detected. > > > > VFS: Mounted root (jffs2 filesystem) readonly. > > > > Freeing init memory: 120K > > > > > > That's because you're using "erase" to erase the rootfs space in > > > flash, rather than jerase. jerase writes the JFFS2 "cleanmarker" > > > into empty sectors, which means linux doesn't need to scan all of > > > that space, erase it, then write the cleanmarkers in before mounting > > > the FS for the first time. If you let the thing run for a few > > > minutes when you get to this point in your booting, it'll work -- it > > > just needs time to scan all of flash and erase/write cleanmarkers in > > > there. > > > > > > C > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a > > > browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > |
From: Craig H. <cr...@gu...> - 2007-07-26 23:29:41
|
On Jul 26, 2007, at 1:29 PM, Peter Lu wrote: > even on operations like cp.b that ensue the erasure cp.b does *not* ensure erasure. It will only turn bits off, not on. C |
From: Peter L. <pl...@gm...> - 2007-07-27 15:56:44
|
Hi, Thanks for the info. I now have a better understanding of what the "new" loading/booting mechanism requires. Basically, one would do (full) erasure of the flash regions where uImage and the rootfs goes and put down jffs2 "not-used" markers in the unused regions (I think 128 KB apart) so that the kernel doesn't have to look in them for the rootfs. Do you know where the uImage should go? Is a2000000 okay, as before? I can't seem to find the katinstall you mention and the Wiki page doesn't say much about it. Please provide me a little more info. Thanks. On 7/26/07, Craig Hughes <cr...@gu...> wrote: > > On Jul 26, 2007, at 1:29 PM, Peter Lu wrote: > > even on operations like cp.b that ensue the erasure > > > cp.b does *not* ensure erasure. It will only turn bits off, not on. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Craig H. <cr...@gu...> - 2007-07-27 18:38:14
|
On Jul 27, 2007, at 8:56 AM, Peter Lu wrote: > Thanks for the info. I now have a better understanding of what the > "new" loading/booting mechanism requires. Basically, one would do > (full) erasure of the flash regions where uImage and the rootfs > goes and put down jffs2 "not-used" markers in the unused regions (I > think 128 KB apart) so that the kernel doesn't have to look in them > for the rootfs. > > Do you know where the uImage should go? Is a2000000 okay, as before? > > I can't seem to find the katinstall you mention and the Wiki page > doesn't say much about it. Please provide me a little more info. When the switch to the new partitioning system happened, I also added a new command called "katinstall" to u-boot, which will do an erase and then copy. It basically works as follows you type: katinstall 100000 and it does, effectively: x = (size of flash) - 0x100000 erase x through (size of flash) cp.l a2000000 (0x100000/4) So it does all the math for you to place the uImage at the top of flash, regardless of the size of your flash (ie 4MB vs 16MB vs 32MB). You can then do this for a "reinstall" procedure: pro off 1:0-1 erase 1:0-1 <fetch uboot.bin> cp.b a2000000 0 $filesize pro on 1:0-1 jera all <fetch rootfs.arm_nofpu.jffs) cp.b a2000000 40000 $filesize <fetch uImage> katinstall 100000 reset The re-installing u-boot part is optional of course. C |
From: Peter L. <pl...@gm...> - 2007-07-27 20:58:08
|
Hi, OK, I believe this does the same thing as what I have for a 16MB flash in my autoscr... protect on 1:0-1 && jerase all protect on 1:0-1 && erase f00000 +100000 tftp a2000000 rootfs.arm_nofpu.jffs2 cp.b a2000000 40000 ${filesize} tftp a2000000 uImage cp.b a2000000 f00000 ${filesize} The rootfs gets over-written over the jffs2 tags (3 long words every 128KB) in flash so that linux (MTD file system?) can easily identify the used verses unused regions. I'm curious as to why the (used and unused) jffs2 tags are needed, when they weren't before. Of course, the bootcmd needs to have "cp.b f00000 a2000000 && bootm" So, overall, the load and run scheme hasn't really changed as far as linux is concerned. I don't know why I'm having so much trouble getting a 1479+ Gumstix loaded and running, even with the new jerase and root=1f01 in place. Perhaps my uImage has run-time errors even though things build without error (after several typo-style source-code clean-ups). Please let me know if a particular Gumstix revision after 1400 is stable and build-able/ run-able out of the box. I'm finding that I need to a lot of manual fixes (often just typos) to just get packages built. Thanks for help. On 7/27/07, Craig Hughes <cr...@gu...> wrote: > > On Jul 27, 2007, at 8:56 AM, Peter Lu wrote: > > > Thanks for the info. I now have a better understanding of what the > > "new" loading/booting mechanism requires. Basically, one would do > > (full) erasure of the flash regions where uImage and the rootfs > > goes and put down jffs2 "not-used" markers in the unused regions (I > > think 128 KB apart) so that the kernel doesn't have to look in them > > for the rootfs. > > > > Do you know where the uImage should go? Is a2000000 okay, as before? > > > > I can't seem to find the katinstall you mention and the Wiki page > > doesn't say much about it. Please provide me a little more info. > > When the switch to the new partitioning system happened, I also added > a new command called "katinstall" to u-boot, which will do an erase > and then copy. It basically works as follows > > you type: > > katinstall 100000 > > and it does, effectively: > > x = (size of flash) - 0x100000 > erase x through (size of flash) > cp.l a2000000 (0x100000/4) > > So it does all the math for you to place the uImage at the top of > flash, regardless of the size of your flash (ie 4MB vs 16MB vs > 32MB). You can then do this for a "reinstall" procedure: > > pro off 1:0-1 > erase 1:0-1 > <fetch uboot.bin> > cp.b a2000000 0 $filesize > pro on 1:0-1 > jera all > <fetch rootfs.arm_nofpu.jffs) > cp.b a2000000 40000 $filesize > <fetch uImage> > katinstall 100000 > reset > > The re-installing u-boot part is optional of course. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Peter L. <pl...@gm...> - 2007-07-31 01:10:53
|
Hi, I'm unable to get a rev 1482 build running on my 16MB board. The cross-compiled build completes without error and the uImage and rootfs.arm_nofpu.jffs are created properly. I download and flash using: protect on 1:0-1 && jerase all protect on 1:0-1 && erase f00000 +100000 tftp a2000000 rootfs.arm_nofpu.jffs2 cp.b a2000000 40000 ${filesize} tftp a2000000 uImage cp.b a2000000 f00000 ${filesize} and my u-boot environment has: bootargs=ttyS0,115200n8 root=1f01 rootfstype=jffs2 reboot=cold,hard ro 3 bootcmd=run preboot ; cp.b f00000 a2000000 100000 && bootm but when I do "boot" I get: ## Booting image at a2000000 ... Image Name: uImage Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 879252 Bytes = 858.6kB Load Address: a0008000 Entry Point: a0008000 OK Starting kernel ... and nothing happens (I waited 5+ minutes). Note that I am able to use the exact same set-up to boot a rev 1161 build I made (same as stable build released at Sourceforge), with rootfs at 40000 and uImage at f00000. The login prompt show up about 30 seconds after "Starting kernel ...." Build rev 1161 uses the old way of specifying partitions in gumstix-flash.c: static struct mtd_partition gumstix_flash_partitions[] = { { .name = "Bootloader", .size = 0x00040000, .offset = FLASH_ADDR },{ .name = "RootFS", .size = MTDPART_SIZ_FULL, .offset = MTDPART_OFS_APPEND } }; while rev 1482 has: static struct mtd_partition gumstix_flash_partitions[] = { { .name = "Bootloader", .size = 0x00040000, .offset = FLASH_ADDR },{ .name = "RootFS", .size = MTDPART_SIZ_REMAINDER, .offset = MTDPART_OFS_NXTBLK },{ .name = "Kernel", .size = 0x00100000, .offset = MTDPART_OFS_NXTBLK } }; I don't know what the difference between OFS_APPEND and OFS_NXTBLK is, but guess that the latter does some scanning through the Flash region. Please tell me what I need to do to get rev 1482 running, whether it's using different U-boot environment variables or build parameters. Thanks for all help. On 7/27/07, Peter Lu <pl...@gm...> wrote: > > Hi, > > OK, I believe this does the same thing as what I have for a 16MB flash in > my autoscr... > > protect on 1:0-1 && jerase all > protect on 1:0-1 && erase f00000 +100000 > tftp a2000000 rootfs.arm_nofpu.jffs2 > cp.b a2000000 40000 ${filesize} > tftp a2000000 uImage > cp.b a2000000 f00000 ${filesize} > > The rootfs gets over-written over the jffs2 tags (3 long words every > 128KB) in flash so that linux (MTD file system?) can easily identify the > used verses unused regions. I'm curious as to why the (used and unused) > jffs2 tags are needed, when they weren't before. > > Of course, the bootcmd needs to have "cp.b f00000 a2000000 && bootm" > > So, overall, the load and run scheme hasn't really changed as far as linux > is concerned. I don't know why I'm having so much trouble getting a 1479+ > Gumstix loaded and running, even with the new jerase and root=1f01 in > place. Perhaps my uImage has run-time errors even though things build > without error (after several typo-style source-code clean-ups). > > Please let me know if a particular Gumstix revision after 1400 is stable > and build-able/ run-able out of the box. I'm finding that I need to a lot > of manual fixes (often just typos) to just get packages built. > > Thanks for help. > > > > On 7/27/07, Craig Hughes <cr...@gu...> wrote: > > > > On Jul 27, 2007, at 8:56 AM, Peter Lu wrote: > > > > > Thanks for the info. I now have a better understanding of what the > > > "new" loading/booting mechanism requires. Basically, one would do > > > (full) erasure of the flash regions where uImage and the rootfs > > > goes and put down jffs2 "not-used" markers in the unused regions (I > > > think 128 KB apart) so that the kernel doesn't have to look in them > > > for the rootfs. > > > > > > Do you know where the uImage should go? Is a2000000 okay, as before? > > > > > > I can't seem to find the katinstall you mention and the Wiki page > > > doesn't say much about it. Please provide me a little more info. > > > > When the switch to the new partitioning system happened, I also added > > a new command called "katinstall" to u-boot, which will do an erase > > and then copy. It basically works as follows > > > > you type: > > > > katinstall 100000 > > > > and it does, effectively: > > > > x = (size of flash) - 0x100000 > > erase x through (size of flash) > > cp.l a2000000 (0x100000/4) > > > > So it does all the math for you to place the uImage at the top of > > flash, regardless of the size of your flash (ie 4MB vs 16MB vs > > 32MB). You can then do this for a "reinstall" procedure: > > > > pro off 1:0-1 > > erase 1:0-1 > > <fetch uboot.bin> > > cp.b a2000000 0 $filesize > > pro on 1:0-1 > > jera all > > <fetch rootfs.arm_nofpu.jffs) > > cp.b a2000000 40000 $filesize > > <fetch uImage> > > katinstall 100000 > > reset > > > > The re-installing u-boot part is optional of course. > > > > C > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > |
From: Craig H. <cr...@gu...> - 2007-07-31 15:22:04
|
On Jul 30, 2007, at 6:10 PM, Peter Lu wrote: > bootargs=ttyS0,115200n8 root=1f01 rootfstype=jffs2 reboot=cold,hard > ro 3 Should be setenv bootargs console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 ro 3 You can leave out the "reboot=" which no longer does anything, and you missed the "console=" part of the ttyS0 thing. C |
From: Peter L. <pl...@gm...> - 2007-07-31 16:50:54
|
Hi, Thank you for catching my typo with the console=, which I inadvertently lost over time. The 1161 build now boots much faster, but the 1482 build (still) gets stuck at the "Freeing init memory 120K" line. Has there been some hardware-software incompatibility that was introduced in the last year, such that the (old prototype) hardware I have just doesn't run newer builds (without special mods)? I will be getting new hardware soon, so perhaps build 1482 will just work (fingers crossed). On 7/31/07, Craig Hughes <cr...@gu...> wrote: > > On Jul 30, 2007, at 6:10 PM, Peter Lu wrote: > > bootargs=ttyS0,115200n8 root=1f01 rootfstype=jffs2 reboot=cold,hard ro > 3 > > > Should be > > setenv bootargs console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 ro 3 > > You can leave out the "reboot=" which no longer does anything, and you > missed the "console=" part of the ttyS0 thing. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Craig H. <cr...@gu...> - 2007-07-31 17:39:45
|
On Jul 31, 2007, at 9:50 AM, Peter Lu wrote: > Thank you for catching my typo with the console=, which I > inadvertently lost over time. The 1161 build now boots much > faster, but the 1482 build (still) gets stuck at the "Freeing init > memory 120K" line. This is probably because you used "erase" instead of "jerase" to erase the JFFS2 space in flash -- if so, then on the first reboot, linux has to scan the entire JFFS2 partition, erase each unused block, and write a JFFS2 cleanmarker in there. This take quite a long time on XM or XLP gumstix -- just wait a few minutes and see if it comes back. > Has there been some hardware-software incompatibility that was > introduced in the last year, such that the (old prototype) hardware > I have just doesn't run newer builds (without special mods)? I > will be getting new hardware soon, so perhaps build 1482 will just > work (fingers crossed). No, the new code should work on old hardware, as long as you selected the correct settings in the buildroot config -- ie you aren't building for verdex then deploying on a connex or something. C |
From: Peter L. <pl...@gm...> - 2007-07-31 18:11:24
|
Hi, My autoscr says: protect on 1:0-1 && jerase all protect on 1:0-1 && erase f00000 +100000 tftp a2000000 rootfs.arm_nofpu.jffs2 cp.b a2000000 40000 ${filesize} tftp a2000000 uImage cp.b a2000000 f00000 ${filesize} so, I'm supposedly doing jerase. I even verified that jerase puts down 3-longword tags every 128kb block in the flash. I waited for over 10 minutes on the "Freeing init memory 128K" and so suspect that something is out of wack. I think you or someone else had indicated the the tag-scan takes a few minutes the first time around (if jerase weren't used). I'm rebuilding rev 1482 again from scratch to see what the new output offers. I've compared the .config files from 1482 and 1161 and don't see anything blatantly different. Thanks for the help. On 7/31/07, Craig Hughes <cr...@gu...> wrote: > > On Jul 31, 2007, at 9:50 AM, Peter Lu wrote: > > > Thank you for catching my typo with the console=, which I > > inadvertently lost over time. The 1161 build now boots much > > faster, but the 1482 build (still) gets stuck at the "Freeing init > > memory 120K" line. > > This is probably because you used "erase" instead of "jerase" to > erase the JFFS2 space in flash -- if so, then on the first reboot, > linux has to scan the entire JFFS2 partition, erase each unused > block, and write a JFFS2 cleanmarker in there. This take quite a > long time on XM or XLP gumstix -- just wait a few minutes and see if > it comes back. > > > Has there been some hardware-software incompatibility that was > > introduced in the last year, such that the (old prototype) hardware > > I have just doesn't run newer builds (without special mods)? I > > will be getting new hardware soon, so perhaps build 1482 will just > > work (fingers crossed). > > No, the new code should work on old hardware, as long as you selected > the correct settings in the buildroot config -- ie you aren't > building for verdex then deploying on a connex or something. > > C > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |
From: Peter L. <pl...@gm...> - 2007-08-01 15:35:12
|
Hi, I tracked down the reason why my initialization hangs. Apparently, default files in /etc such as inittab, fstab, and passwd do not exist in the 1482 revision (but do in 1161), which causes /sbin/init to not do anything. Could someone help me figure out how to get these set up "officially," or how to fix things locally if the build tools are busted? In the mean time, I'll try to copy stuff from build_arm_nofpu/root/etc in 1161 to that in 1482, to see if I can get things going. I believe there are others having the same problem. Also, if someone knows where the build area (sources) for /sbin/init is, please let me know, as I would put some printk's in the code to track my initialization progress. Thanks for all help. On 7/31/07, Peter Lu <pl...@gm...> wrote: > > Hi, > > My autoscr says: > > protect on 1:0-1 && jerase all > protect on 1:0-1 && erase f00000 +100000 > tftp a2000000 rootfs.arm_nofpu.jffs2 > cp.b a2000000 40000 ${filesize} > tftp a2000000 uImage > cp.b a2000000 f00000 ${filesize} > > so, I'm supposedly doing jerase. I even verified that jerase puts down > 3-longword tags every 128kb block in the flash. > > I waited for over 10 minutes on the "Freeing init memory 128K" and so > suspect that something is out of wack. I think you or someone else had > indicated the the tag-scan takes a few minutes the first time around (if > jerase weren't used). > > I'm rebuilding rev 1482 again from scratch to see what the new > output offers. I've compared the .config files from 1482 and 1161 and > don't see anything blatantly different. > > Thanks for the help. > > > > On 7/31/07, Craig Hughes <cr...@gu...> wrote: > > > > On Jul 31, 2007, at 9:50 AM, Peter Lu wrote: > > > > > Thank you for catching my typo with the console=, which I > > > inadvertently lost over time. The 1161 build now boots much > > > faster, but the 1482 build (still) gets stuck at the "Freeing init > > > memory 120K" line. > > > > This is probably because you used "erase" instead of "jerase" to > > erase the JFFS2 space in flash -- if so, then on the first reboot, > > linux has to scan the entire JFFS2 partition, erase each unused > > block, and write a JFFS2 cleanmarker in there. This take quite a > > long time on XM or XLP gumstix -- just wait a few minutes and see if > > it comes back. > > > > > Has there been some hardware-software incompatibility that was > > > introduced in the last year, such that the (old prototype) hardware > > > I have just doesn't run newer builds (without special mods)? I > > > will be getting new hardware soon, so perhaps build 1482 will just > > > work (fingers crossed). > > > > No, the new code should work on old hardware, as long as you selected > > the correct settings in the buildroot config -- ie you aren't > > building for verdex then deploying on a connex or something. > > > > C > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > gumstix-users mailing list > > gum...@li... > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > |
From: Peter L. <pl...@gm...> - 2007-08-01 15:55:57
|
Sorry, it looks like stuff in /etc just doesn't get re-created if build_am_nofpu/root is cleared out (for a "clean" build of the target FS). I managed to retrieve most of the config files, but /sbin/init still doesn't do much. I need to do printk's in /sbin/init to see what it is really doing. On 8/1/07, Peter Lu <pl...@gm...> wrote: > > Hi, > > I tracked down the reason why my initialization hangs. Apparently, > default files in /etc such as inittab, fstab, and passwd do not exist in the > 1482 revision (but do in 1161), which causes /sbin/init to not do anything. > > Could someone help me figure out how to get these set up "officially," or > how to fix things locally if the build tools are busted? In the mean time, > I'll try to copy stuff from build_arm_nofpu/root/etc in 1161 to that in > 1482, to see if I can get things going. I believe there are others having > the same problem. > > Also, if someone knows where the build area (sources) for /sbin/init is, > please let me know, as I would put some printk's in the code to track my > initialization progress. > > Thanks for all help. > > > > On 7/31/07, Peter Lu <pl...@gm...> wrote: > > > > Hi, > > > > My autoscr says: > > > > protect on 1:0-1 && jerase all > > protect on 1:0-1 && erase f00000 +100000 > > tftp a2000000 rootfs.arm_nofpu.jffs2 > > cp.b a2000000 40000 ${filesize} > > tftp a2000000 uImage > > cp.b a2000000 f00000 ${filesize} > > > > so, I'm supposedly doing jerase. I even verified that jerase puts down > > 3-longword tags every 128kb block in the flash. > > > > I waited for over 10 minutes on the "Freeing init memory 128K" and so > > suspect that something is out of wack. I think you or someone else had > > indicated the the tag-scan takes a few minutes the first time around (if > > jerase weren't used). > > > > I'm rebuilding rev 1482 again from scratch to see what the new > > output offers. I've compared the .config files from 1482 and 1161 and > > don't see anything blatantly different. > > > > Thanks for the help. > > > > > > > > On 7/31/07, Craig Hughes < cr...@gu...> wrote: > > > > > > On Jul 31, 2007, at 9:50 AM, Peter Lu wrote: > > > > > > > Thank you for catching my typo with the console=, which I > > > > inadvertently lost over time. The 1161 build now boots much > > > > faster, but the 1482 build (still) gets stuck at the "Freeing init > > > > memory 120K" line. > > > > > > This is probably because you used "erase" instead of "jerase" to > > > erase the JFFS2 space in flash -- if so, then on the first reboot, > > > linux has to scan the entire JFFS2 partition, erase each unused > > > block, and write a JFFS2 cleanmarker in there. This take quite a > > > long time on XM or XLP gumstix -- just wait a few minutes and see if > > > it comes back. > > > > > > > Has there been some hardware-software incompatibility that was > > > > introduced in the last year, such that the (old prototype) hardware > > > > I have just doesn't run newer builds (without special mods)? I > > > > will be getting new hardware soon, so perhaps build 1482 will just > > > > work (fingers crossed). > > > > > > No, the new code should work on old hardware, as long as you selected > > > the correct settings in the buildroot config -- ie you aren't > > > building for verdex then deploying on a connex or something. > > > > > > C > > > > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Splunk Inc. > > > Still grepping through log files to find problems? Stop. > > > Now Search log events and configuration files using AJAX and a > > > browser. > > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > _______________________________________________ > > > gumstix-users mailing list > > > gum...@li... > > > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > > > > > > > |
From: Dave H. <dhy...@gm...> - 2007-08-01 16:17:08
|
Hi Peter, On 8/1/07, Peter Lu <pl...@gm...> wrote: > Sorry, it looks like stuff in /etc just doesn't get re-created if > build_am_nofpu/root is cleared out (for a "clean" build of the target FS). > I managed to retrieve most of the config files, but /sbin/init still doesn't > do much. I need to do printk's in /sbin/init to see what it is really > doing. Try doing cd gumstix-buildroot/build_arm_nofpu rm -rf root There is a file called gumstix-buildroot/target/generic/skel.tar.gz which gets expanded and copied into the root directory, but only if the root directory itself doesn't exist. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |