On Thu, Sep 17, 2009 at 5:42 PM, Mikhail Zaturenskiy
wrote:
> We finally solved our DRAM timing problem so I wanted to follow up on
> my question.
>
> On Fri, Sep 4, 2009 at 1:41 AM, Frank Svendsbøe
> wrote:
>> Hi Mikhail,
>> Burst mode UPM setup is not trivial, and it is quite amount of work to
Peter,
On Wed, 2009-09-16 at 21:38 -0500, Peter Tyser wrote:
> The more standard 'source' command provides identical functionality to
> the autoscr command.
>
> Environment variable names/values on the MVBC_P, MVBML7, kmeter1,
> mgcoge, and km8xx boards are updated to no longer refernce 'autoscr'
Hi Sergey,
Thank you for your work. I have updated the sparc repository with your
patch. And, yes, you are probably the first one to use the standalone
app feature :)
Please CC me next time.
Thanks,
Daniel
Сергей Миронов wrote:
>Hi! Thanks for the beautiful project! Ive tried to launch stand
Dear Rahanesh,
In message <4ab30cd8.7020...@tataelxsi.co.in> you wrote:
>
> I wanted to know the meaning of Device Offset in the config file
> (fw_env.config).
Please see "tools/env/README".
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
Hello Wolfgang,
Please pull the u-boot-sparc.git master branch.
This patch fixes the SPARC support for standalone u-boot applications.
The problem was that I neve finished the implementation in the first
place.
jmp ensures we get back to the location we came from, size(void *) make
sure we get
Signed-off-by: Marcel Ziswiler
Acked-by: Guennadi Liakhovetski
Acked-by: Heiko Schocher
---
Changes since v1:
- CC all respective board maintainers
Changes since v2:
- Added Guennadi Liakhovetski's ack
Changes since v3:
- Added Heiko's ack for IDS8247, mgcoge and muas3001
README
Peter Tyser wrote on 17/09/2009 19:29:18:
> From:
>
> Peter Tyser
>
> To:
>
> Joakim Tjernlund
>
> Cc:
>
> pieter.voorthuij...@prodrive.nl, u-boot@lists.denx.de, Wolfgang Denk
>
>
> Date:
>
> 17/09/2009 19:29
>
> Subject:
>
> Re: [U-Boot] [TESTING PATCH] ppc: Relocation test patch
>
> On Th
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk
> Sent: Thursday, September 17, 2009 1:14 PM
> To: Thomas Jackson
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] U-Boot load and run via NAND flash - ARM926EJ
Hello Peter,
On Wed, 2009-09-16 at 21:38 -0500, Peter Tyser wrote:
> The more standard 'source' command provides identical functionality to
> the autoscr command.
>
> Environment variable names/values on the MVBC_P, MVBML7, kmeter1,
> mgcoge, and km8xx boards are updated to no longer refernce 'aut
Hello Wolfgang,
This patch fixes the SPARC support for standalone u-boot applications.
SPARC/LEON3
=> tftpboot 0x4100 192.168.0.47:hello_world.bin
Using GRETH 10/100 device
TFTP from server 192.168.0.47; our IP address is 192.168.0.206
Filename 'hello
Looks good.
Any plans on adding support on 8572 and/or p2020?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi, all!
I'm trying to implement splash screen on OMAP35xx-based device
with 128x128 1bpp display connected using RFBI, plain parallel interface.
Display has controller and own memory, and is controlled with parallel
interface, 8-bit wide data bus and signals.
This display works under Linux, but
> > On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
> > > >
> > > > When preparing the ppc relocation patches I noticed that the gcc
> > > > -mrelocatable compiler flag increases the .reloc section by 3 or 4
> > > > Kbytes. I did a compile test, and this increase pushes the ALPR board
Peter Tyser wrote on 18/09/2009 16:28:35:
>
>
> > > On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
> > > > >
> > > > > When preparing the ppc relocation patches I noticed that the gcc
> > > > > -mrelocatable compiler flag increases the .reloc section by 3 or 4
> > > > > Kbytes. I did
On Fri, 2009-09-18 at 16:52 +0200, Joakim Tjernlund wrote:
> Peter Tyser wrote on 18/09/2009 16:28:35:
> >
> >
> > > > On Thu, 2009-09-17 at 09:06 +0200, Joakim Tjernlund wrote:
> > > > > >
> > > > > > When preparing the ppc relocation patches I noticed that the gcc
> > > > > > -mrelocatable compi
Peter Tyser wrote on 18/09/2009 17:21:57:
> >
> > Sorry, I don't have an example. Just a guess, weak function references:
> >
> > void weak_fun(void) __attribute__ ((weak));
> > if (weak_fun)
> >weak_fun();
>
> Using default weak functions as well as overridden weak functions both
> definitely
Signed-off-by: Kumar Gala
---
* Updated for new -t option
Makefile|7 +--
include/configs/MPC8572DS.h |4
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 99837a3..8672336 100644
--- a/Makefile
+++ b/Makefile
@@ -2514,1
Signed-off-by: Kumar Gala
---
* Updated for new -t option
Makefile |7 +--
include/configs/P2020DS.h |4
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 8672336..1e25669 100644
--- a/Makefile
+++ b/Makefile
@@ -2518,12 +2
Signed-off-by: Kumar Gala
---
* Updated for new -t option
Makefile| 22 --
include/configs/P1_P2_RDB.h | 13 +
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/Makefile b/Makefile
index 1e25669..d8daa89 100644
--- a/Makefile
Sergey Lapin wrote:
> Hi, all!
>
> I'm trying to implement splash screen on OMAP35xx-based device
> with 128x128 1bpp display connected using RFBI, plain parallel interface.
> Display has controller and own memory, and is controlled with parallel
> interface, 8-bit wide data bus and signals.
>
>
> > > Sorry, I don't have an example. Just a guess, weak function references:
> > >
> > > void weak_fun(void) __attribute__ ((weak));
> > > if (weak_fun)
> > >weak_fun();
> >
> > Using default weak functions as well as overridden weak functions both
> > definitely work. So the pointers must b
On Fri, Sep 18, 2009 at 11:35:33AM +0800, Mingkai Hu wrote:
> diff --git a/Makefile b/Makefile
> index 99837a3..4d18a9f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2446,6 +2446,7 @@ vme8349_config: unconfig
> ATUM8548_config: unconfig
> @$(MKCONFIG) $(@:_config=) ppc mpc85xx a
Peter Tyser wrote on 18/09/2009 18:24:48:
>
>
> > > > Sorry, I don't have an example. Just a guess, weak function references:
> > > >
> > > > void weak_fun(void) __attribute__ ((weak));
> > > > if (weak_fun)
> > > >weak_fun();
> > >
> > > Using default weak functions as well as overridden weak
On Fri, Sep 18, 2009 at 01:17:48PM +0900, J.Hwan.Kim wrote:
> Hi, everyone
>
> I'm using U-boot 2009-03.
> U-boot hangs in nand_init() function.
> I found the routine kmalloc in nand_scan_tail() cause U-boot reset.
>
>
> int nand_scan_tail(struct mtd_info *mtd)
> {
> int i;
> struct nand
Try2: to list..
On Fri, Sep 18, 2009 at 11:08 AM, Dirk Behme wrote:
>
> Sergey Lapin wrote:
> > Hi, all!
> >
> > I'm trying to implement splash screen on OMAP35xx-based device
> > with 128x128 1bpp display connected using RFBI, plain parallel interface.
> > Display has controller and own memory, a
On Sep 17, 2009, at 10:35 PM, Mingkai Hu wrote:
> nand_spl/board/freescale/mpc8536ds/u-boot.lds | 67 +
Can we move this to some common location? cpu/mpc85xx/u-
boot_nand_spl.lds?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http:/
On Sep 17, 2009, at 10:35 PM, Mingkai Hu wrote:
> diff --git a/cpu/mpc85xx/cpu_init_nand.c b/cpu/mpc85xx/cpu_init_nand.c
> new file mode 100644
> index 000..e62f8d3
> --- /dev/null
> +++ b/cpu/mpc85xx/cpu_init_nand.c
> @@ -0,0 +1,69 @@
> +/*
> + * Copyright 2009 Freescale Semiconductor, Inc.
On Sat, Sep 12, 2009 at 06:01:40PM +0900, Shinya Kuribayashi wrote:
> The commit ecad289fc6bd9d89ef4d5093cc7b6fd712fd0d29 (OneNAND: Remove
> unused read_spareram and add unlock_all as kernel does) forgot to remove
> a local reference to read_spareram in board/micronas/vct/ebi_onenand.c,
> which cau
On Wed, Sep 16, 2009 at 02:26:53PM +1000, Paul Gibson wrote:
> Micron nand flash needs a reset before a read command is issued.
> The current mpc5121_nfc driver ignores the reset command.
>
> Signed-off-by: Paul Gibson
>
> ---
> drivers/mtd/nand/mpc5121_nfc.c |1 +
> 1 files changed, 1 inse
On Sep 17, 2009, at 10:45 PM, Mingkai Hu wrote:
> Signed-off-by: Mingkai Hu
> ---
>
> Sorry for the spam, ingnor the [PATCH] mpc8536: simplify the top
> makefile for 36-bit config,
> this is the new version.
>
> Makefile|4 +---
> include/configs/MPC8536DS.h |2 +-
>
On Sat, Aug 29, 2009 at 01:00:59PM +0900, Kyungmin Park wrote:
> #define READ_INTERRUPT()\
> - onenand_readw(THIS_ONENAND(ONENAND_REG_INTERRUPT))
> + onenand_readw(ONENAND_REG_INTERRUPT)
You could get rid of the newli
On Wed, Sep 02, 2009 at 06:05:03PM +0900, Kyungmin Park wrote:
> Some board use more then 2KiB OneNAND IPL.
> E.G., S5PC100 loads 16KiB OneNAND IPL
Why do we need a different image name based on how large the loader is?
-Scott
___
U-Boot mailing list
U-
On CoreNet based platforms the CCSRBAR address is split between an high &
low register and we no longer shift the address.
Signed-off-by: Kumar Gala
Signed-off-by: Scott Wood
---
cpu/mpc85xx/cpu_init_early.c | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
The p4080 SoC has a significant amount of commonality with the 85xx/PQ3
platform. We reuse the 85xx immap and just add new definitions for
local access and global utils. The global utils is now broken into
global utils, clocking and run control/power management.
The offsets from CCSR for a numbe
The CoreNet platform style of bringing secondary cores out of reset is
a bit different that the PQ3 style. Mostly the registers that we use
to setup boot translation, enable time bases, and boot release the cores
have moved around.
Signed-off-by: Kumar Gala
---
cpu/mpc85xx/mp.c | 68 +
On CoreNet based platforms the LAW address is split between an high &
low register and we no longer shift the address. Also, the target IDs
on CoreNet platforms have been completely re-assigned.
Additionally, added a new find_law() API to which LAW an address hits in.
This is need for the CoreNet
On CoreNet style platforms the timebase frequency is the bus frequency
defined by 16 (on PQ3 it is divide by 8). Also on the CoreNet platforms
the core not longer controls the enabling of the timebase. We now need
to enable the boot core's timebase via CCSR register writes.
Signed-off-by: Kumar
There are various locations that we have chip specific info:
* Makefile for which ddr code to build
* Added p4080 & p4040 to cpu_type_list and SVR list
* Added number of LAWs for p4080
* Set CONFIG_MAX_CPUS to 8 for p4080
Signed-off-by: Kumar Gala
---
cpu/mpc85xx/Makefile|1 +
cpu/m
This patch series includes the underpinings for the p4080 support. Its mostly
focussed on the differenes in cpu/mpc85xx code between a PQ3/85xx platform
and the p4080/CoreNet platforms.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/ma
The means to determine the core, bus, and DDR frequencies are completely
new on CoreNet style platforms. Additionally on p4080 we can have
different frequencies for FMAN and PME IP blocks. We need to keep track
of the FMAN & PME frequencies since they are used for time stamping
capabilities insid
> From: Sandeep Paulraj
>
> This patch adds support for the leopard board which is
> based on the DM355 SOC.
>
> Signed-off-by: Sandeep Paulraj
> ---
> Makefile |3 +
> board/davinci/dm355leopard/Makefile | 52 +
> board/davinci/dm355leopar
> From: Sandeep Paulraj
>
> This patch enables EMAC on the DM365 EVM.
>
> Signed-off-by: Sandeep Paulraj
> ---
> board/davinci/dm365evm/dm365evm.c | 38
> +
> 1 files changed, 38 insertions(+), 0 deletions(-)
>
Pushed to u-boot-ti
_
Kumar Gala wrote:
> + u32 lawbarh0; /* 0xc00 - LAW0 base address register high */
> + u32 lawbarl0; /* 0xc04 - LAW0 base address register low */
> + u32 lawar0; /* 0xc08 - LAW0 attributes register */
> + u8 res4[4];
> + u32 lawbarh1;
In message <1253043494-11436-1-git-send-email...@denx.de> you wrote:
> Commit 51003b89 attempted to fix a build problem on 64 bit systems,
> but just turned it into a build problem on 32 bit systems (silly me).
>
> Now do the Right Thing (TM) and use a "%zu" printf format.
>
> Also fix spelling e
In message <1252966161-14156-1-git-send-email...@denx.de> you wrote:
> Fix warning: flash.c:531: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
>
> Signed-off-by: Wolfgang Denk
> Cc: Kári Davíðsson
> ---
> v2: change implementation as suggested by Scott Wood in
>
From: Sandeep Paulraj
In the DaVinci specific code, we use both CONFIG_SOC_DM646X and
CONFIG_SOC_DM646x to represent DM646x specific code.
This patch changes occurrences of CONFIG_SOC_DM646x to
CONFIG_SOC_DM646X. This is because for DM644x series of SOCs we use
the flag CONFIG_SOC_DM644X. We want
In message <20090916133226.bcd3d832e...@gemini.denx.de> I wrote:
> Hi everybody...
>
> The reorganization of the ARM custodian setup has caused some changes
> to the workflow, and I wonder if we should allow for a longer merge
> window?
>
> What do you think about stretching the MW by another wee
On Sep 18, 2009, at 4:20 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> +u32 lawbarh0; /* 0xc00 - LAW0 base address register high */
>> +u32 lawbarl0; /* 0xc04 - LAW0 base address register low */
>> +u32 lawar0; /* 0xc08 - LAW0 attributes register */
>> +
The p4080 SoC has a significant amount of commonality with the 85xx/PQ3
platform. We reuse the 85xx immap and just add new definitions for
local access and global utils. The global utils is now broken into
global utils, clocking and run control/power management.
The offsets from CCSR for a numbe
Kumar Gala wrote:
> void set_law(u8 idx, phys_addr_t addr, enum law_size sz, enum law_trgt_if id)
> {
> +#ifdef CONFIG_FSL_CORENET
> + volatile ccsr_local_t *ccm;
> + volatile u32 *base, *lawbarh, *lawbarl, *lawar;
We don't really need the volatile...
> void disable_law(u8 idx)
> {
>
Scott Wood wrote:
>> +base = &(ccm->lawbarh0);
>
> Use in_be32(). Likewise in find_law.
Grr, ignore me. I just had my brain baked by an ISO9000 presentation.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinf
Scott Wood wrote:
> Scott Wood wrote:
>
>>> +base = &(ccm->lawbarh0);
>>>
>> Use in_be32(). Likewise in find_law.
>>
>
> Grr, ignore me. I just had my brain baked by an ISO9000 presentation.
>
>
You should always just go home after those things. Let someone else
drive, tho
Kumar Gala wrote:
> On CoreNet style platforms the timebase frequency is the bus frequency
> defined by 16 (on PQ3 it is divide by 8). Also on the CoreNet platforms
> the core not longer controls the enabling of the timebase. We now need
> to enable the boot core's timebase via CCSR register writ
Hi Javier,
On 9/17/09, javier Martin wrote:
> Has anyone tested ethernet connection in this board?
>
yes, it is working fine!
Best Regards,
Alan
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to
On Wed, 16 Sep 2009 23:21:59 +0400
Anton Vorontsov wrote:
> This patch fixes various ethernet issues with gigabit links handling
> in U-Boot. The workarounds originally implemented by Kim Phillips for
> Linux kernel.
>
> Signed-off-by: Anton Vorontsov
> ---
sorry, can't accept - this breaks r1
On Sep 18, 2009, at 4:55 PM, Scott Wood wrote:
>> +#ifdef CONFIG_FSL_CORENET
>> +volatile ccsr_local_t *ccm;
>> +volatile u32 *base, *lawbarh, *lawbarl, *lawar;
>> +
>> +ccm = (void *)(CONFIG_SYS_FSL_CORENET_CCM_ADDR);
>> +
>> +base = &(ccm->lawbarh
On Fri, Sep 18, 2009 at 05:40:45PM -0500, Kim Phillips wrote:
> On Wed, 16 Sep 2009 23:21:59 +0400
> Anton Vorontsov wrote:
>
> > This patch fixes various ethernet issues with gigabit links handling
> > in U-Boot. The workarounds originally implemented by Kim Phillips for
> > Linux kernel.
> >
>
On Friday 18 September 2009 18:36:54 Peter Tyser wrote:
> +TOTAL_CNT=0
> + TOTAL_CNT=`expr ${TOTAL_CNT} + 1`
do you have an aversion to using POSIX math ?
: $((TOTAL_CNT += 1))
-mike
signature.asc
Description: This is a digitally signed message part.
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to
This change adds some basic summary information to the MAKEALL script.
The summary information includes how many boards were compiled, how many
boards had compile warnings or errors, and which specific boards had
compile warnings or errors.
This information is useful when doing compile testing to
> > diff --git a/cpu/mpc85xx/cpu_init_nand.c
> > +void cpu_init_f(void)
> > +{
> > + ccsr_lbc_t *lbc = (void *)(CONFIG_SYS_MPC85xx_LBC_ADDR);
> > +
> > + /*
> > +* LCRR - Clock Ratio Register - set up local bus timing
> > +* when needed
> > +*/
> > + out_be32(&lbc->lcrr, LCRR_DB
On Sat, Sep 19, 2009 at 4:37 AM, Scott Wood wrote:
> On Wed, Sep 02, 2009 at 06:05:03PM +0900, Kyungmin Park wrote:
>> Some board use more then 2KiB OneNAND IPL.
>> E.G., S5PC100 loads 16KiB OneNAND IPL
>
> Why do we need a different image name based on how large the loader is?
>
Actually, S5PC10
On Sat, Sep 19, 2009 at 4:26 AM, Scott Wood wrote:
> On Sat, Aug 29, 2009 at 01:00:59PM +0900, Kyungmin Park wrote:
>> #define READ_INTERRUPT() \
>> - onenand_readw(THIS_ONENAND(ONENAND_REG_INTERRUPT))
>> + onenand_rea
Fix build warnings by putting specific used variables
under required #ifdefs for removing:
mem.c:227: warning: unused variable 'f_sec'
mem.c:226: warning: unused variable 'f_off'
mem.c:225: warning: unused variable 'size'
mem.c:224: warning: unused variable 'base'
mem.c:222: warning: unused variabl
Export enable_gpmc_cs_config into common header to
prevent warning:
warning: implicit declaration of function 'enable_gpmc_cs_config'
Signed-off-by: Nishanth Menon
---
include/asm-arm/arch-omap3/sys_proto.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/asm-arm
Defaults are for infenion DDR timings.
Since none of the supported boards currently do
XIP boot, these seem to be faulty. fix the values
as per the calculations(ACTIMA,B), conf
the sdrc power with pwdnen and wakeupproc bits
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |
From: David Brownell
Start of SDP3430 support in "mainline"
u-boot mainline code
Original Patch written by David Brownell
Support default jumpering and:
- UART1/ttyS0 console(legacy sdp3430 u-boot)
- UART3/ttyS2 console (matching other boards,
and SDP HW docs)
- Ethernet
-
This is questionable if this is really required
as the av_ static initalized values should have
been loaded to sdram as part of the boot process
and initialization should have been done.
Signed-off-by: Nishanth Menon
---
common/dlmalloc.c |5 +
1 files changed, 5 insertions(+), 0 deletio
Hi,
This series of patch provides minimal support for
OMAP3430 based OMAP3 platform
Ref:
http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?templateId=6123&navigationId=12013&contentId=28741
David Brownell (1):
ARM:OMAP3:SDP3430: initial support
Nishanth Menon (5):
OMAP3: Fix SDRC ini
gpmc_config should not be a variant as it is board specific
hence make it a const parameter
Signed-off-by: Nishanth Menon
---
cpu/arm_cortexa8/omap3/mem.c |6 +++---
include/asm-arm/arch-omap3/sys_proto.h |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/cpu
The get_clock_freq() comes from freescale/common/cadmus.c and is
only valid for the CDS based 85xx reference platforms. It would
be nice if we could read the 33 vs. 66MHz status somehow, but in
the meantime, tie it to CONFIG_SYS_CLK_FREQ like all the other
non-CDS boards do.
Signed-off-by: Paul G
Create a board_eth_init to allow a place to hook in
the PCI ethernet init after all the eTSEC are up
and configured.
Signed-off-by: Paul Gortmaker
---
board/sbc8548/sbc8548.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/board/sbc8548/sbc8548.c b/board/sbc8548/
This series represents a significant usability improvement to the
sbc8548 board, by delivering:
-64MB SODIMM flash now usable from u-boot
-PCI and PCI-e properly configured and functional
-twice the size of LBC SDRAM available
-easy selection of configuration via
The sbc8548 has a 64MB SODIMM flash module off of CS6 that
previously wasn't enumerated by u-boot. There were already
BR6/OR6 settings for it [used by cpu_init_f()] but there
was no TLB entry and it wasn't in the list of flash banks
reported to u-boot.
The location of the 64MB flash is "pulled ba
Prior to this commit, to enable PCI, you had to go manually
edit the board config header, and if you had 33MHz PCI, you
had to manually change CONFIG_SYS_NS16550_CLK too, which was
not real user friendly,
This adds the typical PCI and clock speed make targets to the
toplevel Makefile in accordance
There are a couple defines and PCI bridge quirks related to the PCI
backplane of the MPC8548CDS that have no meaning in the context of
the port to the sbc8548 board, so delete them.
Also, the form factor of the sbc8548 is a standalone board with a
single PCI-X and a single PCI-e slot. That pretty
The size of the LB SDRAM on this board is 128MB, spanning CS3
and CS4. It was previously only being configured for 64MB on
CS3, since that was what the original codebase of the MPC8548CDS
had. In addition to setting up BR4/OR4, this also adds the TLB
entry for the second half of the SDRAM.
Signe
The previous README.sbc8548 was pretty much content-free. Replace
it with something that actually gives the end user some relevant
hardware details, and also lists the u-boot configuration choices.
Also in the cosmetic department, fix the bogus line in the Makefile
that was carried over from the S
The PCI/PCI-e support for the sbc8548 was based on an earlier
version of what the MPC8548CDS board was using, and in its
current state it won't even compile. This re-syncs it to match
current MPC85xxCDS/MDS PCI-e support.
It borrows from the MPC8568MDS, in that it pulls the PCI-e I/O
back to 0xe2
On Sep 18, 2009, at 6:08 PM, Paul Gortmaker wrote:
> There are a couple defines and PCI bridge quirks related to the PCI
> backplane of the MPC8548CDS that have no meaning in the context of
> the port to the sbc8548 board, so delete them.
>
> Also, the form factor of the sbc8548 is a standalone b
81 matches
Mail list logo
