From: Joel V. <vj...@pa...> - 2006-04-04 22:36:40
|
I built the rootfs.arm_nofpu.jffs2 from svn and flashed it to an xm400, but got a kernel panic and other errors on booting. I then followed the same procedure with a stock root_fs_arm.r773 from the sourceforge site, and it booted fine. The full output is below. What did I do wrong? (/home/vjoel/) C-Kermit>connect Connecting to /dev/ttyS0, speed 115200 Escape character: Ctrl-\ (ASCII 28, FS): enabled Type the escape character followed by C to get back, or followed by ? to see other options. ---------------------------------------------------- U-Boot 1.1.2 (Dec 30 2005 - 12:16:38) *** Welcome to Gumstix *** U-Boot code: A3F00000 -> A3F238B4 BSS: -> A3F58958 RAM Configuration: Bank #0: a0000000 64 MB Flash: 16 MB SMC91C1111-0 Hit any key to stop autoboot: 0 ### JFFS2 loading 'boot/uImage' to 0xa2000000 Scanning JFFS2 FS: Unknown node type: 2005 len 24 offset 0x0 . Unknown node type: 2005 len 24 offset 0x20000 | Unknown node type: 2005 len 24 offset 0x40000 Unknown node type: 2005 len 24 offset 0x60000 / Unknown node type: 2005 len 24 offset 0x80000 Unknown node type: 2005 len 24 offset 0xa0000 - Unknown node type: 2005 len 24 offset 0xc0000 Unknown node type: 2005 len 24 offset 0xe0000 \ Unknown node type: 2005 len 24 offset 0x100000 . Unknown node type: 2005 len 24 offset 0x120000 | Unknown node type: 2005 len 24 offset 0x140000 Unknown node type: 2005 len 24 offset 0x160000 ./ Unknown node type: 2005 len 24 offset 0x180000 Unknown node type: 2005 len 24 offset 0x1a0000 - Unknown node type: 2005 len 24 offset 0x1c0000 Unknown node type: 2005 len 24 offset 0x1e0000 \ Unknown node type: 2005 len 24 offset 0x200000 Unknown node type: 2005 len 24 offset 0x220000 | Unknown node type: 2005 len 24 offset 0x240000 . Unknown node type: 2005 len 24 offset 0x260000 / Unknown node type: 2005 len 24 offset 0x280000 Unknown node type: 2005 len 24 offset 0x2a0000 .- Unknown node type: 2005 len 24 offset 0x2c0000 Unknown node type: 2005 len 24 offset 0x2e0000 \ Unknown node type: 2005 len 24 offset 0x300000 Unknown node type: 2005 len 24 offset 0x320000 done. ### JFFS2 load complete: 744432 bytes loaded to 0xa2000000 ## Booting image at a2000000 ... Image Name: uImage Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 744368 Bytes = 726.9 kB Load Address: a0008000 Entry Point: a0008000 Verifying Checksum ... OK OK Starting kernel ... Linux version 2.6.15gum (vjoel@tumbleweed) (gcc version 3.4.5) #1 Thu Mar 30 15:32:53 PST 2006 CPU: XScale-PXA255 [69052d06] revision 6 (ARMv5TE) 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) CPU0: D VIVT undefined 5 cache CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets 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: 63280KB available (1235K code, 242K data, 56K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. Initializing Cryptographic API io scheduler noop registered pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 15) is a FFUART pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 14) is a BTUART pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 13) is a STUART pxa2xx-uart.3: ttyS3 at MMIO 0x41600000 (irq = 0) is a HWUART 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-0x01000000 : "RootFS" NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP reno registered TCP bic registered Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,2) -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 |
From: Alexandre P. N. <al...@om...> - 2006-04-05 00:41:42
|
Joel VanderWerf escreveu: >I built the rootfs.arm_nofpu.jffs2 from svn and flashed it to an xm400, >but got a kernel panic and other errors on booting. I then followed the >same procedure with a stock root_fs_arm.r773 from the sourceforge site, >and it booted fine. The full output is below. What did I do wrong? > >[cut] >Kernel command line: console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 > > Here is the problem, interrupt the boot process on u-boot and them type: setenv bootargs console=ttyS0,115200n8 root=1f01rootfstype=jffs2 saveenv or, in other words, replace 1f02 by 1f01, it's required since kernel 2.6.14 i think. Someone correct me if i'm wrong Alexandre |
From: Craig H. <cr...@gu...> - 2006-04-05 22:00:20
|
On Apr 4, 2006, at 5:41 PM, Alexandre Pereira Nunes wrote: > setenv bootargs console=ttyS0,115200n8 root=1f01rootfstype=jffs2 > saveenv > > or, in other words, replace 1f02 by 1f01, it's required since > kernel 2.6.14 i think. > > Someone correct me if i'm wrong You need a space after root=1f01 before rootfstype= C |
From: Joel V. <vj...@pa...> - 2006-04-07 21:19:16
|
Alexandre Pereira Nunes wrote: > Joel VanderWerf escreveu: > >> I built the rootfs.arm_nofpu.jffs2 from svn and flashed it to an xm400, >> but got a kernel panic and other errors on booting. I then followed the >> same procedure with a stock root_fs_arm.r773 from the sourceforge site, >> and it booted fine. The full output is below. What did I do wrong? >> >> [cut] >> Kernel command line: console=ttyS0,115200n8 root=1f02 rootfstype=jffs2 >> >> > > Here is the problem, interrupt the boot process on u-boot and them type: > > setenv bootargs console=ttyS0,115200n8 root=1f01rootfstype=jffs2 > saveenv > > or, in other words, replace 1f02 by 1f01, it's required since kernel > 2.6.14 i think. Ok, that is almost perfect. I used this for my bootargs: --- setenv bootargs console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 reboot=cold,hard saveenv --- However, there are still messages about "unknown node type" when booting (see below). Is that a problem? Also there is a long delay while looking for bluetooth (which is not present in the hw): --- Starting Bluetooth subsystem:Trying baud rate 57600... Set (GPIO,out,clear) via /proc/gpio/GPIO7 Set (GPIO,out,set) via /proc/gpio/GPIO7 No response after reset No response from BT module Trying baud rate 115200... Set (GPIO,out,clear) via /proc/gpio/GPIO7 Set (GPIO,out,set) via /proc/gpio/GPIO7 No response after reset No response from BT module Trying baud rate 921600... Set (GPIO,out,clear) via /proc/gpio/GPIO7 Set (GPIO,out,set) via /proc/gpio/GPIO7 No response after resetNo response from BT module Can't initialize device: Success --- However, after the delay, everything seems fine: I can build executables in the cross compiling environment and copy them over and run them I will try to remove bluetooth from the buildroot and see if that helps. U-Boot 1.1.2 (Dec 30 2005 - 12:16:38) *** Welcome to Gumstix *** U-Boot code: A3F00000 -> A3F238B4 BSS: -> A3F58958 RAM Configuration: Bank #0: a0000000 64 MB Flash: 16 MB SMC91C1111-0 Hit any key to stop autoboot: 0 ### JFFS2 loading 'boot/uImage' to 0xa2000000 Scanning JFFS2 FS: Unknown node type: 2005 len 24 offset 0x0 . Unknown node type: 2005 len 24 offset 0x20000 | Unknown node type: 2005 len 24 offset 0x40000 Unknown node type: 2005 len 24 offset 0x60000 / Unknown node type: 2005 len 24 offset 0x80000 It goes on like that for 125 lines (which is more lines then before, when the boot failed). -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 |
From: Craig H. <cr...@gu...> - 2006-04-07 21:41:52
|
On Apr 7, 2006, at 2:19 PM, Joel VanderWerf wrote: > setenv bootargs console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 > reboot=cold,hard > saveenv That should do it. > However, there are still messages about "unknown node type" when > booting > (see below). Is that a problem? Also there is a long delay while > looking > for bluetooth (which is not present in the hw): No, it's not a problem. I've updated u-boot since then to not print this warning message, but haven't put a new binary up at sf.net yet -- for now, just ignore those "errors", they are harmless. > --- > Starting Bluetooth subsystem:Trying baud rate 57600... > Set (GPIO,out,clear) via /proc/gpio/GPIO7 > Set (GPIO,out,set) via /proc/gpio/GPIO7 > No response after reset > No response from BT module > Trying baud rate 115200... > Set (GPIO,out,clear) via /proc/gpio/GPIO7 > Set (GPIO,out,set) via /proc/gpio/GPIO7 > No response after reset > No response from BT module > Trying baud rate 921600... > Set (GPIO,out,clear) via /proc/gpio/GPIO7 > Set (GPIO,out,set) via /proc/gpio/GPIO7 > No response after resetNo response from BT module > Can't initialize device: Success > --- > > > However, after the delay, everything seems fine: I can build > executables > in the cross compiling environment and copy them over and run them If you don't have bluetooth on the gumstix, then you can stop BT from trying to start on boot by removing or renaming /etc/init.d/ S30bluetooth -- if you want, you can also delete all the bluetooth stuff as well to free up some space. The easiest way of doing that is probably to rebuild a rootfs with bluetooth turned off in the top- level config. > I will try to remove bluetooth from the buildroot and see if that > helps. Yeah, that will work. > ### JFFS2 loading 'boot/uImage' to 0xa2000000 > Scanning JFFS2 FS: Unknown node type: 2005 len 24 offset 0x0 > . Unknown node type: 2005 len 24 offset 0x20000 > | Unknown node type: 2005 len 24 offset 0x40000 > Unknown node type: 2005 len 24 offset 0x60000 > / Unknown node type: 2005 len 24 offset 0x80000 > > > It goes on like that for 125 lines (which is more lines then before, > when the boot failed). That's because you have a 16MB flash 'stix -- the first boot, those "node type 2005" only exist for those sectors which you flashed from your rootfs image. On the first boot, there a big delay while JFFS2 erases all the upper part of flash and writes those headers to each sector -- there are 126 such sectors altogether in flash (128 minus the two which u-boot lives in). C |
From: Joel V. <vj...@pa...> - 2006-04-07 22:25:32
|
Craig Hughes wrote: > On Apr 7, 2006, at 2:19 PM, Joel VanderWerf wrote: > >> setenv bootargs console=ttyS0,115200n8 root=1f01 rootfstype=jffs2 >> reboot=cold,hard >> saveenv > > That should do it. > >> However, there are still messages about "unknown node type" when booting >> (see below). Is that a problem? Also there is a long delay while looking >> for bluetooth (which is not present in the hw): > > No, it's not a problem. I've updated u-boot since then to not print > this warning message, but haven't put a new binary up at sf.net yet -- > for now, just ignore those "errors", they are harmless. Thanks. I can live with console messages. Mostly I won't even see 'em because I'll be ssh-ing over ethernet. ... > If you don't have bluetooth on the gumstix, then you can stop BT from > trying to start on boot by removing or renaming /etc/init.d/S30bluetooth > -- if you want, you can also delete all the bluetooth stuff as well to > free up some space. The easiest way of doing that is probably to > rebuild a rootfs with bluetooth turned off in the top-level config. > >> I will try to remove bluetooth from the buildroot and see if that helps. > > Yeah, that will work. I tried deselecting bluez (in menuconfig) and rebuilding the root image, but it still had bluetooth stuff when booted: # cd / # find . -name '*blue*' ./etc/default/bluetooth ./etc/init.d/S30bluetooth ./etc/bluetooth ./etc/bluetooth/bluepin ./lib/modules/2.6.15gum/kernel/net/bluetooth ./lib/modules/2.6.15gum/kernel/net/bluetooth/gumstix_bluetooth.ko ./lib/modules/2.6.15gum/kernel/net/bluetooth/bluetooth.ko ./lib/modules/2.6.15gum/kernel/drivers/bluetooth ./sys/module/gumstix_bluetooth ./usr/lib/libbluetooth.so.1.0.24 ./usr/lib/libbluetooth.so ./usr/lib/libbluetooth.so.1 So I did a make distclean and am starting from scratch. I am sure there is a better way.... -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 |
From: Craig H. <cr...@gu...> - 2006-04-07 22:41:26
|
On Apr 7, 2006, at 3:25 PM, Joel VanderWerf wrote: > I tried deselecting bluez (in menuconfig) and rebuilding the root > image, > but it still had bluetooth stuff when booted: Because you didn't do an: rm -rf /path/to/buildroot/build_arm_nofpu/root /path/to/buildroot/ build_arm_nofpu/staging_dir/.fakeenv If you don't do that, then the stuff which you'd previously built will still be in the "root" staging directory, and so it'll continue to be present in the rootfs which gets built from that directory. Deselecting a package doesn't delete it if it was built while previously selected. > # cd / > # find . -name '*blue*' > ./etc/default/bluetooth > ./etc/init.d/S30bluetooth > ./etc/bluetooth > ./etc/bluetooth/bluepin > ./lib/modules/2.6.15gum/kernel/net/bluetooth > ./lib/modules/2.6.15gum/kernel/net/bluetooth/gumstix_bluetooth.ko > ./lib/modules/2.6.15gum/kernel/net/bluetooth/bluetooth.ko > ./lib/modules/2.6.15gum/kernel/drivers/bluetooth > ./sys/module/gumstix_bluetooth > ./usr/lib/libbluetooth.so.1.0.24 > ./usr/lib/libbluetooth.so > ./usr/lib/libbluetooth.so.1 > > So I did a make distclean and am starting from scratch. I am sure > there > is a better way.... The best way to restart is to just remove the stuff mentioned above. Occasionally, you might need to remove all of build_arm_nofpu and toolchain_build_arm_nofpu -- but not generally. C |
From: Joel V. <vj...@pa...> - 2006-04-07 22:55:28
|
Craig Hughes wrote: > > On Apr 7, 2006, at 3:25 PM, Joel VanderWerf wrote: > >> I tried deselecting bluez (in menuconfig) and rebuilding the root image, >> but it still had bluetooth stuff when booted: > > Because you didn't do an: > > rm -rf /path/to/buildroot/build_arm_nofpu/root > /path/to/buildroot/build_arm_nofpu/staging_dir/.fakeenv > > If you don't do that, then the stuff which you'd previously built will > still be in the "root" staging directory, and so it'll continue to be > present in the rootfs which gets built from that directory. Deselecting > a package doesn't delete it if it was built while previously selected. Good to know. I figured it would be something like that. So would 'make clean' do this? -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407 |
From: Alexandre P. N. <al...@om...> - 2006-04-07 22:57:09
|
> [cut] > Because you didn't do an: > > rm -rf /path/to/buildroot/build_arm_nofpu/root /path/to/buildroot/ > build_arm_nofpu/staging_dir/.fakeenv > > If you don't do that, then the stuff which you'd previously built > will still be in the "root" staging directory, and so it'll continue > to be present in the rootfs which gets built from that directory. > Deselecting a package doesn't delete it if it was built while > previously selected. Craig, I changed .fakeenv to .jffs2_fakeroot.env (name is arbitrary) on /path/to/buildroot/target/jffs2/jffs2root.mk and also did this right the very first invocation of fakeroot: -/sbin/ldconfig -r $(TARGET_DIR) 2>/dev/null + echo -n >$(STAGING_DIR)/jffs2_fakeroot.env # Use fakeroot to pretend all target binaries are owned by root -$(STAGING_DIR)/usr/bin/fakeroot \ -i $(STAGING_DIR)/jffs2_fakeroot.env \ -s $(STAGING_DIR)/jffs2_fakeroot.env -- \ chown -R root:root $(TARGET_DIR) Or, in other words, I make sure this file is empty before calling fakeroot. This fakeroot.env does store inode <-> faked metadata information, which gets out of sync when the files are removed/changed outside of fakeroot, so it's not safe (nor this option was intented to work like that) to keep this file among consecutive builds. Renaming it only for safety because there are other rootfs builders who may need patching as well but since we don't use them I wish to remain on the safe side. That way we go minus one crap to take care of between consecutive rebuilds... Alexandre |
From: Craig H. <cr...@gu...> - 2006-04-07 23:35:11
|
I committed what I think is a somewhat better patch along similar lines as r932 C On Apr 7, 2006, at 3:56 PM, Alexandre Pereira Nunes wrote: >> [cut] >> Because you didn't do an: >> >> rm -rf /path/to/buildroot/build_arm_nofpu/root /path/to/buildroot/ >> build_arm_nofpu/staging_dir/.fakeenv >> >> If you don't do that, then the stuff which you'd previously built >> will still be in the "root" staging directory, and so it'll >> continue to be present in the rootfs which gets built from that >> directory. Deselecting a package doesn't delete it if it was >> built while previously selected. > > > Craig, I changed .fakeenv to .jffs2_fakeroot.env (name is > arbitrary) on /path/to/buildroot/target/jffs2/jffs2root.mk and also > did this right the very first invocation of fakeroot: > > -/sbin/ldconfig -r $(TARGET_DIR) 2>/dev/null > + echo -n >$(STAGING_DIR)/jffs2_fakeroot.env > # Use fakeroot to pretend all target binaries are owned by root > -$(STAGING_DIR)/usr/bin/fakeroot \ > -i $(STAGING_DIR)/jffs2_fakeroot.env \ > -s $(STAGING_DIR)/jffs2_fakeroot.env -- \ > chown -R root:root $(TARGET_DIR) > > Or, in other words, I make sure this file is empty before calling > fakeroot. This fakeroot.env does store inode <-> faked metadata > information, which gets out of sync when the files are removed/ > changed outside of fakeroot, so it's not safe (nor this option was > intented to work like that) to keep this file among consecutive > builds. Renaming it only for safety because there are other rootfs > builders who may need patching as well but since we don't use them > I wish to remain on the safe side. > > That way we go minus one crap to take care of between consecutive > rebuilds... > > Alexandre > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Alexandre P. N. <al...@om...> - 2006-04-08 00:00:22
|
Craig Hughes escreveu: > I committed what I think is a somewhat better patch along similar > lines as r932 > > C Taking a first glimpse, yours sure looks like a better patch indeed, thanks! :-) Alexandre |