February 2008 - U-Boot

[U-Boot-Users] Flash write crash on MPC8548CDS
by ksi＠koi8.net 20 Feb '08

20 Feb '08

1.3.2-rc1-gb6f29c84-dirty crashes on the very first attempt to write in Flash. After that it gets back to the prompt and _ALL_ subsequent writes work just fine. Only the very first one fails. Looks like something is not initialized properly. Before I start digging does anyone has a fix for it? This is quite new platform for me so it could take time for me to come up with a fix... Here is what happens on the very first Flash write attempt (original config with no changes, stock MPC8548CDS with SW2[1..2] set to "off-off", was "off-on" out of the box for booting Freescale's U-Boot 1.1.something from alternate Flash.) === Cut === U-Boot 1.3.2-rc1-gb6f29c84-dirty (Feb 19 2008 - 13:34:21) CPU: 8548_E, Version: 2.1, (0x80390021) Core: E500, Version: 2.2, (0x80210022) Clock Configuration: CPU:1320 MHz, CCB: 528 MHz, DDR: 264 MHz, LBC: 66 MHz L1: D-cache 32 kB enabled I-cache 32 kB enabled Board: CDS Version 0x13, PCI Slot 1 CPU Board Revision 0.0 (0x0000) I2C: ready DRAM: Initializing SDRAM: 64 MB DDR: 256 MB FLASH: 16 MB L2 cache 512KB: enabled PCI: 64 bit, unknown MHz, async, host, external-arbiter Scanning PCI bus 00 PCI on bus 00 - 02 PCIE connected to slot as Root Complex (base address e000a000) PCIE on bus 3 - 3 In: serial Out: serial Err: serial Net: eTSEC0, eTSEC1, eTSEC2, eTSEC3 Hit any key to stop autoboot: 0 => saveenv Saving Environment to Flash... Un-Protected 4 sectors Erasing Flash... .... done Erased 4 sectors Writing to Flash... External Interrupt Exception at PC: ffc1e2c, SR: 29200, vector=500 irq IACK0@e00600a0=2 NIP: 0FFC1E2C XER: 00000000 LR: 0FFCEBF4 REGS: 0ff5dc50 TRAP: 0500 DAR: 00000000 MSR: 00029200 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00 GPR00: 00029200 0FF5DD40 0FF9DF78 00010000 00000000 00000555 FF800AAA 32C45D1D GPR08: 00000000 FF810000 0FF5DD2B 0FFF5404 0FF5DBA0 40ED2D4B 0FFF5100 00000000 GPR16: 0FFEC778 0FFEE784 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 0FF5DD78 0FF5DD88 00000001 FFFFF146 E4010000 0FF5DD33 0FFF572C 0FFF5404 Call backtrace: 0FF5DD33 0FFCEB8C 0FFCF8C8 0FFDD27C 0FFDCCCC 0FFD9B50 0FFDF230 0FFDE944 0FFDEAB0 0FFD2384 0FFC9810 0FFC15FC Skipping current instr, Returning to 0x0ffc1e30 done Protected 4 sectors => === Cut === --- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

2 2

[U-Boot-Users] [PATCH] 8610HPCD: Don't use VIDEO/CFB_CONSOLE by default.
by Jon Loeliger 20 Feb '08

20 Feb '08

Without an actual supported video card hooked up, enabling the CONFIG_VIDEO by default just makes it look broken by routing all console output to the video card. Don't. Signed-off-by: Jon Loeliger <jdl(a)freescale.com> --- Wolfgang, I'll drop this in my -mpc86xx tree for a -rc2 pickup! Thanks, jdl include/configs/MPC8610HPCD.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/MPC8610HPCD.h b/include/configs/MPC8610HPCD.h index 3920147..9e70198 100644 --- a/include/configs/MPC8610HPCD.h +++ b/include/configs/MPC8610HPCD.h @@ -24,7 +24,7 @@ #define CONFIG_FSL_DIU_FB 1 /* FSL DIU */ /* video */ -#define CONFIG_VIDEO +#undef CONFIG_VIDEO #if defined(CONFIG_VIDEO) #define CONFIG_CFB_CONSOLE -- 1.5.4.rc5.19.g0509eb

2 2

[U-Boot-Users] [PATCH] 86xx: Fix GUR PCI config registers properly.
by Jon Loeliger 20 Feb '08

20 Feb '08

Back in commit 975a083a5ef785c414b35f9c5b8ae25b26b41524 where I tried to "8610HPCD: Fix typos in two PCI setup registers", I botched it due to not realizing that 8610 and 8641 had different Global Utility Register defintions, one of which was like 85xx, and the other wasn't. Correct this problem by introducing two symbols, one for each 86xx SoC, but neither of which is named anything like 85xx. My bad. Lovely Wednesday with git bisect. You know. Signed-off-by: Jon Loeliger <jdl(a)freescale.com> --- Wolfgang, I'll drop this in my -mpc86xx tree for a -rc2 pickup! Thanks, jdl board/freescale/mpc8610hpcd/mpc8610hpcd.c | 6 ++++-- board/freescale/mpc8641hpcn/mpc8641hpcn.c | 6 ++++-- include/asm-ppc/immap_86xx.h | 10 ++++++++-- 3 files changed, 16 insertions(+), 6 deletions(-) diff --git a/board/freescale/mpc8610hpcd/mpc8610hpcd.c b/board/freescale/mpc8610hpcd/mpc8610hpcd.c index d5a4f0e..16acbbe 100644 --- a/board/freescale/mpc8610hpcd/mpc8610hpcd.c +++ b/board/freescale/mpc8610hpcd/mpc8610hpcd.c @@ -280,8 +280,10 @@ void pci_init_board(void) volatile immap_t *immap = (immap_t *) CFG_CCSRBAR; volatile ccsr_gur_t *gur = &immap->im_gur; uint devdisr = gur->devdisr; - uint io_sel = (gur->pordevsr & MPC86xx_PORDEVSR_IO_SEL) >> 19; - uint host_agent = (gur->porbmsr & MPC86xx_PORBMSR_HA) >> 16; + uint io_sel = (gur->pordevsr & MPC8610_PORDEVSR_IO_SEL) + >> MPC8610_PORDEVSR_IO_SEL_SHIFT; + uint host_agent = (gur->porbmsr & MPC8610_PORBMSR_HA) + >> MPC8610_PORBMSR_HA_SHIFT; printf( " pci_init_board: devdisr=%x, io_sel=%x, host_agent=%x\n", devdisr, io_sel, host_agent); diff --git a/board/freescale/mpc8641hpcn/mpc8641hpcn.c b/board/freescale/mpc8641hpcn/mpc8641hpcn.c index ae79143..0e451dc 100644 --- a/board/freescale/mpc8641hpcn/mpc8641hpcn.c +++ b/board/freescale/mpc8641hpcn/mpc8641hpcn.c @@ -206,7 +206,8 @@ void pci_init_board(void) volatile immap_t *immap = (immap_t *) CFG_CCSRBAR; volatile ccsr_gur_t *gur = &immap->im_gur; uint devdisr = gur->devdisr; - uint io_sel = (gur->pordevsr & MPC86xx_PORDEVSR_IO_SEL) >> 16; + uint io_sel = (gur->pordevsr & MPC8641_PORDEVSR_IO_SEL) + >> MPC8641_PORDEVSR_IO_SEL_SHIFT; #ifdef CONFIG_PCI1 { @@ -214,7 +215,8 @@ void pci_init_board(void) extern void fsl_pci_init(struct pci_controller *hose); struct pci_controller *hose = &pci1_hose; #ifdef DEBUG - uint host1_agent = (gur->porbmsr & MPC86xx_PORBMSR_HA) >> 17; + uint host1_agent = (gur->porbmsr & MPC8641_PORBMSR_HA) + >> MPC8641_PORBMSR_HA_SHIFT; uint pex1_agent = (host1_agent == 0) || (host1_agent == 1); #endif if ((io_sel == 2 || io_sel == 3 || io_sel == 5 diff --git a/include/asm-ppc/immap_86xx.h b/include/asm-ppc/immap_86xx.h index 6143062..7526061 100644 --- a/include/asm-ppc/immap_86xx.h +++ b/include/asm-ppc/immap_86xx.h @@ -1256,10 +1256,16 @@ typedef struct ccsr_rio { typedef struct ccsr_gur { uint porpllsr; /* 0xe0000 - POR PLL ratio status register */ uint porbmsr; /* 0xe0004 - POR boot mode status register */ -#define MPC86xx_PORBMSR_HA 0x00060000 +#define MPC8610_PORBMSR_HA 0x00070000 +#define MPC8610_PORBMSR_HA_SHIFT 16 +#define MPC8641_PORBMSR_HA 0x00060000 +#define MPC8641_PORBMSR_HA_SHIFT 17 uint porimpscr; /* 0xe0008 - POR I/O impedance status and control register */ uint pordevsr; /* 0xe000c - POR I/O device status regsiter */ -#define MPC86xx_PORDEVSR_IO_SEL 0x000F0000 +#define MPC8610_PORDEVSR_IO_SEL 0x00380000 +#define MPC8610_PORDEVSR_IO_SEL_SHIFT 19 +#define MPC8641_PORDEVSR_IO_SEL 0x000F0000 +#define MPC8641_PORDEVSR_IO_SEL_SHIFT 16 #define MPC86xx_PORDEVSR_CORE1TE 0x00000080 /* ASMP (Core1 addr trans) */ uint pordbgmsr; /* 0xe0010 - POR debug mode status register */ char res1[12]; -- 1.5.4.rc5.19.g0509eb

1 0

[U-Boot-Users] [PATCH] Fix fdt boardsetup command parsing
by Kumar Gala 20 Feb '08

20 Feb '08

The introduciton of the 'fdt bootcpu' broke parsing for 'fdt boardsetup'. Signed-off-by: Kumar Gala <galak(a)kernel.crashing.org> --- common/cmd_fdt.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c index c31560b..26f09ad 100644 --- a/common/cmd_fdt.c +++ b/common/cmd_fdt.c @@ -324,7 +324,8 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[]) /******************************************************************** * Set boot cpu id ********************************************************************/ - } else if ((argv[1][0] == 'b') && (argv[1][1] == 'o')) { + } else if ((argv[1][0] == 'b') && (argv[1][1] == 'o') && + (argv[1][0] == 'o')) { unsigned long tmp = simple_strtoul(argv[2], NULL, 16); fdt_set_boot_cpuid_phys(fdt, tmp); -- 1.5.4.1

2 2

[U-Boot-Users] IDE/ATAPI, videocard on MPC8548CDS
by ksi＠koi8.net 20 Feb '08

20 Feb '08

I wonder if somebody used IDE/ATAPI on MPC8548CDS. It has VIA VT82C686B chip on Arcadia motherboard that work just fine with no problems with Freescale's supplied 2.6.11 Linux kernel. It's a common chip with generic register layout etc. so stock common/cmd_ide.c should work once supplied with proper base address and offsets. The problem is I've just started with that platform so I don't know yet how memory and I/O is mapped. I will be digging and I will grok it soon but it will take time. Can anybody point me in the right direction? I'm going to put Fedora on the thing and I would've liked to boot it off of IDE HDD rather than from Flash. That would make regular Fedora update mechanism work without additional steps for burning kernel/initFS to Flash... I would also like to enable a PCI/PCI-E videocard but that can wait, I'll have the platform groked by the time it come to that so I will be able to do it myself. Any help is highly appreciated... --- ****************************************************************** * KSI@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************

1 0

[U-Boot-Users] FW: [PATCH][ARM] Rationalize ARM compiler options
by Peter Pearse 20 Feb '08

20 Feb '08

> -----Original Message----- > From: Peter Pearse [mailto:peter.pearse@arm.com] > Sent: 14 February 2008 13:59 > To: 'wd(a)denx.de' > Subject: RE: [U-Boot-Users] [PATCH][ARM] Rationalize ARM > compiler options > > > > -----Original Message----- > > From: wd(a)denx.de [mailto:wd@denx.de] > > Sent: 13 February 2008 22:51 > > To: Peter Pearse > > Cc: U-Boot-Users > > Subject: Re: [U-Boot-Users] [PATCH][ARM] Rationalize ARM compiler > > options > > > > > > Please don't add too many empty lines. > > > > OK - I'll change thie when I re-submit. > I just like to be able to ripple thru my buffers to animate > the differences between almost identical files. > > > Why exactly are you dropping -msoft-float here? > > I was under the delusion that dropping this protected against > incorporation of floating point instructions. > > Have I now got a clear understanding of the position:- > > " > The use of floating point arithmetic in the U-Boot code is > deprecated. > However the ELDK toolchains provide floating point support > and were built with the -msoft-float option. This option is > supplied to the code to ensure any floating point arithmetic > included links in the floating point support code correctly. > " > > If so I'll put -msoft-float in all arm config.mk files. > > > > > > -# Make ARMv5 to allow more compilers to work, even though its v6. > > > -PLATFORM_CPPFLAGS += -march=armv5 > > > +PLATFORM_CPPFLAGS += -march=armv6 > > > > Why exactly are you changing this? > > arm1136 is an ARM Architecture V6 processor. > > My position is: > " > The main (arm) tree processor options should use the correct > architecture option for the processor (provided this option > is accepted without error or warning by the ELDK arm > toolchains) Users using compilers which do not support the > correct architecture should be made aware of this. > Should they wish to use another compiler they can change this > option locally. > " > > I would also accept > (reluctantly, although it saves lots of space I could waste > as empty lines ;-) ) > > " > For simplicity, the main (arm) tree processor options use the > lowest common architecture option (armv4), whatever the > processor implements. Users can change this option locally. > " > > At present we have a mixture..... > > Regards > > Peter > >

4 8

Re: [U-Boot-Users] FW: [PATCH][ARM] Rationalize ARM compiler options
by Peter Pearse 20 Feb '08

20 Feb '08

> -----Original Message----- > From: Ulf Samuelsson [mailto:ulf.samuelsson@atmel.com] > Sent: 20 February 2008 00:40 > To: Peter Pearse > Subject: Re: [U-Boot-Users] FW: [PATCH][ARM] Rationalize ARM > compiler options > ---snip--- > > > > My postion remains that U-Boot is supplied to build with the latest > > ELDK toolchain. > > Supporting all possible toolchains (and all possible builds of those > > toolchains) > > is too much effort. > > Since I have already implemented a fix in my private U-boot I > know this to be false (at least for this specific problem). > I'm not clear here - are you saying that the arm compiler options, in the current U-Boot head, prevent one or more boards building with arm-linux-gcc (GCC) 4.0.0 (DENX ELDK 4.1.4.0.0) (excluding build systems which treat all warnings as errors)? If so, please supply details. Regards Peter

2 1

[U-Boot-Users] U-Boot on Windows
by Ramy Mamdouh 20 Feb '08

20 Feb '08

Dear all I need to make U-Boot on Windows, is that possible? and if yes how can I do that? Regards,

4 4

[U-Boot-Users] [PATCH v2] PPC440EPx: Reconfigure PLL for 667MHz processor
by Mike Nuss 20 Feb '08

20 Feb '08

On PPC440EPx without a bootstrap I2C EEPROM, the PLL can be reconfigured after startup in order to change the speed of the clocks. This patch adds the option CONFIG_667MHZ. If set, it will set the clocks to run at full speed on a 667MHz PPC440EPx without the need for an external EEPROM. Signed-off-by: Mike Nuss <mike(a)terascala.com> Cc: Stefan Roese <sr(a)denx.de> -- Addresses changes suggested by Stefan; move PLL reconfiguration into a separate function. diff --git a/cpu/ppc4xx/cpu_init.c b/cpu/ppc4xx/cpu_init.c index 2e0dd6f..fd663af 100644 --- a/cpu/ppc4xx/cpu_init.c +++ b/cpu/ppc4xx/cpu_init.c @@ -99,10 +99,107 @@ DECLARE_GLOBAL_DATA_PTR; # endif #endif /* CFG_INIT_DCACHE_CS */ +#ifndef CFG_PLL_RECONFIG +#define CFG_PLL_RECONFIG 0 +#endif + +void reconfigure_pll(u32 new_cpu_freq) +{ +#if defined(CONFIG_440EPX) + int reset_needed = 0; + u32 reg, temp; + u32 prbdv0, target_prbdv0, /* CLK_PRIMBD */ + fwdva, target_fwdva, fwdvb, target_fwdvb, /* CLK_PLLD */ + fbdv, target_fbdv, lfbdv, target_lfbdv, + perdv0, target_perdv0, /* CLK_PERD */ + spcid0, target_spcid0; /* CLK_SPCID */ + + /* Reconfigure clocks if necessary. + * See PPC440EPx User's Manual, sections 8.2 and 14 */ + if (new_cpu_freq == 667) { + target_prbdv0 = 2; + target_fwdva = 2; + target_fwdvb = 4; + target_fbdv = 20; + target_lfbdv = 1; + target_perdv0 = 4; + target_spcid0 = 4; + + mfcpr(clk_primbd, reg); + temp = (reg & PRBDV_MASK) >> 24; + prbdv0 = temp ? temp : 8; + if (prbdv0 != target_prbdv0) { + reg &= ~PRBDV_MASK; + reg |= ((target_prbdv0 == 8 ? 0 : target_prbdv0) << 24); + mtcpr(clk_primbd, reg); + reset_needed = 1; + } + + mfcpr(clk_plld, reg); + + temp = (reg & PLLD_FWDVA_MASK) >> 16; + fwdva = temp ? temp : 16; + + temp = (reg & PLLD_FWDVB_MASK) >> 8; + fwdvb = temp ? temp : 8; + + temp = (reg & PLLD_FBDV_MASK) >> 24; + fbdv = temp ? temp : 32; + + temp = (reg & PLLD_LFBDV_MASK); + lfbdv = temp ? temp : 64; + + if (fwdva != target_fwdva || fbdv != target_fbdv || lfbdv != target_lfbdv) { + reg &= ~(PLLD_FWDVA_MASK | PLLD_FWDVB_MASK | + PLLD_FBDV_MASK | PLLD_LFBDV_MASK); + reg |= ((target_fwdva == 16 ? 0 : target_fwdva) << 16) | + ((target_fwdvb == 8 ? 0 : target_fwdvb) << 8) | + ((target_fbdv == 32 ? 0 : target_fbdv) << 24) | + (target_lfbdv == 64 ? 0 : target_lfbdv); + mtcpr(clk_plld, reg); + reset_needed = 1; + } + + mfcpr(clk_perd, reg); + perdv0 = (reg & CPR0_PERD_PERDV0_MASK) >> 24; + if (perdv0 != target_perdv0) { + reg &= ~CPR0_PERD_PERDV0_MASK; + reg |= (target_perdv0 << 24); + mtcpr(clk_perd, reg); + reset_needed = 1; + } + + mfcpr(clk_spcid, reg); + temp = (reg & CPR0_SPCID_SPCIDV0_MASK) >> 24; + spcid0 = temp ? temp : 4; + if (spcid0 != target_spcid0) { + reg &= ~CPR0_SPCID_SPCIDV0_MASK; + reg |= ((target_spcid0 == 4 ? 0 : target_spcid0) << 24); + mtcpr(clk_spcid, reg); + reset_needed = 1; + } + + /* Set reload inhibit so configuration will persist across + * processor resets */ + mfcpr(clk_icfg, reg); + reg &= ~CPR0_ICFG_RLI_MASK; + reg |= 1 << 31; + mtcpr(clk_icfg, reg); + } + + /* Reset processor if configuration changed */ + if (reset_needed) { + __asm__ __volatile__ ("sync; isync"); + mtspr(dbcr0, 0x20000000); + } +#endif +} + /* * Breath some life into the CPU... * - * Set up the memory map, + * Reconfigure PLL if necessary, + * set up the memory map, * initialize a bunch of registers */ void @@ -111,6 +208,7 @@ cpu_init_f (void) #if defined(CONFIG_WATCHDOG) unsigned long val; #endif + reconfigure_pll(CFG_PLL_RECONFIG); #if (defined(CONFIG_405EP) || defined (CONFIG_405EX)) && !defined(CFG_4xx_GPIO_TABLE) /*

1 0

Re: [U-Boot-Users] U-Boot on Windows (Ramy Mamdouh)
by Tim Braun 20 Feb '08

20 Feb '08

> Date: Wed, 20 Feb 2008 13:10:58 +0200 > From: "Ramy Mamdouh" <rmamdouh.ese(a)gmail.com> > Subject: [U-Boot-Users] U-Boot on Windows > > Dear all > > I need to make U-Boot on Windows, is that possible? and if yes how can I do > that? Building U-Boot on Windows is done every day. You install the cygwin tools, get yourself a cross-compiler, and you may have to tweak a few Makefiles for .exe executable suffixes (for the tools which are built). The uclibc people have reasonable build scripts for cross-compilers. You can get an ARM cross-compiler from a few places. I built the MIPSEL cross-compiler we use from the uclibc scripts. http://buildroot.uclibc.org/ There's extra info building just the tool-chain: http://buildroot.uclibc.org/buildroot.html#toolchain_standalone Since u-boot doesn't use libc, you can also not use uclibc... which is to say that a uclibc based toolchain isn't a problem for building u-boot. Tim Braun, Sr. Des. Eng. LibreStream Technologies http://www.librestream.com 895 Waverley St., Suite 110, Winnipeg, MB R3T 5P4

1 0