November 2014 - U-Boot

[U-Boot] [drivers/mtd/ubi/eba.c:1275]: (error) Uninitialized variable: aeb
by Wolfgang Denk 07 Nov '14

07 Nov '14

Hello, cppcheck reports: [drivers/mtd/ubi/eba.c:1275]: (error) Uninitialized variable: aeb can you please have a look? Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de If you're not part of the solution, then you're part of the precipi- tate.

2 3

[U-Boot] [PATCH 4/4] x86: Save TSC frequency in the global data
by Bin Meng 07 Nov '14

07 Nov '14

Return the saved TSC frequency in get_tbclk_mhz(). Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- arch/x86/include/asm/global_data.h | 1 + arch/x86/lib/tsc_timer.c | 4 ++++ 2 files changed, 5 insertions(+) diff --git a/arch/x86/include/asm/global_data.h b/arch/x86/include/asm/global_data.h index 721e7dc..7f22336 100644 --- a/arch/x86/include/asm/global_data.h +++ b/arch/x86/include/asm/global_data.h @@ -21,6 +21,7 @@ struct arch_global_data { uint64_t tsc_base; /* Initial value returned by rdtsc() */ uint32_t tsc_base_kclocks; /* Initial tsc as a kclocks value */ uint32_t tsc_prev; /* For show_boot_progress() */ + uint32_t tsc_mhz; /* TSC frequency in MHz */ void *new_fdt; /* Relocated FDT */ }; diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c index 8a0abde..b5f0458 100644 --- a/arch/x86/lib/tsc_timer.c +++ b/arch/x86/lib/tsc_timer.c @@ -293,6 +293,9 @@ unsigned __attribute__((no_instrument_function)) long get_tbclk_mhz(void) { unsigned long fast_calibrate; + if (gd->arch.tsc_mhz) + return gd->arch.tsc_mhz; + fast_calibrate = try_msr_calibrate_tsc(); if (fast_calibrate) return fast_calibrate; @@ -301,6 +304,7 @@ unsigned __attribute__((no_instrument_function)) long get_tbclk_mhz(void) if (!fast_calibrate) panic("TSC frequency is ZERO"); + gd->arch.tsc_mhz = fast_calibrate; return fast_calibrate; } -- 1.8.2.1

2 1

[U-Boot] [PATCH 3/4] x86: Add quick TSC calibration via PIT
by Bin Meng 07 Nov '14

07 Nov '14

Use the same way that Linux does for quick TSC calibration via PIT when calibration via MSR fails. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- arch/x86/include/asm/i8254.h | 3 + arch/x86/lib/tsc_timer.c | 155 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 158 insertions(+) diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h index c3ccd4f..4116de1 100644 --- a/arch/x86/include/asm/i8254.h +++ b/arch/x86/include/asm/i8254.h @@ -36,4 +36,7 @@ #define PIT_CMD_MODE4 0x08 /* Select mode 4 */ #define PIT_CMD_MODE5 0x0A /* Select mode 5 */ +/* The clock frequency of the i8253/i8254 PIT */ +#define PIT_TICK_RATE 1193182ul + #endif diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c index fafbbfc..8a0abde 100644 --- a/arch/x86/lib/tsc_timer.c +++ b/arch/x86/lib/tsc_timer.c @@ -117,6 +117,157 @@ fail: return 0; } +/* + * This reads the current MSB of the PIT counter, and + * checks if we are running on sufficiently fast and + * non-virtualized hardware. + * + * Our expectations are: + * + * - the PIT is running at roughly 1.19MHz + * + * - each IO is going to take about 1us on real hardware, + * but we allow it to be much faster (by a factor of 10) or + * _slightly_ slower (ie we allow up to a 2us read+counter + * update - anything else implies a unacceptably slow CPU + * or PIT for the fast calibration to work. + * + * - with 256 PIT ticks to read the value, we have 214us to + * see the same MSB (and overhead like doing a single TSC + * read per MSB value etc). + * + * - We're doing 2 reads per loop (LSB, MSB), and we expect + * them each to take about a microsecond on real hardware. + * So we expect a count value of around 100. But we'll be + * generous, and accept anything over 50. + * + * - if the PIT is stuck, and we see *many* more reads, we + * return early (and the next caller of pit_expect_msb() + * then consider it a failure when they don't see the + * next expected value). + * + * These expectations mean that we know that we have seen the + * transition from one expected value to another with a fairly + * high accuracy, and we didn't miss any events. We can thus + * use the TSC value at the transitions to calculate a pretty + * good value for the TSC frequencty. + */ +static inline int pit_verify_msb(unsigned char val) +{ + /* Ignore LSB */ + inb(0x42); + return inb(0x42) == val; +} + +static inline int pit_expect_msb(unsigned char val, u64 *tscp, unsigned long *deltap) +{ + int count; + u64 tsc = 0, prev_tsc = 0; + + for (count = 0; count < 50000; count++) { + if (!pit_verify_msb(val)) + break; + prev_tsc = tsc; + tsc = rdtsc(); + } + *deltap = rdtsc() - prev_tsc; + *tscp = tsc; + + /* + * We require _some_ success, but the quality control + * will be based on the error terms on the TSC values. + */ + return count > 5; +} + +/* + * How many MSB values do we want to see? We aim for + * a maximum error rate of 500ppm (in practice the + * real error is much smaller), but refuse to spend + * more than 50ms on it. + */ +#define MAX_QUICK_PIT_MS 50 +#define MAX_QUICK_PIT_ITERATIONS (MAX_QUICK_PIT_MS * PIT_TICK_RATE / 1000 / 256) + +static unsigned long quick_pit_calibrate(void) +{ + int i; + u64 tsc, delta; + unsigned long d1, d2; + + /* Set the Gate high, disable speaker */ + outb((inb(0x61) & ~0x02) | 0x01, 0x61); + + /* + * Counter 2, mode 0 (one-shot), binary count + * + * NOTE! Mode 2 decrements by two (and then the + * output is flipped each time, giving the same + * final output frequency as a decrement-by-one), + * so mode 0 is much better when looking at the + * individual counts. + */ + outb(0xb0, 0x43); + + /* Start at 0xffff */ + outb(0xff, 0x42); + outb(0xff, 0x42); + + /* + * The PIT starts counting at the next edge, so we + * need to delay for a microsecond. The easiest way + * to do that is to just read back the 16-bit counter + * once from the PIT. + */ + pit_verify_msb(0); + + if (pit_expect_msb(0xff, &tsc, &d1)) { + for (i = 1; i <= MAX_QUICK_PIT_ITERATIONS; i++) { + if (!pit_expect_msb(0xff-i, &delta, &d2)) + break; + + /* + * Iterate until the error is less than 500 ppm + */ + delta -= tsc; + if (d1+d2 >= delta >> 11) + continue; + + /* + * Check the PIT one more time to verify that + * all TSC reads were stable wrt the PIT. + * + * This also guarantees serialization of the + * last cycle read ('d2') in pit_expect_msb. + */ + if (!pit_verify_msb(0xfe - i)) + break; + goto success; + } + } + debug("Fast TSC calibration failed\n"); + return 0; + +success: + /* + * Ok, if we get here, then we've seen the + * MSB of the PIT decrement 'i' times, and the + * error has shrunk to less than 500 ppm. + * + * As a result, we can depend on there not being + * any odd delays anywhere, and the TSC reads are + * reliable (within the error). + * + * kHz = ticks / time-in-seconds / 1000; + * kHz = (t2 - t1) / (I * 256 / PIT_TICK_RATE) / 1000 + * kHz = ((t2 - t1) * PIT_TICK_RATE) / (I * 256 * 1000) + */ + delta *= PIT_TICK_RATE; + delta /= (i*256*1000); + debug("Fast TSC calibration using PIT\n"); + return delta / 1000; +} + void timer_set_base(u64 base) { gd->arch.tsc_base = base; @@ -143,6 +294,10 @@ unsigned __attribute__((no_instrument_function)) long get_tbclk_mhz(void) unsigned long fast_calibrate; fast_calibrate = try_msr_calibrate_tsc(); + if (fast_calibrate) + return fast_calibrate; + + fast_calibrate = quick_pit_calibrate(); if (!fast_calibrate) panic("TSC frequency is ZERO"); -- 1.8.2.1

2 1

[U-Boot] PHY support issues
by Aaron Williams 07 Nov '14

07 Nov '14

Hi all, I am dealing with some phy devices made by Cortina and the current U-Boot PHY infrastructure is giving me some huge headaches. First of all, Cortina does not follow any of the standards for their phys. Their phys use clause 45 but use device 0 registers 0 and 1 for the PHY ID instead of the usual device 1-4 registers 2-3. On top of that, some of their devices like the CS4223 can have multiple interfaces share the same MDIO address. We're running quad XFI with this device and the Cortina phy uses a single address for all four interfaces but offsets the registers for each interface by 0x1000. For example, interface 0 uses register addresses 0.0x1000-0x1fff, interface 1 uses register addresses 0.0x2000-0x2fff, etc. Instead of using an array for each MDIO interface a linked list per MDIO interface might be better. One other thing to keep in mind is that a number of phy companies are starting to migrate away from MDIO. I was just speaking with a Vitesse engineer and they want to do away with MDIO and support SPI and i2c instead and possibly PCIe for configuration. Other phy devices I'm working with also support these alternative busses. I believe I emphasized how important MDIO support is, however, since it is a standard and it supports multiple devices per interface (unlike SPI which requires a separate chip enable per device). One other change I would like to see is support for more interface types. We're dealing with everything from RGMII, SGMII, QSGMII, XAUI, XFI, XLAUI, 10G KR 40G KR among other interface types. Someday I'd love to get our U-Boot into the upstream U-Boot but it will be a big process. We have well over 700,000 lines of code, most of this portable between all of our chips and boards with only myself to maintain and support it. -Aaron -- Aaron Williams Software Engineer Cavium, Inc. (408) 943-7198 (510) 789-8988 (cell)

1 0

[U-Boot] [PATCH 2/4] x86: Do TSC MSR calibration only for known/supported CPUs
by Bin Meng 07 Nov '14

07 Nov '14

Using MSR_PLATFORM_INFO (0xCE) to calibrate TSR will cause #GP on processors which do not have this MSR. Instead only doing the MSR calibration for known/supported CPUs. Signed-off-by: Bin Meng <bmeng.cn(a)gmail.com> --- arch/x86/lib/tsc_timer.c | 116 ++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 109 insertions(+), 7 deletions(-) diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c index 8b38702..fafbbfc 100644 --- a/arch/x86/lib/tsc_timer.c +++ b/arch/x86/lib/tsc_timer.c @@ -1,6 +1,9 @@ /* * Copyright (c) 2012 The Chromium OS Authors. * + * TSC calibration codes are adapted from Linux kernel + * arch/x86/kernel/tsc_msr.c and arch/x86/kernel/tsc.c + * * SPDX-License-Identifier: GPL-2.0+ */ @@ -12,8 +15,108 @@ #include <asm/msr.h> #include <asm/u-boot-x86.h> +/* CPU reference clock frequency: in KHz */ +#define FREQ_83 83200 +#define FREQ_100 99840 +#define FREQ_133 133200 +#define FREQ_166 166400 + +#define MAX_NUM_FREQS 8 + DECLARE_GLOBAL_DATA_PTR; +/* + * According to Intel 64 and IA-32 System Programming Guide, + * if MSR_PERF_STAT[31] is set, the maximum resolved bus ratio can be + * read in MSR_PLATFORM_ID[12:8], otherwise in MSR_PERF_STAT[44:40]. + * Unfortunately some Intel Atom SoCs aren't quite compliant to this, + * so we need manually differentiate SoC families. This is what the + * field msr_plat does. + */ +struct freq_desc { + u8 x86_family; /* CPU family */ + u8 x86_model; /* model */ + u8 msr_plat; /* 1: use MSR_PLATFORM_INFO, 0: MSR_IA32_PERF_STATUS */ + u32 freqs[MAX_NUM_FREQS]; +}; + +static struct freq_desc freq_desc_tables[] = { + /* PNW */ + { 6, 0x27, 0, { 0, 0, 0, 0, 0, FREQ_100, 0, FREQ_83 } }, + /* CLV+ */ + { 6, 0x35, 0, { 0, FREQ_133, 0, 0, 0, FREQ_100, 0, FREQ_83 } }, + /* TNG */ + { 6, 0x4a, 1, { 0, FREQ_100, FREQ_133, 0, 0, 0, 0, 0 } }, + /* VLV2 */ + { 6, 0x37, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_166, 0, 0, 0, 0 } }, + /* ANN */ + { 6, 0x5a, 1, { FREQ_83, FREQ_100, FREQ_133, FREQ_100, 0, 0, 0, 0 } }, +}; + +static int match_cpu(u8 family, u8 model) +{ + int i; + + for (i = 0; i < ARRAY_SIZE(freq_desc_tables); i++) { + if ((family == freq_desc_tables[i].x86_family) && + (model == freq_desc_tables[i].x86_model)) + return i; + } + + return -1; +} + +/* Map CPU reference clock freq ID(0-7) to CPU reference clock freq(KHz) */ +#define id_to_freq(cpu_index, freq_id) \ + (freq_desc_tables[cpu_index].freqs[freq_id]) + +/* + * Do MSR calibration only for known/supported CPUs. + * + * Returns the calibration value or 0 if MSR calibration failed. + */ +static unsigned long try_msr_calibrate_tsc(void) +{ + u32 lo, hi, ratio, freq_id, freq; + unsigned long res; + int cpu_index; + + cpu_index = match_cpu(gd->arch.x86, gd->arch.x86_model); + if (cpu_index < 0) + return 0; + + if (freq_desc_tables[cpu_index].msr_plat) { + rdmsr(MSR_PLATFORM_INFO, lo, hi); + ratio = (lo >> 8) & 0x1f; + } else { + rdmsr(MSR_IA32_PERF_STATUS, lo, hi); + ratio = (hi >> 8) & 0x1f; + } + debug("Maximum core-clock to bus-clock ratio: 0x%x\n", ratio); + + if (!ratio) + goto fail; + + /* Get FSB FREQ ID */ + rdmsr(MSR_FSB_FREQ, lo, hi); + freq_id = lo & 0x7; + freq = id_to_freq(cpu_index, freq_id); + debug("Resolved frequency ID: %u, frequency: %u KHz\n", + freq_id, freq); + if (!freq) + goto fail; + + /* TSC frequency = maximum resolved freq * maximum resolved bus ratio */ + res = freq * ratio / 1000; + debug("TSC runs at %lu MHz\n", res); + + return res; + +fail: + debug("Fast TSC calibration using MSR failed\n"); + return 0; +} + void timer_set_base(u64 base) { gd->arch.tsc_base = base; @@ -34,17 +137,16 @@ u64 __attribute__((no_instrument_function)) get_ticks(void) return now_tick - gd->arch.tsc_base; } -#define PLATFORM_INFO_MSR 0xce - /* Get the speed of the TSC timer in MHz */ unsigned __attribute__((no_instrument_function)) long get_tbclk_mhz(void) { - u32 ratio; - u64 platform_info = native_read_msr(PLATFORM_INFO_MSR); + unsigned long fast_calibrate; + + fast_calibrate = try_msr_calibrate_tsc(); + if (!fast_calibrate) + panic("TSC frequency is ZERO"); - /* 100MHz times Max Non Turbo ratio */ - ratio = (platform_info >> 8) & 0xff; - return 100 * ratio; + return fast_calibrate; } unsigned long get_tbclk(void) -- 1.8.2.1

2 1

[U-Boot] MPC85xx: Uninitialized variables and other problems
by Wolfgang Denk 07 Nov '14

07 Nov '14

Hello, cppcheck reports: [arch/powerpc/cpu/mpc85xx/cmd_errata.c:62]: (error) Uninitialized variable: x108 [board/freescale/common/cds_pci_ft.c:36]: (error) Possible null pointer dereference: map [board/freescale/common/cds_pci_ft.c:52]: (error) Uninitialized variable: len [board/freescale/t4qds/eth.c:289]: (error) Undefined behavior: Variable 'buf' is used as parameter and destination in s[n]printf(). [board/freescale/t4qds/eth.c:298]: (error) Undefined behavior: Variable 'buf' is used as parameter and destination in s[n]printf(). [board/freescale/t4qds/eth.c:307]: (error) Undefined behavior: Variable 'buf' is used as parameter and destination in s[n]printf(). [board/freescale/t4qds/eth.c:316]: (error) Undefined behavior: Variable 'buf' is used as parameter and destination in s[n]printf(). [drivers/ddr/fsl/ctrl_regs.c:1659]: (error) Uninitialized variable: wr [drivers/ddr/fsl/ctrl_regs.c:2257]: (error) Uninitialized variable: ea [drivers/ddr/fsl/ctrl_regs.c:2256]: (error) Uninitialized variable: sa [drivers/ddr/fsl/ctrl_regs.c:1985]: (error) Uninitialized variable: zqcs_init [drivers/mmc/fsl_esdhc_spl.c:95]: (error) Dereferencing 'tmp_buf' after it is deallocated / released [drivers/mmc/fsl_esdhc_spl.c:98]: (error) Memory pointed to by 'tmp_buf' is freed twice. [drivers/mmc/fsl_esdhc_spl.c:101]: (error) Dereferencing 'tmp_buf' after it is deallocated / released [drivers/mmc/fsl_esdhc_spl.c:104]: (error) Memory pointed to by 'tmp_buf' is freed twice. Can you please have a look and fix these? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de A person who is more than casually interested in computers should be well schooled in machine language, since it is a fundamental part of a computer. -- Donald Knuth

2 1

[U-Boot] [PATCH] MAINTAINERS: add me as a maintainer of MTD
by Heiko Schocher 06 Nov '14

06 Nov '14

Add MAINTAINERS and doc/git-mailrc entry. Signed-off-by: Heiko Schocher <hs(a)denx.de> --- as discussed this step here and there first of all with Scott Wood for example here: http://lists.denx.de/pipermail/u-boot/2014-August/186005.html I am now ready for taking over the ownership for MTD ... @Scott: I would be happy, if you can still have a look in nand patches ;-) please inform me, if you have no longer time for it, so we can set u-boot-nand into not maintained state @all: Please send me a list of pending patches, so I can go through them, thanks! MAINTAINERS | 8 ++++++++ doc/git-mailrc | 1 + 2 files changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index fd346c9..e81a08a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -258,6 +258,14 @@ S: Maintained T: git git://git.denx.de/u-boot-mmc.git F: drivers/mmc/ +MTD +M: Heiko Schocher <hs(a)denx.de> +S: Maintained +T: git git://git.denx.de/u-boot-mtd.git +F: drivers/mtd* +F: include/linux/mtd* +F: include/mtd* + OPENRISC M: Stefan Kristiansson <stefan.kristiansson(a)saunalahti.fi> S: Maintained diff --git a/doc/git-mailrc b/doc/git-mailrc index ad22763..166fe37 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -116,6 +116,7 @@ alias fdt uboot, sjg alias i2c uboot, hs alias kconfig uboot, masahiro alias mmc uboot, panto +alias mtd uboot, hs alias nand uboot, scottwood alias net uboot, jhersh alias spi uboot, jagan -- 1.8.3.1

6 10

[U-Boot] [PATCH] usb: rmobile: Use ARRAY_SIZE(usb_base_address) instead of CONFIG_USB_MAX_CONTROLLER_COUNT
by Nobuhiro Iwamatsu 06 Nov '14

06 Nov '14

Signed-off-by: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj(a)renesas.com> CC: Marek Vasut <marex(a)denx.de> --- drivers/usb/host/ehci-rmobile.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/host/ehci-rmobile.c b/drivers/usb/host/ehci-rmobile.c index b433087..7fe79ef 100644 --- a/drivers/usb/host/ehci-rmobile.c +++ b/drivers/usb/host/ehci-rmobile.c @@ -13,18 +13,18 @@ #include "ehci.h" #if defined(CONFIG_R8A7740) -static u32 usb_base_address[CONFIG_USB_MAX_CONTROLLER_COUNT] = { +static u32 usb_base_address[] = { 0xC6700000 }; #elif defined(CONFIG_R8A7790) -static u32 usb_base_address[CONFIG_USB_MAX_CONTROLLER_COUNT] = { +static u32 usb_base_address[] = { 0xEE080000, /* USB0 (EHCI) */ 0xEE0A0000, /* USB1 */ 0xEE0C0000, /* USB2 */ }; #elif defined(CONFIG_R8A7791) || defined(CONFIG_R8A7793) || \ defined(CONFIG_R8A7794) -static u32 usb_base_address[CONFIG_USB_MAX_CONTROLLER_COUNT] = { +static u32 usb_base_address[] = { 0xEE080000, /* USB0 (EHCI) */ 0xEE0C0000, /* USB1 */ }; @@ -53,7 +53,7 @@ int ehci_hcd_stop(int index) if (!i) printf("error : ehci(%d) reset failed.\n", index); - if (index == (CONFIG_USB_MAX_CONTROLLER_COUNT - 1)) + if (index == (ARRAY_SIZE(usb_base_address) - 1)) setbits_le32(SMSTPCR7, SMSTPCR703); return 0; -- 2.1.1

2 1

[U-Boot] [PATCH] usb: ehci: fix Interrupt on Doorbell flag of USBCMD
by Masahiro Yamada 06 Nov '14

06 Nov '14

CMD_IAAD (Interrupt on Async Advance Doorbell) is bit 6, not bit 5. While we are here, sort the flags. Signed-off-by: Masahiro Yamada <yamada.m(a)jp.panasonic.com> --- drivers/usb/host/ehci.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h index 433e703..79aecd4 100644 --- a/drivers/usb/host/ehci.h +++ b/drivers/usb/host/ehci.h @@ -47,9 +47,9 @@ struct ehci_hcor { uint32_t or_usbcmd; #define CMD_PARK (1 << 11) /* enable "park" */ #define CMD_PARK_CNT(c) (((c) >> 8) & 3) /* how many transfers to park */ -#define CMD_ASE (1 << 5) /* async schedule enable */ #define CMD_LRESET (1 << 7) /* partial reset */ -#define CMD_IAAD (1 << 5) /* "doorbell" interrupt */ +#define CMD_IAAD (1 << 6) /* "doorbell" interrupt */ +#define CMD_ASE (1 << 5) /* async schedule enable */ #define CMD_PSE (1 << 4) /* periodic schedule enable */ #define CMD_RESET (1 << 1) /* reset HC not bus */ #define CMD_RUN (1 << 0) /* start/stop HC */ -- 1.9.1

2 1

[U-Boot] [net/eth.c:64]: (error) Uninitialized variable: skip_state
by Wolfgang Denk 06 Nov '14

06 Nov '14

Hello, cppcheck reports: [net/eth.c:64]: (error) Uninitialized variable: skip_state can you please have a look? Thanks! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de What we anticipate seldom occurs; what we least expect generally happens. - Bengamin Disraeli

2 3