2.6.26rc bootlog

GoogleGroups
1

Hi,

To give everybody an idea of the state of the beagleboard kernels in
OE, here's a bootlog with all supported devices enabled:

Linux version 2.6.26-rc2-omap1 (koen@lieve) (gcc version 4.2.2) #1 Thu
May 15 12:35:09 CEST 2008
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f
Machine: OMAP3 Beagle Board
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 32768
  DMA zone: 256 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 32512 pages, LIFO batch:7
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
OMAP3430 ES2.0
SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets
Built 1 zonelists in Zone order, mobility grouping on. Total pages:
32512
Kernel command line: root=/dev/mmcblk0p2 rootdelay=2
console=ttyS2,115200n8 noinitrd rootfstype=ext3 ip=off
Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz
GPMC revision 5.0
IRQ: Found an INTC at 0x48200000 (revision 4.0) with 96 interrupts
Total of 96 interrupts on 1 active controller
OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB 0MB = 128MB total
Memory: 125568KB available (3792K code, 308K data, 148K init)
Calibrating delay loop... 499.92 BogoMIPS (lpj=1949696)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
net_namespace: 324 bytes
NET: Registered protocol family 16
OMAP3 L2 cache enabled
OMAP DMA hardware revision 4.0
Initializing OMAP McBSP system
USB: No board-specific platform config found
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz
i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz
TWL4030: TRY attach Slave TWL4030-ID0 on Adapter OMAP I2C adapter [1]
TWL4030: TRY attach Slave TWL4030-ID1 on Adapter OMAP I2C adapter [1]
TWL4030: TRY attach Slave TWL4030-ID2 on Adapter OMAP I2C adapter [1]
TWL4030: TRY attach Slave TWL4030-ID3 on Adapter OMAP I2C adapter [1]
Initialized TWL4030 USB module
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
musb_hdrc: version 6.0, musb-dma, peripheral, debug=0
musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO
Rx (X))
musb_hdrc: MHDRC RTL version 1.400
musb_hdrc: setup fifo_mode 4
musb_hdrc: 29/15 max ep, 7232/16384 memory
musb_hdrc: hw_ep 0shared, max 64
musb_hdrc: hw_ep 1tx, max 512
musb_hdrc: hw_ep 1rx, max 512
musb_hdrc: hw_ep 2tx, max 512
musb_hdrc: hw_ep 2rx, max 512
musb_hdrc: hw_ep 3tx, max 512
musb_hdrc: hw_ep 3rx, max 512
musb_hdrc: hw_ep 4tx, max 512
musb_hdrc: hw_ep 4rx, max 512
musb_hdrc: hw_ep 5tx, max 512
musb_hdrc: hw_ep 5rx, max 512
musb_hdrc: hw_ep 6tx, max 512
musb_hdrc: hw_ep 6rx, max 512
musb_hdrc: hw_ep 7tx, max 512
musb_hdrc: hw_ep 7rx, max 512
musb_hdrc: USB Peripheral mode controller at c8800000 using DMA, IRQ
92
Bluetooth: Core ver 2.11
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
msgmni has been set to 245 for ipc namespace c03f8ac0
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
omapfb: configured for panel omap3beagle
omapfb: DISPC version 3.0 initialized
Console: switching to mono frame buffer device 128x48
omapfb: Framebuffer initialized. Total vram 2359296 planes 1
omapfb: Pixclock 48000 kHz hfreq 44.7 kHz vfreq 57.7 Hz
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing
enabled
serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654
serial8250.0: ttyS1 at MMIO 0x4806c000 (irq = 73) is a ST16654
serial8250.0: ttyS2 at MMIO 0x49020000 (irq = 74) is a ST16654
console [ttyS2] enabled
brd: module loaded
loop: module loaded
usbcore: registered new interface driver asix
usbcore: registered new interface driver cdc_ether
Linux video capture interface: v2.00
i2c /dev entries driver
i2c_omap i2c_omap.2: controller timed out
i2c_omap i2c_omap.2: controller timed out
TLV320AIC23 I2C version 1.8 (10-Feb-2006)
TWL4030 GPIO Demux: IRQ Range 384 to 402, Initialization Success
input: triton2-pwrbutton as /class/input/input0
triton2 power button driver initialized
Driver 'sd' needs updating - please use bus_type methods
TI TSC2102 driver initializing
usbmon: debugfs is not available
Clock usbhost_48m_fck didn't enable in 100000 tries
ehci-omap ehci-omap.0: OMAP-EHCI Host Controller
ehci-omap ehci-omap.0: new USB bus registered, assigned bus number 1
ehci-omap ehci-omap.0: irq 77, io mem 0x48064800
ehci-omap ehci-omap.0: USB 0.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ether gadget: using random self ethernet address
ether gadget: using random host ethernet address
usb0: Ethernet Gadget, version: May Day 2005
usb0: using musb_hdrc, OUT ep1out IN ep1in STATUS ep2in
usb0: MAC 52:b4:0f:74:43:48
usb0: HOST MAC 4a:3a:9e:f6:47:9a
usb0: RNDIS ready
mice: PS/2 mouse device common for all mice
twl4030_rtc twl4030_rtc: rtc core: registered twl4030_rtc as rtc0
twl4030_rtc twl4030_rtc: Power up reset detected.
twl4030_rtc twl4030_rtc: Enabling TWL4030-RTC.
OMAP Watchdog Timer Rev 0x31: initial timeout 60 sec
Bluetooth: HCI USB driver ver 2.9
usbcore: registered new interface driver hci_usb
Bluetooth: Broadcom Blutonium firmware driver ver 1.1
usbcore: registered new interface driver bcm203x
Bluetooth: Digianswer Bluetooth USB driver ver 0.9
usbcore: registered new interface driver bpa10x
Bluetooth: Generic Bluetooth SDIO driver ver 0.1
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
Advanced Linux Sound Architecture Driver Version 1.0.16.
ASoC version 0.13.2
ALSA device list:
  No soundcards found.
TCP cubic registered
NET: Registered protocol family 17
NET: Registered protocol family 15
Bluetooth: L2CAP ver 2.9
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO (Voice Link) ver 0.5
Bluetooth: SCO socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
Bluetooth: BNEP (Ethernet Emulation) ver 1.2
Bluetooth: BNEP filters: protocol multicast
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
ieee80211: 802.11 data/management/control stack, git-1.1.13

2

Nice!

Linux version 2.6.26-rc2-omap1 (koen@lieve) (gcc version 4.2.2) #1 Thu
May 15 12:35:09 CEST 2008
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f

This means this is a Cortex A8 r1p2. Good thing...

  Movable zone: 0 pages used for memmap
OMAP3430 ES2.0

This contradicts what I have been told about ES 2.0 being r1p1.
Or perhaps it's different for OMAP3530. BTW is there a way to
distinguish OMAP3430 and OMAP3530 using some id regs?

CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets

That's certainly wrong. It seems the kernel fails to correctly
detect ARMv7 cache properties.

OMAP3 L2 cache enabled

:slight_smile:

omapfb: Framebuffer initialized. Total vram 2359296 planes 1

1024x768x24 bits?

Power Management for OMAP2 initializing
PRCM revision 0.0
could not get osc_ck

Is that expected?

Laurent

3

CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets

That's certainly wrong. It seems the kernel fails to correctly
detect ARMv7 cache properties.

All: Sounds like this is something we have to discuss on arm kernel list with RMK & Catalin? Shall I start a thread?

OMAP3 L2 cache enabled

Koen: How do you do this? Kernel patch? Modified U-Boot?

As discussed at IRC I think our target upstream compatible solution for this currently is to remove l2cache_disable() from uboot's cleanup_before_linux() function.

Koen: How stable is this kernel boot for you at the moment? How often do you have to boot to get a 'stable' boot?

Thanks

Dirk

4

CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets

That's certainly wrong. It seems the kernel fails to correctly
detect ARMv7 cache properties.

All: Sounds like this is something we have to discuss on arm kernel
list with RMK & Catalin? Shall I start a thread?

OMAP3 L2 cache enabled

Koen: How do you do this? Kernel patch? Modified U-Boot?

Kernel patch.

As discussed at IRC I think our target upstream compatible solution
for this currently is to remove l2cache_disable() from uboot's
cleanup_before_linux() function.

I'm slightly too lazy/too busy to rebuild u-boot and sign it, etc, so
I opted for the kernel patch :slight_smile: I do agree that this should be solved
in u-boot

Koen: How stable is this kernel boot for you at the moment? How
often do you have to boot to get a 'stable' boot?

That's hard to say, I sometimes get 20 good boots in a row, and
sometimes I need 5 cold resets. Sometimes MUSB doesn't work, sometimes
the kernel crashes inside the omapfb layer, sometimes SD doesn't work.
You get the idea. And regardless of kernel, the board becomes
unresponsive after a few hours. With linux-omap git I can sysrq-b to
reboot, but that doesn't work with the WTBU kernel (software reset is
broken, not sysrq).

regards,

Koen

5

Yes please, there is some code missing in kernel/setup.c to
get this right. This is only cosmetics, but it's good to have
things properly detected and printed :slight_smile:

Laurent

6

Laurent Desnogues wrote:

CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets

That's certainly wrong. It seems the kernel fails to correctly
detect ARMv7 cache properties.

All: Sounds like this is something we have to discuss on arm kernel list
with RMK & Catalin? Shall I start a thread?

Yes please, there is some code missing in kernel/setup.c to
get this right.

Okay, I will do this.

This is only cosmetics, but it's good to have
things properly detected and printed :slight_smile:

What would be the correct output, btw?

Dirk

7

Something similar to this (IIRC Dcache is 16 kb):

CPU0: D VIPT cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
      supports RA WT

Laurent

8

Nice!

> omapfb: Framebuffer initialized. Total vram 2359296 planes 1

1024x768x24 bits?

Yes

> Power Management for OMAP2 initializing
> PRCM revision 0.0
> could not get osc_ck

Is that expected?

Sort of:

http://article.gmane.org/gmane.linux.ports.arm.omap/8233

regards,

Koen

9

Laurent Desnogues wrote:

CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets

That's certainly wrong. It seems the kernel fails to correctly
detect ARMv7 cache properties.

All: Sounds like this is something we have to discuss on arm kernel list
with RMK & Catalin? Shall I start a thread?

Yes please, there is some code missing in kernel/setup.c to
get this right. This is only cosmetics, but it's good to have
things properly detected and printed :slight_smile:

Short look into the details about this:

In arch/arm/kernel/setup.c there is:

if (CACHE_S(info)) {
   dump_cache("I cache", cpu, CACHE_ISIZE(info));
   dump_cache("D cache", cpu, CACHE_DSIZE(info));
} else {
    dump_cache("cache", cpu, CACHE_ISIZE(info));
}

Looks like on Beagle the else path is executed. With "info" containing

mrc p15, 0, Rd, c0, c0, 1

this is because CACHE_S is defined as

#define CACHE_S(x) ((x) & (1 << 24))

Looking to e.g. ARM926

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0198d/I1039291.html

this correct, as the S bit

"Specifies if the cache is a unified cache (S=0), or separate ICache and DCache (S=1)"

But it seems that at Cortex-A8 p15, 0, Rd, c0, c0, 1 has completely different meaning:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0344e/Babgfegb.html

Dirk