From: Peter Tyser [mailto:[EMAIL PROTECTED]
>
> When agent/end-point, I thought the CPU must enable inbound
> PCI configuration cycles by poking the PBFR Register (offset
> 0x44) for PCI, or the Configuration Ready Register (offset
> 0x4b0 for PCIe) after configuring its own inbound BARs.
Tha
From: Wolfgang Denk [mailto:[EMAIL PROTECTED]
>
> NAK.
>
> Sorry, this doesn't work. We cannot have one board compile
> this way, and another one another way - one working with that
> tool chain and the other with another tool chain only.
Is there a list of the toolchains that -mrelocatable
From: Joakim Tjernlund [mailto:[EMAIL PROTECTED]
>
> The __eabi_uconvert() function skips NULL ptrs.
>
> Perhaps this is the missing piece needed in start.S for PPC?
I'm not seeing any zeros in the .got2 or .fixup entries
in the .reloc section on 85xx when compiling with -mrelocatable.
So I d
From: Loren A. Linden Levy
>
> Is there something like ethtool in U-boot that I can use to
> see what the network negotiated too.
If CONFIG_CMD_MII is set, there is "mii info" and "mii dump".
-Ed
___
U-Boot mailing list
U-Boot@lists.denx.de
http://li
The string pointers in uimage_{arch,os,type,comp}[] are not being
relocated and still point to flash.
If flash is erased (all f's), this causes bootm to trap on a bad
pointer.
This is for powerpc (mpc8572ds). How are they suppose to be relocated?
-EdS
=> boot
boot
## Booting kernel from Legacy
From: Carlos Roberto Moratelli
>
> I am trying to map a PCIe peripherical on my MPC8536 custom board.
> The peripherical is on PCIe1 port.
Is this still an issue?
>pci_init_board: devdisr=40900, sdrs2_io_sel=7, io_sel=7
> Serdes2 disalbed
That is fine.
> PCIE3: disabled
>
> P
From: Carlos Roberto Moratelli
>
> Rigth! I just enabled CONFIG_PCIE1 flag and the PCIE1 bus is detected.
> Now I have this new log:
>
>
> PCIE1 connected to Slot1 as Root Complex (base address ffe0a000)
> Outbound memory range: f800:1 PCICSRBAR @ 0xf7f0 R0
> bus_start: 0
From: Peter Tyser
> Sent: Monday, November 09, 2009 8:09 PM
> Subject: [U-Boot] [PATCH] nfs: NfsTimeout() updates
Tested on MPC8527DS.
Tested by: Ed Swarthout
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
> On Dec 15, 2009, at 12:10 PM, Peter Tyser wrote:
>
> > The gd->cpu pointer is set to an address located in flash when the
> > probecpu() function is called while U-Boot is executing from flash.
> > This pointer needs to be updated to point to
From: Kumar Gala
> Its possible that we try and copy the boot page code out of flash into
> a DDR location that doesn't have a TLB cover it. For example, if we
> have 3G of DDR we typically only map the first 2G. In the cases of
> 4G+ this wasn't an issue since the reset page TLB mapping cove
From: Kumar Gala
>
> On Jan 25, 2010, at 4:44 PM, Wolfgang Denk wrote:
>
> > here is a list of e-mail messages / patches, which I have marked as
> > "open" in my folder. It would we be really helpful if both
submitters
> > and responsible custodians could take a look at these and provide
> >
From: Peter Tyser
> Sent: Tuesday, January 26, 2010 12:44 PM
>
> This *seemed* to work, but I'm probably overlooking something obvious.
> The other thing this patch doesn't do is ever shut down an interface,
> eg prior to booting an OS. I'm also not sure how it would work if
> using multiple i
From: Wolfgang Denk
>
> All patches applied to "reloc" branch. Thanks for all this work.
With -m relocatable, x86emu crashes because the op codes tables are
forced to GOT2 section:
Video: ATI Radeon video card (1002, 5b60) found @(6:0:0)
videoboot: Booting PCI video card bus 6, function 0, devic
From: Edward
> Sent: Thursday, September 24, 2009 11:05 AM
> To: Wolfgang Denk; Peter Tyser
>
> With -m relocatable, x86emu crashes because the op codes
> tables are forced to GOT2 section:
>
> Video: ATI Radeon video card (1002, 5b60) found @(6:0:0)
> videoboot: Booting PCI video card bus 6, fu
From: Peter Tyser
>
>> From: Edward
>>
>> This patch fixes it:
>>
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/48103
>>
>> I still get this crash with latest head (u-boot
>> 2009.08-00338-gcd77dd1).
>
> Thanks Ed,
> To clarify, you're saying that the patch linked above
> just
From: Wolfgang Denk
>
> Dear Vipin KUMAR,
>
> In message <4b908bc8.9030...@st.com> you wrote:
> >
> > > Why would that be needed? Do you really expect to see
> > > both types of interfaces on the same piece of hardware?
> >
> > Yes, that's precisely the case with Spear SoC. It has an FSMC
> >
From: António Silva
>
> I am trying to activate a PCIe link between two MPC8544
> processor's on a custom board.
> One processor is configured as Root Complex
> (cfg_host_agt[0:2] = '111') and
> the other processor as endpoint (cfg_host_agt[0:2] = '101').
I've done this with many different conf
From: sardamaxima
>
> In the first processor (configured as RC) I get the following
...
> ...PCIE LTSSM=0x16, Negotiated link width=1
Good.
>Scanning PCI bus 01
> PCIE1 on bus 00 - 01
...
> In the second processor (configured as EP) I get the
> following output:
> "
>
> ... it's possible for the 'reg' property to be wrong.
Instead of all this, why doesn't u-boot just fix it?
I have the same annoyance with ccsrbar.
U-boot controls the ccsrbar address via a user configured #define.
So instead of having different dts's based on the u-boot ccsrbar,
why can't u-bo
From: Ajeesh Kumar
>
> We have a custom board with MPC8548E processor, please help
> me in suggesting/sharing Ethernet Internal/External Loopback
> testing code piece. Also any Phy level loop back too.
If you have a typical phy and this commit applied, you can use the mii
command to put the ph
From: bosmith
>
> ...
> The use-case is to have two kernel images, two root file
> systems, and to let a user-space application specify which to
> use and then force a reboot. The system will not lose power
> during this reboot.
>
> This seems like a common enough problem. Has anyone solved
21 matches
Mail list logo
