May 2008 - U-Boot

[U-Boot-Users] Sandisk mDoC H3 support
by Micha Kalfon 30 May '08

30 May '08

Hello all, In the last few weeks I've been working on a u-boot driver for Sandisk's (MSystems) mDoc H3 device - basically, it's a DiskOnChip device which exposes a simple ATA interface to the software and works differently from previous generation DoCs (see http://www.linuxdevices.com/articles/AT2185129745.html for more). I implemented the following low-level features in u-boot which allow using the DoC H3 as a boot device (currently all I need it for) : 1. Basic partitioning - allows statically allocating sectors for numerous binary (raw) partitions. 2. Writing IPL boot block - basically, the very initial 2KB of code than run when the CPU boots. 3. Reading and Writing of binary partitions - I place u-boot binary in one partition to be loaded and run by the IPL and the linux kernel uImage in another. Features are exposed to the user / bootscript as simple u-boot commands. Does anyone see benefit from this to other u-boot users? If not, what can be added / changed to make it so? Micha

3 2

[U-Boot-Users] u-boot v2
by Kenneth Johansson 30 May '08

30 May '08

I'm just wondering what the status and plans are with the V2 branch. Is the plan that at some future date everyone just stops works on the main branch and switch over to V2 or is the features of V2 going to be ported over one by one.

3 2

[U-Boot-Users] U-Boot NAND driver for s3c6400
by Guennadi Liakhovetski 30 May '08

30 May '08

Hi Harald, all do you or anyone else know, if there is a s3c6400 NAND driver available somewhere for a recent U-Boot version (not OneNAND)? Preferably with booting from NAND support? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer

2 2

[U-Boot-Users] MPC8360x FATAL BUG with UEC and 10BaseT
by Russell McGuire 30 May '08

30 May '08

All - Freescale crowd, Carefully reading the manual it becomes evident, though not obvious that current U-boot UEC driver would crash with any 10BaseT hub connected. I.e. any RGMII connection with Half Duplex, which the current UEC driver readily will set, is an illegal mode in the MPC83xx chipsets. At least the MPC836xx chips. You'll get TX FIFO errors, followed by no TX Buffers ready, as the QE just locks up. My main concern is that how does one make the PHY switch modes without implementing some kind of crude reset of the entire driver? I.e. the PHY has to change interface mode from RGMII to something else that can support half duplex, as well as the MAC inside the MPC83xx has to change modes to something other than RGMII that can support half duplex. Currently there is no code path to drive anything other than RGMII. Anyone got suggestions? My beta code for a national GigE part, simply calls a function similar to the Marvell change_phy_interface() seems to cause the QE to never get a lock with the PHY device, and thus nothing is ever established. Not sure if the QE is losing sync with the PHY or the PHY is blowing up due to a change of interface type on the fly. Kim??? -Russ

1 0

[U-Boot-Users] [PATCH] Add a fpga memory test and some bugfixes to the fpga POST.
by sascha.laue＠liebherr.com 30 May '08

30 May '08

From: Sascha Laue <sascha.laue(a)liebherr.com> Signed-off-by: Sascha Laue <sascha.laue(a)liebherr.com> --- post/board/lwmon5/fpga.c | 58 ++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 54 insertions(+), 4 deletions(-) diff --git a/post/board/lwmon5/fpga.c b/post/board/lwmon5/fpga.c index b48390b..aa8f8bb 100644 --- a/post/board/lwmon5/fpga.c +++ b/post/board/lwmon5/fpga.c @@ -41,6 +41,14 @@ DECLARE_GLOBAL_DATA_PTR; #if CONFIG_POST & CFG_POST_BSPEC3 +const static uint pattern[] = { + 0x55555555, + 0xAAAAAAAA, + 0xAA5555AA, + 0x55AAAA55, + 0x0 +}; + static int one_scratch_test(uint value) { uint read_value; @@ -60,13 +68,47 @@ static int one_scratch_test(uint value) return ret; } +/* FPGA Memory-pattern-test */ +static int fpga_mem_test(void * address) +{ + int ret = 1; + uint read_value; + uint old_value; + uint i = 0; + + old_value = in_be32(address); + + while (pattern[i] != 0) { + out_be32(address, pattern[i]); + /* read other location (protect against data lines capacity) */ + read_value = in_be16((void *)FPGA_VERSION_REG); + /* verify test pattern */ + read_value = in_be32(address); + + if (read_value != pattern[i]) { + post_log("FPGA memory test failed."); + post_log(" write %08X, read %08X at address %08X\n", + pattern[i], read_value, address); + goto out; + } + i++; + } + + ret = 0; +out: + out_be32(address, old_value); + return ret; +} + /* Verify FPGA, get version & memory size */ int fpga_post_test(int flags) { uint old_value; - ushort version; + uint version; uint read_value; int ret = 0; + uint address; + uint old_fpga_stat; post_log("\n"); old_value = in_be32((void *)FPGA_SCRATCH_REG); @@ -78,16 +120,24 @@ int fpga_post_test(int flags) out_be32((void *)FPGA_SCRATCH_REG, old_value); - version = in_be16((void *)FPGA_VERSION_REG); - post_log("FPGA : version %u.%u\n", + version = in_be32((void *)FPGA_VERSION_REG); + post_log("FPGA version %u.%u\n", (version >> 8) & 0xFF, version & 0xFF); /* Enable write to FPGA RAM */ out_be32((void *)FPGA_STAT, in_be32((void *)FPGA_STAT) | 0x1000); read_value = get_ram_size((void *)CFG_FPGA_BASE_1, 0x4000); - post_log("FPGA RAM size: %d bytes\n", read_value); + post_log("FPGA RAM size %d bytes\n", read_value); + for (address = 0; address < 0x1000; address++) { + if (fpga_mem_test((void *)(FPGA_RAM_START + 4*address)) == 1) { + ret = 1; + goto out; + } + } +out: + out_be32((void *)FPGA_STAT, in_be32((void *)FPGA_STAT) & 0xEFFF); return ret; } -- 1.5.2.4

2 1

[U-Boot-Users] u-boot and Linux kernel forward compatibility is unsure?
by Leon Woestenberg 30 May '08

30 May '08

Hello all, triggered by the e-mail below (which solved my issue, thanks Kim) I have the following question: For how long can I expect current u-boot (say 1.3.4) to be forward compatible with newer Linux kernels? It seems the u-boot from only half a year old cannot boot a current Linux kernel (!). I typically work on products where the initial boot loader is adapted to provide fail-safe upgrades and itself is never upgraded to prevent the chance of non-flashable (bricked) products in the very small chance something goes wrong during the boot loader update. How do people deal with using u-boot in a fail-safe environment where the chance of brickage must be zero and the (initial) bootloader itself cannot be updated? Should I plan for a second stage loader? Also, is there any plan to add fail-safe features to u-boot? Regards, Leon. On Wed, May 28, 2008 at 9:38 PM, Kim Phillips <kim.phillips(a)freescale.com> wrote: > On Wed, 28 May 2008 21:33:33 +0200 > "Leon Woestenberg" <leon.woestenberg(a)gmail.com> wrote: > >> I have tried to run the vanilla upstream 2.6.25.4 kernel on my >> U-Boot 1.3.0-rc2 (Nov 19 2007 - 16:37:36) MPC83XX >> >> Is this u-boot too old, i.e. might there be a compatibility issue > yes > start by updating u-boot > Regards, -- Leon

2 3

[U-Boot-Users] 真诚信
by 您好 30 May '08

30 May '08

你好。我公司是一家香港上市公司的下属子公司，在全国大中城市有多家分部。现在有一部分：工商业销售、建筑安装、咨询、广告服务、餐饮酒店等fa#票价钱低点如贵公司有业务需要我方诚恳联系贵方携手共创效益。彼此合作真诚必将成为朋友！联系人：刘总13691829296 致，礼！

1 0

[U-Boot-Users] How to add boot picture to S3C2410 u-boot
by Fan, Xin (GE Healthcare) 30 May '08

30 May '08

Hello Everybody , How to add boot picture to S3C2410 u-boot, the LCD.c in ../common directory can direct support S3C2410 u-boot or not. When I define CONFIG_LCD to config file, it doesn't work in compile. Anyone has the experience on this? Thanks, Fan

1 0

[U-Boot-Users] Bis zu 2500 Euro Nebenverdienst
by Albertina batz 30 May '08

30 May '08

Ein marktgewinnendes Handelsbetrieb sucht neue Mitarbeiter !! Sie haben 6 Stunden in der Woche frei , besitzen einige PCkenntnisse und sind immer erreichebar?? - Sie haben dann die Moeglichkeit bei uns einzusteigen und sehr gutes Geld zu verdienen!! Begeistert? - schreiben Sie uns an elfingo(a)bk.ru und lassen Sie sich genauere Details zumailen. Mit freundlichen Gruessen ELF LTD

1 0

[U-Boot-Users] MPC8360 QENET20 MicroCode Patch
by Russell McGuire 30 May '08

30 May '08

Freescale Crowd, Has anyone already started implementation of the microcode patches for the QE_ENET20 errata for U-boot? Guessing it is not hot on the list, since it probably only affects 10BaseT users. If not, does anyone have any quick suggestions on where the patch should get loaded, i.e. at what point during the driver? Or should I put this as a board specific patch? -Russ

1 0