Priyanka,
If you use gcc version 4.7.2 (GCC), it will pass the build
Regards,
Dave
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On
Behalf Of Jain Priyanka-B32167
Sent: Thursday, August 29, 2013 3:31 PM
To: u-boot@lists.denx.de
Subject: [U-
Michael,
How are you?
I believe we missed to change these for 8360. if you can submit a patch for
this, it is better.
Thanks a lot.
Dave
-Original Message-
From: Michael Barkowski [mailto:michaelbarkow...@ruggedcom.com]
Sent: Tuesday, October 23, 2012 5:25 AM
To: Anton Vorontsov; Liu
NACK.
> diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c index
> 9885b14..8a97c1b
> 100644
> --- a/arch/powerpc/lib/board.c
> +++ b/arch/powerpc/lib/board.c
> @@ -75,9 +75,7 @@
> #include
> #endif
>
> -#ifdef CONFIG_ADDR_MAP
> #include
> -#endif
>
> #ifdef CONFIG_MP
> #in
> > Timur,
> > Any reason not to use in_be8?
> > The first version code is finished by me some months ago. at that
time I used
> the in_be8.
>
> What first version code? Did you implement this feature, too?
http://git.ap.freescale.net/gitweb/?p=u-boot-p1022.git;a=commitdiff;h=45
ddca32e5f288e81a
>> /* There is no __raw_writeq(), so do the write manually */
>> *(volatile u64 *)addr = value;
>> -if (sw)
>> +if (sw) {
>> +/*
>> + * To ensure the post-write is completed to eLBC, software must
>> + * perform a dummy read from one valid addre
>After adding some more stuff in start.S I find that a lwz isn't
> enough. An extra isync fixes this though
> lwz r4, LBLAWAR1(r3)
> isync
> So something is missing but what? I guess isync isn't it either but
> it works for now.
Joakim,
Please post more code to the list to have a better understa
> Wouldn't the fact that you're accessing the same address -- and
> that it's cache inhibited -- eliminate the need for a sync instruction
> between the stw and lwz?
You are right. If st and ld the same address, e300 core have a address
collision inside.
It will make sure the order. Here we don't
> The experts found an issue within init code and it looks like a proper
> patch will be added to mainline shortly.
> The discussion of the proper fix is right in this thread ...
It should be timing issue in the SoC, software did not have a proper
process to handle
IMMR registers accessing.
I agr
> Has anyone else tested 83xx on NOR?
> My guess is that cache line crossing shifted so that now the CPU
> doesn't need to read in a new cache at the critical part.
I notice this is hot thread for 83xx in these days.
Anybody can share more background for the issue?
I would like have a look the iss
> stumbled over board_pci_host_broken() in
> board/freescale/mpc837xemds/mpc837xemds.c
>
> Is this a board specific error (wiring) or a CPU issue ?
>
> Wonder if this could apply to my MPC8377 based system, too ...
Andre,
Sorry for the late
It is board specific error in some early MPC837xEPB bo
> It look same as other PQ2/3 which using BR0/OR0 to set boot vecror
base address.
>
> just confirm, do you know CPU will read RCW data before it jump to
0x_FFFC?
Yes. CPU reset module must fetch RCW and configure CPU itself.
then reset to 0x_FFFC, it is also same as PQ3.
Thanks,
Dave
> For that reset address question, I think because p4080ds's FPGA can do
this address
> decode and map 0xefff to 0x setting by SW7, is it right?
No. FPGA doesn't matter with it.
The e500mc core boot start address(0x_FFFC) will point to the end of
CS0 Flash due to OR0[AM]=0.
In thi
>
> Now I am use p4080ds board from freescale, I download U-Boot
>
> 2010.06 version.I check the board code for freescale, just
>
> find p2020 directory, no p4080 board.
>
> You said U-Boot has basic support for P4080, can you give
>
> some more detail informaion such as file name or directory
>There is nothing to 'implement'. Page mode flash has a
>timing parameter indicating the time to the first read,
>and then the time for subsequent reads within a page
>to return.
>
>If you are interfacing to this flash using a processor
>local bus controller, then you generally only have one
>read
> Add basic suport for the Freescale P1022DS reference board.
> +#elif defined(CONFIG_P1022)
> +static struct pci_info pci_config_info[] =
> +{
> + [LAW_TRGT_IF_PCIE_1] = {
> + .agent = (1 << 0) | (1 << 1),
> + .cfg = (1 << 6) | (1 << 7) | (1 << 9) | (1 << 0xa) |
>
> > +#ifdef CONFIG_P1022
>
> This should be something like CONFIG_FSL_SATA_V2. While
> P1022 is the first others will need this change and its more
> specific the the 2nd generation of the SATA HW IP block.
Good idea, CONFIG_FSL_SATA_V2 is better.
__
> > @@ -191,6 +192,19 @@ int init_sata(int dev)
> > /* Wait the controller offline */
> > ata_wait_register(®->hstatus, HSTATUS_ONOFF, 0, 1000);
> >
> > +#ifdef CONFIG_SYS_P1022_ERRATUM_SATA-A001
>
> This should just be #ifdef CONFIG_SYS_FSL_SATA_ERRATUM_A001
> (the A001 # is not specifi
> >>> - if (hw->desc[0] != (unsigned int)ad)
> >>> - hw->desc[0] = (unsigned int)ad;
> >>> + if (in_be32(&hw->desc[0]) != (unsigned int)ad)
> >>> + out_be32(&hw->desc[0], ad);
> >
> >> 'ad' should be cast to a u32, not an "unsigned int". You
> >> shouldn't compare a sized type wi
> > @@ -369,8 +370,8 @@ static int fsl_diu_enable_panel(struct
> fb_info *info)
> > struct diu_ad *ad = &fsl_diu_fb_ad;
> >
> > debug("Entered: enable_panel\n");
> > - if (hw->desc[0] != (unsigned int)ad)
> > - hw->desc[0] = (unsigned int)ad;
> > + if (in_be32(&hw->desc[0]) !
> Read-to-read/Write-to-write turnaround for same chip select
> of DDR3 memory, BL/2+2 cycles is enough for these turnarounds.
> Cutting down the turnaround from BL/2+4 to BL/2+2 will improve
> the memory performance.
Please ignore this patch, I will provide one better solution to address
this per
> The default value of the prescaler of eSDHC clock frequency
> is 0x80, so we need to mask the MSB to set a different clock,
> or else it maybe make the behavior of this prescaler undefined.
>
> Signed-off-by: Mingkai Hu
> ---
> include/fsl_esdhc.h |2 +-
> 1 files changed, 1 insertions(+
> > The code was assuming the initial speed is 1000Mbps, so the
>> 1000 case did nothing.
>
> Hmm.. but what happend, if you connect a 100Mbps, and then
> back to the 1000Mpbs?
The ethernet port may be broken :)
___
U-Boot mailing list
U-Boot@lists.de
> > I don't remember why I added the eth_type==GIGA_ETH condition.
> > If it is possible, please refactor it as Kim.
>
> Hmm.. while looking at this code, a question comes in mind:
> Did this code (eth_type==GIGA_ETH) work correctly?
Yes, It worked correctly. But later there are lots of change,
I
> did you make any effort to refactor this into the existing
> eth_type == GIGA_ETH code? I'm not sure why that code became
> conditional in commit
> 24c3aca3f1358b113d3215adb5433b156e99f72b "mpc83xx: Add
> support for the MPC832XEMDS board" in the first place - Dave?
I don't remember why I a
> The memory controller could already be enabled, when spd_sdram() is
> called. This could be the case for example, when the SDRAM is
> initialized
> by the JTAG debugger.
>
> Signed-off-by: Stefan Roese
> Cc: Reinhard Arlt
> Cc: Kim Phillips
Acked-by: Dave Liu
__
> 3. TIMING_CFG_5[RODT_ON] should be set to WL-2
> 4. TIMING_CFG_5[RODT_OFF] should be set to WL-1
> 5. TIMING_CFG_5[WODT_ON] should be set to WL-2
> 6. TIMING_CFG_5[WODT_OFF] should be set to WL-1
I would like hold on the patch, There are still issue on ODT
settings.
Please don't apply the patch.
> > > Is there a SDCARD support for MPC8315e?
> >
> > Yes. Have a look the drivers/mmc
>
> Hm... AFAIK, 8315 chips don't include eSDHC controller.
>
> (It is still possible to connect SD cards via SPI, but mmc
> spi driver isn't yet included into U-Boot.)
Anton is right, I was assuming the 831
> Is there a SDCARD support for MPC8315e?
Yes. Have a look the drivers/mmc
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> 1. TIMING_CFG_0[ACT_PD_EXIT] was set to 6 clocks, but
>It should be set to tXP parameter, tXP=max(3CK, 7.5ns)
> 2. TIMING_CFG_0[PRE_PD_EXIT] was set to 6 clocks, but
>It should be set to tXP (if MR0[A12]=1) else to tXPDLL parameter
>We are setting the mode register MR0[A12]='1'
> 3. T
> On Tue, 2009-11-10 at 08:42 +0800, Liu Dave-R63238 wrote:
> > > IIRC, 85xx cache is enabled, so when we do the ecc error inject
> > > test, What will happen before disable ecc error inject?
> > > I-fetch may get wrong instruction?
>
> If you're inj
83xx ECC test code is really perfect, but it is regretful that it can
not reused to 85xx/86xx right now.
I'm not sure which approach is better between Peter's and this.
Because I still have not read carefully Peter's code.
> Update 83xx boards to use the same ECC driver that the 85xx and 86xx
>
> > IIRC, 85xx cache is enabled, so when we do the ecc error
> inject test,
> > What will happen before disable ecc error inject?
> > I-fetch may get wrong instruction?
>
> and
> Because cache is enabled, data bus assume 64 bits (it is normal case).
> The DDR bus will have 4-beat burst. So t
> IIRC, 85xx cache is enabled, so when we do the ecc error inject test,
> What will happen before disable ecc error inject?
> I-fetch may get wrong instruction?
and
Because cache is enabled, data bus assume 64 bits (it is normal case).
The DDR bus will have 4-beat burst. So the error informat
> You can inject data in the upper/lower 32 bit data path, or in the ecc
> path using the "ecc inject" command shown above. The inject command
> takes a mask that is XORed with the proper data, eg "ecc
> inject low 0x5"
> would result in data bits 0 and 2 always being swapped resulting in
> multi
How to use these command to test the ECC?
Specially, how to inject multi error in 64bit data bus?
Thanks, Dave
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Peter Tyser
> Sent: Tuesday, November 10, 2009 7:37 AM
> To: u-boo
> > 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
> -Original Message-
> From: Heiko Schocher [mailto:h...@denx.de]
> Sent: Tuesday, August 25, 2009 7:32 PM
> To: Liu Dave-R63238
> Cc: Phillips Kim-R1AAHA; U-Boot user list
> Subject: [PATCH v2] mpc83xx: update LCRR register handling
>
> MPC8379E RM says (10-34)
> MPC8379E RM says (10-34):
> Once LCRR[CLKDIV] is written, the register should be read, and then
> an isync should be executed.
> So update this in code.
> Also define a LCRR mask for processors, which uses not all bits
> in the LCRR register (as for example mpc832x did).
>
> Signed-off-by: Heiko
> Well, that's what the other patch I sent does (the link above), but
> there were wishes then to handle this above the driver layer, hence
> this patch :-)
>
> I'm fine with either way, but if there are other drivers with
> alignment requirements, I'd prefer this variant.
I believe some Freesca
>
> See to it that sent data is aligned to the ethernet controllers wishes
>
> This patch adds a send_alignment member to the eth_device structure
> which specifies what the alignment requirements are for the particular
> device. eth_send checks this alignment on sends, and if it
> doesn't match
> >>> with this patch, this mpc8313 board does this:
> >>>
> >>> U-Boot 2009.06-00524-g28958b8 (Jul 23 2009 - 18:33:11) MPC83XX
> >>>
> >>> Reset Status:
> >>>
> >>> CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
> >>> Board: Freescale MPC8313ERDB
> >>> I2C: ready
> >>> DRAM:
> > with this patch, this mpc8313 board does this:
> >
> > U-Boot 2009.06-00524-g28958b8 (Jul 23 2009 - 18:33:11) MPC83XX
> >
> > Reset Status:
> >
> > CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.667 MHz
> > Board: Freescale MPC8313ERDB
> > I2C: ready
> > DRAM: 128 MB
> > FLASH
> > > I've tested this on 86xx boards, it'd be great if someone
> > > could test on
> > > 83xx and 74xx/7xx. 85xx boards should not be affected by
> this change.
> > >
> > > This change assumes
> > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> > > has already been applied, o
> Previously, non-e500 architectures only unlocked their data
> cache which
> was used as early RAM when booting to Linux using the "bootm" command.
> This change causes all PPC boards with
> CONFIG_SYS_INIT_RAM_LOCK defined
> to unlock their data cache during U-Boot's initialization. This
> imp
> According to Ira, the DMA method was faster than the cpu method:
> "It makes the DMA initialization normal speed again. The DMA
> in the for loop takes the longest (as expected).
>
> So yes, strangely it (enabling the icache) makes a HUGE
> difference. The total time is <3 seconds now. It is
> When SDRAM ECC is enabled and CONFIG_ECC_INIT_VIA_DDRCONTROLLER is not
> defined use DMA to set SDRAM to a known state. Previously a
> sequence of
> 64-bit stores was used.
IIRC, the DMA init SDRAM is slower than the 64bit stores.
It is why I added these code here.
I suggest to keep the way.
I believe the question should be sent to u-boot@lists.denx.de,
not linuxppc-dev list.
What is the TLB settings for NAND FCM buffer? Pay attention
to set the TLB as cache inhibited and guarded attribute.
If not set the guarded bit, it is possible to cause the speculate
load from FCM buffer below t
Hi Dave,
Good news, Good summary!
> I modified the MPC8349E-MDS board and can create the
> same problem we were experiencing on our boards;
> CRC errors and data packets with received bytes
> repeated within the receive packets.
>
> So I am certain we have tracked the root cause of
> the problem
> Over the weekend we performed some hardware modifications
> on our boards with their troublesome gigabit interfaces.
>
> We performed a couple of tests, one of which may be
> the solution to our problem.
>
> 1) Modified the value of the series termination of EC_GTX_CLK125
>
> The PHY drive
> The MPC8349EMDS config has had that setting since it was imported into
> U-Boot. I've copied the relevant part of include/configs/MPC8349EMDS.h
> below.
>
> #define CONFIG_SYS_SICRH SICRH_TSOBI1
>
> This seems wrong for the MPC8349EMDS board. I tried setting
> the register
> value to 0x0 by ha
> Did you check the GMII interface (H/W)?
> Like EC_GTX_CLK125, this signal is input for TSEC block for
> 1000Mbps case.
> When you used the 100Mbps, the GTX_CLK125 is not used. Because you are
> Using the MII interface for 100Mbps case.
IIRC, the MV88E has some h/w config option to configure
> > => md e118 1
> > e118: 0002
> >
> > This looks wrong. The MPC8349EMDS board has the exact same
> setting in
> > that register. Writing 0x0 to the SICRH register did not cause the
> > problem to go away.
> >
>
> The MPC8349EMDS config has had that setting since it was imp
Did you check the GMII interface (H/W)?
Like EC_GTX_CLK125, this signal is input for TSEC block for 1000Mbps
case.
When you used the 100Mbps, the GTX_CLK125 is not used. Because you are
Using the MII interface for 100Mbps case.
Thanks, Dave
___
U-Boot ma
> What is the ACR register settings?
> What is the freq of core/csb/DDR and TSEC block?
And what is the SICRH[30-31]?
Did you have the matching settings for GMII with 3.3V?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinf
What is the ACR register settings?
What is the freq of core/csb/DDR and TSEC block?
Thanks, Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> >EELADR - 0XF401, it is INIT_RAM address, why the
> transaction with
> >address(0xF401) go to system bus?
> >It should keep in the cache due to cache lock, never out to
> system bus.
>
> I don't know why... and it just happened shall I allocate
> a entry of tlb for it?? or cover
> My board can't boot normally, and I found it just hang in
> data tlb error
> through the system.map.
> Could any one help for this?
> Some regisers are as below:
>
> DEAR: 0xf400fff0 (L1 init ram base address is 0xf401)
> IVPR : 0xfff8 , IVPR3
> CPU: MPC8536DS [Core E500, Freescale]
> Flash: 16MB [50MHz Local bus Clk)
> DDR: 1G (SODIMM, 400 MHz)
> Baord: Network Evaluation Cutom MPC8536E Board
>
> U-Boot Debug Issue (GPIO Toggling code help)
> _
>
> -> as i am not able to debug uboot over jtag and the CW tool
>
> I have bsp from freescale for mpc8313erdb evalutaion board. the board
> is up and running no issues with it as of now.
> But in u-boot the autoboot option is not enabled and I would like to
> have enabled. I believe that I need to do some changes in the u-boot
> source code.
> Could anyone please
> Interesting. I've tried to use your patch but still hanging
> board_init_f.
> Even putting BOOKE_PAGESZ_256M in set_tlb the problem occur.
Because you are using the 8548 with e500v2 core, so the bug doesn't
effect your board when you are using the 1G DIMMs.
_
> > The tlb settings looks fine (debbug in setup_ddr_tlbs()):
> >
> > ram_tlb_address: 0x0, ram_tlb_address: 0x0, ram_tlb_index:
> 0x8, tlb_size:
> 0xa
> > ram_tlb_address: 0x4000, ram_tlb_address: 0x4000,
> ram_tlb_index:
> 0x9, tlb_size: 0xa
>
> "tlb_size: 0xa" is _not_ fine.
>
No,
> my mpc8572ds (2x 512 MiB ram) had initially u-boot 1.3.0-rc2 and I
> haven't notice any problems. Today I updated u-boot to
> v2009.03 because
> I was not able to boot current vanilla linux kernel in smp mode.
> Since then I experience random kernel opses. I thing it has
> something to
> do wit
> I'm working on a mpc85xx board very similar to MPC8548CDS. I
> have 2 DIMMs and each one with it own spd eeprom and with
> only one chip select (cs0 and cs2). I'm trying to use two 1Gb
> DDR2s. My ddr configurations:
>
> /* DDR Setup */
> #define CONFIG_VERY_BIG_RAM
> #define CONFIG_FSL_DDR2
> I have a custom board similar to MPC8560ADS board with 1GB
> DDR SDRAM. The DDR SDRAM Make
> is MT18VDDF12872DG-335D3. In U-BOOT (2009.01) config file I
> have enabled CONFIG_SPD_EEPROM
> so U-boot configures MPC8560ADS DDR controller with the
> values read from SPD_EEPROM (i2c
> address 0x51)
> I was going thruogh the code of u-boot-1.3.0 and was
> particlarly going through the code in
> board/freescale/mpc8313erdb cause thats my board.
> And i found that relocate_code() function is being declared
> in common.h and called at few instances but could not find
> the definition of the
> I am using u-boot 1.1.6 in MPC8313ERDB custom board. when i'm doing
> Ethernet(tftp) test after 10th iteration "Bus Fault" error
> occur and restart
> the board. The error message is as follows.
>
> ##Bus Fault @
> 0x0900, fixup
> 0x
>
> Thank you very much for information Wolfgang. However I don't
> understand
> why I didn't receive my post on the mailing list, I'm afraid that even
> other people didn't receive it and then I don't receive any
> comments. I checked the option "Receive your own posts to the list" on
my setting
>
> > AFAIK, while running from flash, u-boot uses (part of)
> d-cache on some
> > platforms for the C stack. I think, it's on MPC83xx and MPC85xx?
> >
> > Does anybody know, if I can use the remaining part of the d-cache
> > as normal d-cache, e.g. to generate bursts on the SDRAM interface
> > whi
> I am using a custom board with MPC8313E processor. In u-boot
> prompt, when i
> do TFTP of large size files, sometime it hangs completely
> and, sometimes it
> says bus fault, prints following message and resets the board.
>
> /message
> printed
Hello all,
I often miss some mails from u-boot@lists.denx.de in these days,
For example, we didn't receive the 8569 support patch from lists,
and didn't receive the mail from Kim
http://lists.denx.de/pipermail/u-boot/2009-March/049890.html
http://lists.denx.de/pipermail/u-boot/2009-March/049891.ht
> It seems like the root cause of this problem:
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/53025/
> match=nasty+gunzip+problem+mpc8313e+rdb
>
> As a MPC8313E(-RDB) user I'm happy no more checkstops will
> occur for some kernels. I'm even more happy I took over the
> BAT settings f
Furthermore,
Your patch didn't set the RFXE bit correctly.
It should be
lis r0,hid1_r...@h
ori r0,r0,(HID1_ASTME|HID1_ABE)@l /* Addr streaming &
broadcast */
mtspr HID1,r0
Thanks, Dave
___
U-Boot mailing list
U-Boot@li
> From: Jerry Van Baren [mailto:gvb.ub...@gmail.com]
> Sent: Friday, March 13, 2009 11:40 PM
> To: u-boot@lists.denx.de; Phillips Kim-R1AAHA; Liu Dave-R63238
> Subject: [PATCH v2] Add bank configuration to FSL spd_sdram.c
>
> The routine assumed 4 bank SDRAMs, enhance to confi
> The routine assumed 4 bank SDRAMs, enhance to configure for 4
> or 8 bank SDRAMs.
>
> Signed-off-by: Gerald Van Baren
> ---
>
> I haven't made much headway on adapting the cpu/mpc8/ddr
> routines to the 83xx (8360). It has some 85xx (86xx)
> assumptions in that needs to be pulled out.
> I agree that this is the better approach, and I would be delighted if
> somebody would write and submit that code for both u-boot and Linux.
> It's a few hundred lines and takes careful testing, as we found with
> our proprietary OS.
In fact. u-boot has some support for these error events, check
> Set HID1[RFXE] = 1 in cpu/mpc85xx/start.S. When this bit is 0, any
> condition that asserts the internal core_fault_in* signal will result
> in a processor hang, recoverable only with reset. When this bit is 1,
> such a condition will cause a machine check exception and software
> will have a c
> yes you are right - I'll get this if one of you don't beat me to it.
It is fine for me.
Thanks, Dave
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> > The code actually is ugly. The max operation freq of the whole 83xx
> > DDR controller is lagging the mainstream DDR2 DIMMs.
> > We have to put the high speed DIMMs to low speed controller.
> > It sounds like ugly. So we often happen the boundary issue.
> >
> > Basically, the mainstream PC in
> > 1. RD_TO_PRE missed to add the AL, and need min 2 clocks for
> > tRTP according to DDR2 JEDEC spec.
> > 2. WRTORD - tWTR need min 2 clocks according to DDR2 JEDEC spec.
> > 3. add the support of DDR2-533,667,800 DIMMs
> > 4. cpo
> > 5. make the AL to min to gain better performance.
> >
> > T
Kim,
If not any objection for the patch,
Could you pick it up to 83xx tree to go main tree.
Thanks, Dave
> -Original Message-
> From: Liu Dave-R63238
> Sent: 2009?2?24? 7:10 PM
> To: Phillips Kim-R1AAHA; Fleming Andy-AFLEMING
> Cc: u-boot@lists.denx.de; joakim.tjernl.
> well it applies, but it also nuked the first board I tried it on. For
> any new ddr work on 83xx, I'd suggest starting with porting the new
> common mpc8xxx ddr code.
Agree,
The original spd_spd.c will go away.
___
U-Boot mailing list
U-Boot@lists.den
> > Dave Liu (2):
> > mpc83xx: enable eLBC NAND support for MPC8315ERDB board
> > NAND: Fix cache and memory inconsistency issue
>
>
> This commit (commit c70564e6b1bd08f) broke the SIMPC8313_LP board:
>
> nand_boot_fsl_elbc.o:
> I'm not sure what you are asking about. I agree we have some
> limitations but for the vast majority of boards 8 entries has been
> enough.
It is not real case. If the MP enable, only 7 entries the board can use.
> I'm all for any patches that try and make the allocation a bit more
> dyn
> +#ifndef CONFIG_SYS_DDR_TLB_START
> +#define CONFIG_SYS_DDR_TLB_START 8
> +#endif
> +
> unsigned int setup_ddr_tlbs(unsigned int memsize_in_meg)
> {
> unsigned int tlb_size;
> @@ -137,7 +141,7 @@ unsigned int setup_ddr_tlbs(unsigned int
> memsize_in_meg)
>* Configure DDR TLB1 ent
> Yes, there are two pci_init_board() functions in this file.
> One for PCI
> host mode, and one for PCI agent mode. This version only runs in agent
> mode, it doesn't even get compiled in host mode.
That is fine.
___
U-Boot mailing list
U-Boot@lists.de
> void pci_init_board(void)
> {
> volatile immap_t *immr = (volatile immap_t *)CONFIG_SYS_IMMR;
> - volatile clk83xx_t *clk = (volatile clk83xx_t *)&immr->clk;
> volatile law83xx_t *pci_law = immr->sysconf.pcilaw;
> volatile pcictrl83xx_t *pci_ctrl = &immr->pci_ctrl[0];
>
> u-boot-1.1.6.
Suggest you use the latest u-boot as base, due to the u-boot/kernel
interface has much change since 1.1.6.
> my sdram is 512MB, with CS0_BNDS,DDRLAWAR0,DDRLAWBAR0
> modified, 256MB of
> 512MB sdram can work perfectly.
>
> Then, I defined CONFIG_VERY_BIG_RAM, 512MB can be recogni
> > +static void mpc83xx_pcie_register_hose(int bus, struct
> > pci_region *reg,
> > + u8 link)
> > +{
> > + extern void disable_addr_trans(void); /* start.S */
> > + static struct pci_controller pcie_hose[PCIE_MAX_BUSES];
> If PCIe use the hose which is differ
> This patch adds support for MPC83xx PCI-E controllers in Root Complex
> mode.
>
> The patch is based on Tony Li and Dave Liu work[1].
>
> Though unlike the original patch, by default we don't register PCI-E
> buses for use in U-Boot, we only configure the controllers for future
> use in other O
> + /* Deassert the resets in the control register */
> + out_be32(&sysconf->pecr1, 0xE0008000);
> + if (!pex2)
> + out_be32(&sysconf->pecr2, 0xE0008000);
> + udelay(2000);
> +
> + /* Configure PCI Express Local Access Windows */
> + out_be32(&pcie_law[0].bar, CO
> MPC8315ERDB boards features PCI-E x1 and Mini PCI-E x1 ports. Let's
> support them.
>
> Signed-off-by: Anton Vorontsov
Acked-by: Dave Liu
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> I'll apply it to the "next" branch, but it's not needed for
> the upcoming release because there's no board upstream
> with d-cache enabled.
It is fine, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
> 1. patch should be split into at least two patches. One for
> the first stage loader changes and one for the second stage
> u-boot
absolutely correct. It is also my desired.
Because you query the LAW, I submit the patch for that purpose.
> 2. we should look at refactoring common code so not
> > +void board_init_f(ulong bootflag)
> > +{
> > + volatile ccsr_local_ecm_t *ecm = (void *)
> > (CONFIG_SYS_MPC85xx_ECM_ADDR);
> > + u32 mas0, mas1, mas2, mas3;
> > +
> > + /* init serial port */
> > + NS16550_init((NS16550_t)(CONFIG_SYS_CCSRBAR + 0x4500),
> > +
> Lets post this as part of the NAND boot patch series so it can be
> reviewed in that context. Its not that I'm against this change.
> However I was trying to isolate explicit knowledge of LAW registers
> from the rest of the code base when I added fsl_law.c
You are right, it should be po
> Ok. I'd prefer we just expand the field to 0x3ff to match the EREF
> spec since the upper bits are reserved we'll always read them
> as 0 so no harm. And we dont have to change the code again in
> the future if we expand into those upper bits.
If match the EREF, it should be 0x7ff.
and it al
> Change bne to blt in 85xx clear_bss to protect against the pointer
> never being equal to _end if _end is not word aligned.
> @@ -917,7 +929,7 @@ clear_bss:
> stw r0,0(r3)
> addir3,r3,4
> cmplw 0,r3,r4
> - bne 5b
> + blt 5b
> 6:
Should not they be
> Use CONFIG_SYS_BOOT_BLOCK_{EPN,RPN,PAGESZ} in start.S for the boot
> block TLB for AS=1 mapping. Reduce the default size from 16M to 1M.
>
> Change bne to blt in 85xx clear_bss to protect against the pointer
> never being equal to _end if _end is not word aligned.
>
> Signed-off-by: Ed Swartho
NAND boot
> -Original Message-
> From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> Sent: 2008?12?17? 1:54 AM
> To: Liu Dave-R63238
> Cc: u-boot@lists.denx.de; Loeliger Jon-LOELIGER; Fleming Andy-AFLEMING
> Subject: Re: [U-Boot] [PATCH 3/3] Move the LAW defin
> was code breaking or just fixing it up to match the docs?
not break the system, because the bit[55] is reserved zero for
e500/e500mc.
so just fixied it to match the e500/e500mc docs.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mai
1 - 100 of 115 matches
Mail list logo
