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-
Dave-R63238
Cc: u-boot@lists.denx.de; Richard Retanubun
Subject: MPC8360 arbiter settings
Hello Anton and Dave,
I am seeing these MPC83xx arbiter settings in most boards except the 8360 ones.
(Consistent with Ravi Chandran's recommendation at
http://www.freescale.com/files/training_present
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
> +/*
> + * Copy the code for other cpus to execute into an
> + * aligned location accessible via BPTR
> + */
> +void setup_mp(void)
> +{
> + extern ulong __secondary_start_page;
> + ulong fixup = (ulong)&__secondary_start_page;
> + u32 bootpg;
> + u32 bootpg_va;
> +
> + /*
> +
> +int board_early_init_f (void)
> +{
> + volatile u32 *pmuxcr = (u32 *)(CONFIG_SYS_IMMR + 0xe0060);
> + u32 val;
> +
> + val = *pmuxcr;
> + val |= 0x6000;
> + *pmuxcr = val;
> +
> + return 0;
> +}
> +
Andy, How about using the in/out_be32 for this?
Thanks,
Dave
__
> diff --git a/board/freescale/mpc837xemds/mpc837xemds.c
> b/board/freescale/mpc837xemds/mpc837xemds.c
> index acf8ada..57747be 100644
> --- a/board/freescale/mpc837xemds/mpc837xemds.c
> +++ b/board/freescale/mpc837xemds/mpc837xemds.c
> @@ -22,6 +22,7 @@
>
> int board_early_init_f(void)
> {
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Fleming
> Andy-AFLEMING
> Sent: Friday, October 31, 2008 6:36 AM
> To: [EMAIL PROTECTED]
> Cc: u-boot@lists.denx.de; Fleming Andy-AFLEMING
> Subject: [U-Boot] [PATCH 07/10] Add support for the Freescal
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Fleming
> Andy-AFLEMING
> Sent: Friday, October 31, 2008 6:36 AM
> To: [EMAIL PROTECTED]
> Cc: u-boot@lists.denx.de; Fleming Andy-AFLEMING
> Subject: [U-Boot] [PATCH 06/10] Add MMC Framework
>
> Here'
> From: Kumar Gala [mailto:[EMAIL PROTECTED]
> On Oct 23, 2008, at 8:59 AM, Dave Liu wrote:
>
> > The patch is following the commit
> > 392438406041415fe64ab8748ec5ab5ad01d1cf7
> >
> > mpc86xx: use r4 instead of r2 in lock_ram_in_cache and
> > unlock_ram_in_cache
> >
> > This is needed in unl
Thanks David Hawkins,
> -Original Message-
> From: David Hawkins [mailto:[EMAIL PROTECTED]
> Sent: 2008?10?8? 11:51 AM
> To: u-boot@lists.denx.de
> Cc: Liu Dave-R63238; Phillips Kim-R1AAHA
> Subject: Re: [U-Boot-Users] Freescale MPC8349EMDS BCSR corruption
>
Hello Anton,
1)
I strongly suggest you use the hardware reset configuration word from
flash,
not from FPGA.
You can set the PCI host and internal arbiter enabled in the HRCW in
flash
to avoid these issue.
2)
Also, I strongly suggest you use the production 837xEMDS pilot rev2.05
board.
Because the
It is due to hardware design and logic defect, that is the
I/O[0:7] of NAND chip is connected to LAD[7:0], so when
the NAND chip connected to nLCS3, you have to set up the
OR3[BCTLD] = '1' for normal operation, otherwise it will have
bus contention due to the pin 48/25 of U60 is enabled.
Setup th
90 matches
Mail list logo
