You are not logged in. Please login or register.
chumbysphere forum → Hardware → bootup without daughtercard
I would like to use my Chumby without a daughtercard. But when I remove the daughtercard Chumby won't boot up. Maybe Chumby reads some information from personality EEPROM on daughtercard I guess.
Can I use my Chumby without any daughtercard?
You should be able to use the chumby without the daughtercard, if you provide an alternate way for power to get in, and to assert the power button signal, which is done by shorting the power button signal to the 3.3V standby power line made available on the chumbilical...
Okay, let me re-phrase. I wired 12V power source and power switch to main board then it actually booted up, loaded the bootloader and loaded the kernel. Dotted boot up screen changed which means Chumby loaded and run /etc/rcS.
I checked userhooks. Chumby loaded and run userhook0, but somehow couldn't load and run userhook1. There are device settings and network settings between userhook0 and userhook1. I guess rcS is getting stuck on checking some device statuses such as EEPROM.
I'm seeing the same problem as naan - I am bringing up the Chumby with a custom daughtercard and the system hangs on boot. I just got started on debugging, but suspect booting hangs while the Chumby waits for SPI traffic that's not forthcoming (my daughtercard doesn't make any use of the Chumbilical SPI pins). Any thoughts?
I'm running the Chumby headless for now, but following boot progress via the debug port, this is what I get:
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
cramfs with NAND flash bad block extensions.
Please remember to size your partitions with adequate margins for bad blocks.
cramfs_init_badblock: found start of cramfs at addr 0x0
VFS: Mounted root (cramfs filesystem) readonly.
Freeing init memory: 104K
Chumby Rootdisk - RFS1 (ken@chumby.com)
makedevs : 1.1.1.1 $
makedevs: creating device nodes at /dev using mknod
Empty flash at 0x001fcc10 ends at 0x001fce00
Alarm was set for 2147483647 seconds from now
Starting udevd as daemon
waiting for USB subsystem: No usb drives appear to be mounted.. nothing to wait for...
timed out
mount: mounting /dev/sda1 on /mnt/usb failed
Starting mountmon as daemon
input: tsc2100_ts as /class/input/input0
Chumby TI-TSC2100 TouchScreen Driver v1.01 initialized (hw 1.x)
Chumby TI-TSC2100 ALSA Audio Driver v1.01 initialized
Chumby sensor suite 1 driver version 2.1-Ironforge initializing (bunnie@chumby.com)...
UserDMA device major=253, allocated 1572864 bytes. (buf_addr=c3200000, dma_addr=c3200000, cached=1)
drivers/mfd/chumby-tsc2100.c/tsc2100_dma_play_isr(): timed-out wating for DMA to start.
usbcore: registered new driver snd-usb-audio
usbcore: registered new driver hiddev
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
Restoring mute setting: 0
Restoring volume setting: 100
Restoring speaker pan setting: 0
Chumby timerx[2] driver version 2.1-Ironforge initializing (bunnie@chumby.com)...show me your jiffies!!!
Chumby accelerometer driver version 2.1-Kionix-Ironforge initializing (bunnie@chumby.com)...
Chumby DC ID EEPROM driver version 1.0-Atmel-25080A-Ironforge initializing (bunnie@chumby.com)...
BUG: soft lockup detected on CPU#0!
Pid: 1251, comm: insmod
CPU: 0
PC is at spi_exchange_data+0x34/0x48 [chumby_accel]
LR is at readEEPROM+0x78/0x13c [chumby_accel]
pc : [<bf04c034>] lr : [<bf04c1c0>] Not tainted
sp : c379de0c ip : c379de1c fp : c379de18
r10: 00000000 r9 : c4869000 r8 : bf04ee90
r7 : 00000300 r6 : 00000001 r5 : e000e000 r4 : 0500ffff
r3 : 00000003 r2 : e000e000 r1 : 00000001 r0 : 00000500
Flags: nZCv IRQs on FIQs on Mode SVC_32 Segment user
Control: 5317F Table: C3114000 DAC: 00000015
[<c0024b64>] (show_regs+0x0/0x4c) from [<c0054898>] (softlockup_tick+0x60/0x78)
r4 = C379DDC4
[<c0054838>] (softlockup_tick+0x0/0x78) from [<c00417d8>] (do_timer+0x3d0/0x450)
r4 = 00000000
[<c0041408>] (do_timer+0x0/0x450) from [<c0027578>] (timer_tick+0xb0/0xe0)
r8 = C379DDC4 r7 = 0000001A r6 = 00000000 r5 = 00000000
r4 = C379DDC4
[<c00274c8>] (timer_tick+0x0/0xe0) from [<c002cc74>] (imx_timer_interrupt+0x38/0x54)
r6 = 00000000 r5 = 00000000 r4 = C02E601C
[<c002cc3c>] (imx_timer_interrupt+0x0/0x54) from [<c0023dd0>] (__do_irq+0x4c/0x8c)
r4 = C0286360
[<c0023d84>] (__do_irq+0x0/0x8c) from [<c0024074>] (do_level_IRQ+0x68/0xc0)
r8 = BF04EE90 r7 = 00000300 r6 = C379DDC4 r5 = 0000001A
r4 = C02DCFC8
[<c002400c>] (do_level_IRQ+0x0/0xc0) from [<c00242c4>] (asm_do_IRQ+0x4c/0x120)
r6 = C379DDC4 r5 = 0000FFFF r4 = FFFFFFFF
[<c0024278>] (asm_do_IRQ+0x0/0x120) from [<c0022984>] (__irq_svc+0x24/0x80)
r6 = 00000001 r5 = 0000FFFF r4 = FFFFFFFF
[<bf04c000>] (spi_exchange_data+0x0/0x48 [chumby_accel]) from [<bf04c1c0>] (readEEPROM+0x78/0x13c [chumby_accel])
[<bf04c148>] (readEEPROM+0x0/0x13c [chumby_accel]) from [<bf0505a4>] (chumby_accel_init+0x5a4/0x730 [chumby_accel])
r7 = 00000FFF r6 = 00000000 r5 = BF04EA60 r4 = 00000000
[<bf050000>] (chumby_accel_init+0x0/0x730 [chumby_accel]) from [<c0053a80>] (sys_init_module+0x13c4/0x159c)
[<c00526bc>] (sys_init_module+0x0/0x159c) from [<c0022d00>] (ret_fast_syscall+0x0/0x2c)A little followup - after some debugging, the Chumby does seem to be hanging as a result of that unresolved "spi_exchange_data" transaction. My daughtercard lacks any SPI devices so, when the Chumby makes its request, there is no one to answer, and the Chumby will wait indefinitely for a response.
My solution for now: a wire jumper between SPI_MOSI and SPI_MISO - this loopback lets the Chumby answer its own request.
chumbysphere forum → Hardware → bootup without daughtercard
Powered by PunBB, supported by Informer Technologies, Inc.