Re: [U-Boot] ?Q?Re=3A=20=5BU=2DBoot=5D=20MAKEALL=20ml507=5Fflash=20return=20=22Not=20enough=20room=20for

Hi Benny, > Hi Michal, > > Good to hear from you. > > You are exactly right about the issue with my FLASH not being mapped to > the end of the memory mapped space. Hence, the initial boot code could > not jump far enough to it. > > I need a 64k BRAM block sitting on the end of memory address s

Re: [U-Boot] =?us-ascii?Q?Re=3A=20=5BU=2DBoot=5D=20MAKEALL=20ml507=5Fflash=20return=20=22Not=20enough=20room=20for

Hi Michal, Good to hear from you. You are exactly right about the issue with my FLASH not being mapped to the end of the memory mapped space. Hence, the initial boot code could not jump far enough to it. I need a 64k BRAM block sitting on the end of memory address so I can't back my FLASH mappi

[U-Boot] Patches for in-house board

Hi, We are a consulting firm that has produced a product for a client which contains at Atmel AT91SAM9263 running linux. I have registed a machine type at kernel.org and have ported both u-boot and the kernel to it. I have created patches to add this support against u-boot HEAD. Is it standard

Re: [U-Boot] [PATCH] Flex-OneNAND driver

Hi We can provide two device registration for SLC and MLC are but I don't know how useful it is because FlexOneNand provides boundary settings and user can configure SLC and MLC area and other point is still device registration is separate how user will get any gain as it will be on same die

Re: [U-Boot] Building u-boot for the AT91RM9200-EK circa 2008

Wolfgang Denk <[EMAIL PROTECTED]> wrote: > The thing is: we will not accept any such (new) code for > mainline. And switching to using the CFI driver is trivial. Okay then. I was able to compile u-boot 1.3.4 for the AT91RM9200DK with changes so that it can handle writing to the flash on my cus

Re: [U-Boot] Regarding uboot

kishore wrote: > hi frnds, > Actually i am planing to develop a boot loader for power pc board (mpc866) > of embedded planet, can any one help me out wht r the reqiurements for that. > pl

Re: [U-Boot] [patch V2] U-Boot Firetux board support

Hi Juergen, Juergen Schoew wrote: > Hi U-Boot mailling list, > > This patchset adds a new ARM board with the NXP PNX8181 cpu to u-boot. > The PNX8181 is an ARM926ej with an internal DSP (mostly used for Audio > processing and VOIP codecs) and a baseband processor (used for DECT). The > chip also f

Re: [U-Boot] [PATCH] [OneNAND] bad block aware read/write support

Hi, On Wed, Nov 5, 2008 at 5:40 PM, Stefan Roese <[EMAIL PROTECTED]> wrote: > Hi Kyungmin, > > On Tuesday 04 November 2008, Stefan Roese wrote: >> > Update OneNAND command to support bad block awareness >> > Also change the OneNAND command styel like NAND >> >> I'm starting with OneNAND support fo

Re: [U-Boot] [PATCH v3] Freescale NFC NAND driver

On Tue, Nov 04, 2008 at 07:02:41PM -0700, John Rigby wrote: > +#define MIN(x, y)((x < y) ? x : y) Please use the min() macro defined in include/common.h. > +static struct fsl_nfc_private { > + struct mtd_info mtd; > + char spare_only; > + char status_req; > + u16 col_a

Re: [U-Boot] [PATCH 9/9] mpc8641: Support 36-bit physical addressing

On Nov 5, 2008, at 2:55 PM, Becky Bruce wrote: > This patch creates a memory map with all the devices > in 36-bit physical space, in addition to the 32-bit map. > The CCSR relocation is moved (again, sorry) to > allow for the physical address to be 36 bits - this > requires translation to be enab

Re: [U-Boot] [PATCH] at91: board specific lowlevel_init.S

Dear Jean-Christophe PLAGNIOL-VILLARD, In message <[EMAIL PROTECTED]> you wrote: > > > The attribute ".weak" works only if the file where is the weak function > > is not in a library. > This method of build will not generate a library evenif it's still called > libat91.a, it will generate a pre-bu

[U-Boot] [PATCH 9/9] mpc8641: Support 36-bit physical addressing

This patch creates a memory map with all the devices in 36-bit physical space, in addition to the 32-bit map. The CCSR relocation is moved (again, sorry) to allow for the physical address to be 36 bits - this requires translation to be enabled. With 36-bit physical addressing enabled, we are no lo

[U-Boot] [PATCH 2/9] mpc86xx: Move setup_bats into cpu_init_f

In order to later allow for a physical relocation of the flash, setup_bats, which sets up the final BAT mapping for the board, needs to happen *after* init_laws(). Otherwise, there will be no window programmed for the flash at the new physical location at the point when we change the mmu translatio

[U-Boot] [PATCH 8/9] mpc8641: Change 32-bit memory map

The memory map on the 8641hpcn is modified to look more like the 85xx boards; this is a step towards a more standardized layout going forward. As part of this change, we now relocate the flash. The regions for some of the mappings were far larger than they needed to be. I have reduced the mapping

[U-Boot] [PATCH 4/9] mpc8641: Drop imaginary second flash bank, map 8MB

There's a lot of setup and foo for the second flash bank. The problem is, this board doesn't actually have one. Clean this up. Also, the flash is 8M in size. Get rid of the confusing aliased overmapping, and just map 8M. Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> --- board/freescale/mpc864

[U-Boot] [PATCH 3/9] mpc8641: only define CONFIG_ENV_SIZE once

It's currently defined twice inside in an if/else block, but both halves set the same value. Move the define outside the if. Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> --- include/configs/MPC8641HPCN.h |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/include/configs

[U-Boot] [PATCH 5/9] mpc8641: make DIAG_ADDR == FLASH_BASE

Currently, that's what it is, but it's hardcoded. Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> --- include/configs/MPC8641HPCN.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index d77f0fc..0a6d5f9 100644

[U-Boot] [PATCH 0/9] MPC8641 memory map changes/cleanup/36-bit

board/freescale/mpc8641hpcn/config.mk |2 +- board/freescale/mpc8641hpcn/law.c | 30 ++-- cpu/mpc86xx/cpu_init.c|4 + cpu/mpc86xx/start.S | 90 +++- include/configs/MPC8610HPCD.h |9 + include/configs/MPC8641HPCN.h | 2

[U-Boot] [PATCH 6/9] mpc86xx: Use SRR0/1/rfi to enable address translation, not blr

Using a mtmsr/blr means that you have to be executing at the same virtual address once you enable translation. This is unnecessarily restrictive, and is not really how this is usually done. Change it to use the more common mtspr SRR0/SRR1 and rfi method. Signed-off-by: Becky Bruce <[EMAIL PROTEC

[U-Boot] [PATCH 7/9] mpc86xx: Change early FLASH mapping to 1M at CONFIG_MONITOR_BASE_EARLY

We define CONFIG_MONITOR_BASE_EARLY to define the initial location of the bootpage in flash. Use this to create an early mapping definition for the FLASH, and change the early_bats code to use this. This change facilitates the relocation of the flash since the early mappings are no longer tied

[U-Boot] [PATCH 1/9] mpc8641: Remove extra "0" from BR2 define

Signed-off-by: Becky Bruce <[EMAIL PROTECTED]> --- include/configs/MPC8641HPCN.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/MPC8641HPCN.h b/include/configs/MPC8641HPCN.h index 1401e15..779e9a8 100644 --- a/include/configs/MPC8641HPCN.h +++ b/include/c

Re: [U-Boot] =?us-ascii?Q?Re=3A=20=5BU=2DBoot=5D=20MAKEALL=20ml507=5Fflash=20return=20=22Not=20enough=20room=20for

Hi Benny and Ricardo, How are you Benny? I am not xilinx ppc expert but it seems to me that your problem is in Flash baseaddr. I haven't worked with ppc440 but I worked with ppc405. The point is that ppc starts on specific address. I think from end of memory space (address like 0xFFFC or any

Re: [U-Boot] [PATCH v3] Freescale NFC NAND driver

Fabio Estevam wrote: > >> +#define NFC_BUF_ADDR(NFC_REG_BASE + 0x1E04) >> +#define NFC_FLASH_ADDR (NFC_REG_BASE + 0x1E06) >> +#define NFC_FLASH_CMD (NFC_REG_BASE + 0x1E08) >> +#define NFC_CONFIG (NFC_REG_BASE + 0x1E

Re: [U-Boot] [PATCH v2] Freescale NFC NAND driver

Magnus Lilja wrote: > Hi > > 2008/11/5 John Rigby <[EMAIL PROTECTED]>: > >> Reworked MPC5121 NAND driver. >> Attempted to address all the problems listed by Scott Wood. >> Driver is now board independent. Will still need more >> work to be SOC independent. >> >> Driver for the NAND controller o

Re: [U-Boot] [PATCH] at91: board specific lowlevel_init.S

On 18:29 Wed 05 Nov , Ilko Iliev wrote: > Dear Jean, > > Jean-Christophe PLAGNIOL-VILLARD wrote: > > On 12:45 Tue 28 Oct , Ilko Iliev wrote: > > > >> Dear Jean-Christophe, > >> > >> Jean-Christophe PLAGNIOL-VILLARD wrote: > >> > >>> On 22:20 Mon 27 Oct , Wolfgang Denk wrote: >

Re: [U-Boot] [PATCH] at91: board specific lowlevel_init.S

Dear Jean, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 12:45 Tue 28 Oct , Ilko Iliev wrote: > >> Dear Jean-Christophe, >> >> Jean-Christophe PLAGNIOL-VILLARD wrote: >> >>> On 22:20 Mon 27 Oct , Wolfgang Denk wrote: >>> >>> Dear Jean-Christophe PLAGNIOL-VILLARD,

Re: [U-Boot] [PATCH] strings: use puts() rather than printf()

Mike Frysinger wrote: > When running `strings` on really long strings, the stack tends to get > smashed due to printf(). Switch to puts() instead since we're only passing > the data through. ...which raises the question of why we don't have vsnprintf(). -Scott ___

Re: [U-Boot] [PATCH v3] Freescale NFC NAND driver

--- On Tue, 11/4/08, John Rigby <[EMAIL PROTECTED]> wrote: > From: John Rigby <[EMAIL PROTECTED]> > Subject: [U-Boot] [PATCH v3] Freescale NFC NAND driver > To: u-boot@lists.denx.de, "Scott Wood" <[EMAIL PROTECTED]> > Cc: "John Rigby" <[EMAIL PROTECTED]> > Date: Tuesday, November 4, 2008, 11:02 PM

[U-Boot] Regarding uboot

hi frnds, Actually i am planing to develop a boot loader for power pc board (mpc866) of embedded planet, can any one help me out wht r the reqiurements for that. pl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/list

Re: [U-Boot] [PATCH] [OneNAND] bad block aware read/write support

Hi Kyungmin, On Tuesday 04 November 2008, Stefan Roese wrote: > > Update OneNAND command to support bad block awareness > > Also change the OneNAND command styel like NAND > > I'm starting with OneNAND support for a MIPS platform right now and wasn't > ware that the onenand commands were not bad b

Re: [U-Boot] [PATCH v2] Freescale NFC NAND driver

Hi 2008/11/5 John Rigby <[EMAIL PROTECTED]>: > Reworked MPC5121 NAND driver. > Attempted to address all the problems listed by Scott Wood. > Driver is now board independent. Will still need more > work to be SOC independent. > > Driver for the NAND controller on MPC5121. > > This driver has been