Re: [U-Boot] [PATCH 1/3] PPC 85xx: Detect e500v2 / e500mc during runtime
On Mar 6, 2014, at 9:50 AM, Scott Wood scottw...@freescale.com wrote: On Thu, 2014-03-06 at 09:48 -0600, Kumar Gala wrote: On Jan 23, 2014, at 6:11 AM, Alexander Graf ag...@suse.de wrote: On 21.01.2014, at 03:25, Scott Wood scottw...@freescale.com wrote: On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote: With the qemu-ppce500 machine type we can run the same board with either an e500v2 or an e500mc core plugged in. This means that the IVOR setup can't be based on compile time decisions, so instead we have to do a runtime check which CPU generation we're running on. Is this really the only place where you ran into this? Yup. At least the only place where the difference actually matters for a VM. Also consider that you'll be adding extra size, and some of our 85xx targets are pretty close to the limit as is (though at least this code isn't used in SPLs). I guess nobody ever bothered to set IVORs for e6500-specific exceptions. For that matter, I don't see why we need this code at all. These aren't the addresses that U-Boot keeps its exception vectors at; it's setting them up for the OS, apparently trying to imitate some other type of book3e chip that has fixed ivors. Apparently U-Boot has done this only since 2009 (commit 26f4cdba6b51deab4ec99d60be381244068ef950), so it's not even something that an OS could depend on (and certainly Linux doesn't). So I don't see the point. Kumar, do you remember why you put this in? Was it only for prototyping purposes? I certainly wouldn't mind removing the whole thing altogether. Alex I feel like we did have some support for timer external interrupts in u-boot. Its been a while since I looked. This has nothing to do with U-Boot's own exception handlers -- this is what U-Boot is currently doing just prior to entering the OS. -Scott Oh, right. Did e6500 move to fixed IVORs? If not this can probably be removed as I doubt there will be a new core from FSL that would require this. It was meant as a transition for any OS that cared (if my memory serves me). - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7][v2] powerpc/mpc85xx: Move LAW_EN define outside of config
On Mar 6, 2014, at 6:12 AM, Prabhakar Kushwaha prabha...@freescale.com wrote: LAW_EN is only defined if CONFIG_SYS_CCSRBAR_DEFAULT is not equal to CONFIG_SYS_CCSRBAR_PHYS. in SPL framework CCSRBAR is not relocated hence both are same. This cause compilation error. So LAW_EN define outside of configs Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Changes for v2: Sending as it is arch/powerpc/cpu/mpc85xx/start.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) why aren’t these coming from asm/fsl_law.h? diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index dbbd8e5..67e071b 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -26,6 +26,8 @@ #undefMSR_KERNEL #define MSR_KERNEL ( MSR_ME ) /* Machine Check */ +#define LAW_EN 0x8000 + #if defined(CONFIG_NAND_SPL) || \ (defined(CONFIG_SPL_BUILD) defined(CONFIG_SPL_INIT_MINIMAL)) #define MINIMAL_SPL @@ -574,7 +576,6 @@ infinite_debug_loop: #ifdef CONFIG_FSL_CORENET #define CCSR_LAWBARH0 (CONFIG_SYS_CCSRBAR + 0x1000) -#define LAW_EN 0x8000 #define LAW_SIZE_4K 0xb #define CCSRBAR_LAWAR (LAW_EN | (0x1e 20) | LAW_SIZE_4K) #define CCSRAR_C 0x8000 /* Commit */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] PPC 85xx: Detect e500v2 / e500mc during runtime
On Jan 23, 2014, at 6:11 AM, Alexander Graf ag...@suse.de wrote: On 21.01.2014, at 03:25, Scott Wood scottw...@freescale.com wrote: On Sun, 2014-01-19 at 16:19 +0100, Alexander Graf wrote: With the qemu-ppce500 machine type we can run the same board with either an e500v2 or an e500mc core plugged in. This means that the IVOR setup can't be based on compile time decisions, so instead we have to do a runtime check which CPU generation we're running on. Is this really the only place where you ran into this? Yup. At least the only place where the difference actually matters for a VM. Also consider that you'll be adding extra size, and some of our 85xx targets are pretty close to the limit as is (though at least this code isn't used in SPLs). I guess nobody ever bothered to set IVORs for e6500-specific exceptions. For that matter, I don't see why we need this code at all. These aren't the addresses that U-Boot keeps its exception vectors at; it's setting them up for the OS, apparently trying to imitate some other type of book3e chip that has fixed ivors. Apparently U-Boot has done this only since 2009 (commit 26f4cdba6b51deab4ec99d60be381244068ef950), so it's not even something that an OS could depend on (and certainly Linux doesn't). So I don't see the point. Kumar, do you remember why you put this in? Was it only for prototyping purposes? I certainly wouldn't mind removing the whole thing altogether. Alex I feel like we did have some support for timer external interrupts in u-boot. Its been a while since I looked. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Add workaround for errata USB-14 (enable on P204x/P3041/P50x0)
On Mar 5, 2013, at 2:40 PM, Wolfgang Denk wrote:
Dear Xu Lei-B33228,
Please do not top post / full quote. Thanks.
In message
8cb6a38adf9e994697ff8a45e96e0853388...@039-sn1mpn1-004.039d.mgd.msft.net
you wrote:
Thank you and I agree with you. It is a little ugly but because these
registers info are not publicly, so I did not use C struct to describe them,
for this case is it ok, or other method such as define a struct but keep all
other registers and bits in this register reserved? Thank you.
I'm not throwing in a formal NAK here, but for reasons of consistency
(and because others are just too eager to quote such patches as
authoritative precedent) I'd prefer the use of a struct.
While I'd prefer a struct as well, unfortunately this isn't something FSL has
documented and we publish the erratum write ups with address like this. So
when a customer comes and looks for the code its more inline with the erratum
writeup.
I'm not sure what value a dummy struct would provide above the explicit
addressing utilized in the patch.
Again, I'm not happy about the situation, just not sure what additional value
doing something like:
struct dummy_usb_dscr {
u8 res[0x520];
u32 erratum_usb14_reg;
u8 res[4096-0x524];
};
Its going to be a bit more error prone than the method used when the struct
needs updating for a new register field and when someone screws up getting the
res[] sizes correct.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] fdt: cmd_fdt: Call fdt_chosen() from fdt boardsetup
On Sep 26, 2012, at 9:20 AM, Stefan Roese wrote: Hi Kumar, On 09/26/2012 03:36 PM, Kumar Gala wrote: By calling fdt_chosen(), the chosen node will be updated / created by the fdt boardsetup command. This is useful for setting of the kernel commandline via the bootargs env variable. With this change, the fdt boardsetup can be used to prepare the DT blob for SPL booting. The patched DT blob can be saved to flash and can be used by the SPL U-Boot version directly for Linux booting. Signed-off-by: Stefan Roese s...@denx.de --- common/cmd_fdt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) There are possibly some workflows this breaks. I can't remember if for AMP boot we need to do something between ft_board_setup() and fdt_chosen() Could you please elaborate what exactly you fear here? Is this a NACK for this patch? Possibly. I've got to find our docs on how we do 2-core AMP booting sequence w/regards to device tree. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] fdt: cmd_fdt: Call fdt_chosen() from fdt boardsetup
On Sep 26, 2012, at 4:11 AM, Stefan Roese wrote:
By calling fdt_chosen(), the chosen node will be updated /
created by the fdt boardsetup command. This is useful for
setting of the kernel commandline via the bootargs
env variable.
With this change, the fdt boardsetup can be used to prepare
the DT blob for SPL booting. The patched DT blob can be saved
to flash and can be used by the SPL U-Boot version directly
for Linux booting.
Signed-off-by: Stefan Roese s...@denx.de
---
common/cmd_fdt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
There are possibly some workflows this breaks. I can't remember if for AMP
boot we need to do something between ft_board_setup() and fdt_chosen()
- k
diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c
index e2225c4..d688334 100644
--- a/common/cmd_fdt.c
+++ b/common/cmd_fdt.c
@@ -425,8 +425,10 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc, char
* const argv[])
}
#ifdef CONFIG_OF_BOARD_SETUP
/* Call the board-specific fixup routine */
- else if (strncmp(argv[1], boa, 3) == 0)
+ else if (strncmp(argv[1], boa, 3) == 0) {
ft_board_setup(working_fdt, gd-bd);
+ fdt_chosen(working_fdt, 1);
+ }
#endif
/* Create a chosen node */
else if (argv[1][0] == 'c') {
--
1.7.12.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems with a P2020 board
On Sep 26, 2012, at 7:09 AM, Joakim Tjernlund wrote: Joakim Tjernlund/Transmode wrote on 2012/08/30 15:12:08: Hi. We have a new board which we are suing with U-boot. The CPU is a P2020. I am having a few minor problems, and I was hoping to get some help. - Boot Count. We are keen to use the boot counter feature, but I am struggling to find a suitable register in the P2020. The file arch/powerpc/lib/bootcount.c list a few locations that work with other PowerPC chips, but I can't find any of those registers in the P2020 documentation. Me too on finding such a register Did you find a register? What are the requirements of the bootcount register? If it needs to persist value across hard resets of the SoC than nothing exists. If you need a scratch register than you could possibly use one of the MPIC msg registers. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Problems with a P2020 board
On Aug 30, 2012, at 2:56 AM, Mark Marshall wrote: - Timer Interrupts seem to stop. Once U-boot has started the timer interrupts seem to stop. I have added a test command that prints out the timestamp variable (from arch/powerpc/lib/interrupts.c). I can see that when we enter the interactive loop this variable stops incrementing. I can add boot scripts that output this value, and it is incrementing until the console becomes interactive. Has anyone else seen a problem like this? Which kinda of timer interrupts - those generated by core decrementer or something via MPIC timer? can you see if MSR[EE] is still set? If core decrementer, also take a look at TSR TCR sprs. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pci: fix some warnings related to assumptions about
On Sep 21, 2012, at 5:34 PM, Anatolij Gustschin wrote:
Hi,
On Wed, 19 Sep 2012 09:47:36 -0500
Kumar Gala ga...@kernel.crashing.org wrote:
The following commit introduced some warnings associated with using
pci_addr_t instead of a proper 32-bit data type.
commit af778c6d9e2b945ee03cbc53bb976238a3374f33
Author: Andrew Sharp andywy...@gmail.com
Date: Wed Aug 1 12:27:16 2012 +
pci: fix errant data types and corresponding access functions
On some platforms pci_addr_t is defined as a 64-bit data type so its not
proper to use with pci_{read,write}_config_dword.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/pci/pci.c |6 +++---
drivers/pci/pci_auto.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
Applied to staging/ag...@denx.de.
Thanks,
Anatolij
Thanks,
This should get in before v2012.10 is released
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-mpc85xx (for v2012.10)
Tom, Sorry for both sending this and the late request. I think Andy's been swamped with some chip bringup and lost notice of window (thus my sending this request). Would be good to get this stuff (and some fixes, etc) into v2012.10. Thanks - k The following changes since commit ee1f4caaa2a3f79d692155eec8a4c7289d60e106: Tom Rini (1): Prepare v2012.10-rc1 are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Andy Fleming (1): Revert powerpc: Fix declaration type for I/O functions Joakim Tjernlund (2): mpc85xx: Initial SP alignment is wrong. powerpc: Stack Pointer not properly aligned Kumar Gala (3): Add e6500 processor detection Add IFC offset for DPAA/Corenet platforms Added new ext fields to IFC Liu Gang (6): powerpc/corenet_ds: Update README.srio-boot-corenet powerpc/corenet_ds: Get rid of the SRIOBOOT_MASTER build target powerpc/corenet_ds: Get rid of the CONFIG_SRIOBOOT_SLAVE_PORTx macro powerpc/corenet_ds: Update README and README.srio-pcie-boot-corenet powerpc/corenet_ds: Master module for boot from PCIE powerpc/corenet_ds: Slave module for boot from PCIE Matthew McClintock (6): p1014rdb: set ddr bus width properly depending on SVR p1010rdb: fix ddr values for p1014rdb (setting bus width to 16bit) powerpc/p1010rdb: nandboot: compare SVR properly nand_spl: update udelay for Freescale boards nand_spl: p1023rds: wait before enabling DDR controller nand_spl: change out_be32 to raw_writel and depend on subsequent sync Paul Gortmaker (1): mpc85xx: use LCRR_DBYP define instead of raw constant Prabhakar Kushwaha (2): powerpc/mpc85xx:Enable debugger support to missed e500v2 SoC powerpc/mpc85xx: Add IFC LAW target ID for FSL High-End SoC Scott Wood (6): nand/fsl_elbc: shrink SPL a bit by converting out_be32() to __raw_writel() powerpc/fsl-corenet: remove dead variant symbols powerpc/fsl-corenet: work around erratum A004510 powerpc/85xx: clear out TLB on boot powerpc/p1_p2_rdb_pc: print -PC suffix in board name powerpc/mpc85xx/p1_p2_rdb: add all LAWs during SPL Shaohui Xie (1): powerpc/CoreNet: add tool to support pbl image build. Timur Tabi (6): powerpc/85xx: add support for FM2 DTSEC5 fm-eth: add function fm_info_get_phy_address() powerpc/85xx: introduce function serdes_device_from_fm_port() fm-eth: use fdt_status_disabled() function in ft_fixup_port() powerpc/85xx: get rid of enum board_slots in P4080 MDIO driver powerpc/85xx: remove support for the Freescale P3060 York Sun (14): powerpc/mpc85xx: Make NMG_CPU_A011 workaround conditional powerpc/mpc8xxx: Remove P1015 and P1016 from CPU list powerpc/mpc8xxx: Add immap for topology and rcpm registers powerpc/mpc8xxx: use topology registers to calculate number of cores powerpc/mpc8xxx: fix core id for multicore booting powerpc/mpc85xx: Skip zero values for DDR debug registers powerpc/mpc8xxx: Add fine timing support for DDR3 powerpc/mpc8xxx: Add support for cas latency 12 and above powerpc/mpc8xxx: Enable 3-way and 4-way DDR interleaving powerpc/mpc8xxx: Fix bug for extended DDR timing powerpc/mpc8xxx DDR: Fix CAS latency calculation powerpc/mpc8xxx DDR: Fall back to raw timing for first controller only powerpc/mpc8xxx DDR: Fix interactive DDR debugging powerpc/mpc8xxx: Move HWCONFIG_BUFFER_SIZE into config.h Makefile |6 + README | 37 +- arch/powerpc/cpu/mpc85xx/Makefile | 10 - arch/powerpc/cpu/mpc85xx/cmd_errata.c |9 +- arch/powerpc/cpu/mpc85xx/cpu.c | 15 +- arch/powerpc/cpu/mpc85xx/cpu_init.c| 52 ++- arch/powerpc/cpu/mpc85xx/ddr-gen3.c| 26 +- arch/powerpc/cpu/mpc85xx/fdt.c |7 +- arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |8 +- arch/powerpc/cpu/mpc85xx/p3060_ids.c | 117 - arch/powerpc/cpu/mpc85xx/p3060_serdes.c| 118 - arch/powerpc/cpu/mpc85xx/release.S | 87 +++- arch/powerpc/cpu/mpc85xx/speed.c |3 +- arch/powerpc/cpu/mpc85xx/start.S | 376 +-- arch/powerpc/cpu/mpc8xxx/cpu.c | 68 ++- arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 223 - arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c| 25 +- arch/powerpc/cpu/mpc8xxx/ddr/interactive.c | 26 +- .../cpu/mpc8xxx/ddr/lc_common_dimm_params.c| 18 +- arch/powerpc/cpu/mpc8xxx/ddr/main.c| 307 +++-- arch/powerpc/cpu/mpc8xxx/ddr/options.c | 212 ++--- arch/powerpc/cpu/mpc8xxx/ddr/util.c| 67 ++- arch/powerpc/cpu
Re: [U-Boot] arch/powerpc/lib/board.c:get_effective_memsize() for 4GB+ systems
On Sep 21, 2012, at 6:54 AM, Robert Thorhuus wrote: -Original Message- From: Tabi Timur-B04825 [mailto:b04...@freescale.com] Sent: den 21 september 2012 13:37 To: Robert Thorhuus Cc: Kumar Gala; u-boot@lists.denx.de Subject: Re: [U-Boot] arch/powerpc/lib/board.c:get_effective_memsize() for 4GB+ systems Robert Thorhuus wrote: I really see the advantage of keeping this map you have. It is of course more compatible with different OSEs and you do not need to do anything special with 32/64 bit cores. But at the same time you never take advantage of a 64 bit core with this approach. U-Boot is a boot loader, not an operating system. What is U-Boot supposed to do with more than 2GB of RAM? How should I access my 24GB in U-Boot? You should not! So really you are saying that I should have a 2GB map window in my 32-bit address space and then move this window depending on what memory I want to access? A bit cumbersome I must say. But ok. Again, you're doing the wrong thing with U-Boot. It's a boot loader. It's supposed to find your OS, load it into memory, and then boot it. How about the U-Boot relocation? As I see the code, it is not easy to decide where it should relocate. It will be either relocated to end of RAM or if we have more than 4G it will be at 4GB end. It relocates to the end of RAM or the end of 2GB, whichever is lower. It ignores all memory above 2GB. What if you want to place U-Boot at 16MB for instance? Or if you do not want a memory map hole at 4GB just because U-Boot doesn't handle more than that? Again, you're missing the point about U-boot. Last AND least I just want to say I'm used to creating memory maps in bootloader which holds for the OS. It seems the time has come to annihilate my illusion... Yes, please kill it with fire! -- Timur Tabi Linux kernel developer at Freescale Hello Timur! You really used the machine gun there ;) Ok. I'll just answer your 2GB+ usage question: Testing! No I will not be using much memory at all for functionality. But the memory needs to be tested. What is your proposal for that then? And I see U-Boot as the first software place for test and debug. Maybe I want to read out RAM contents? Robert, We have seen some cases for u-boot to access 4G of memory directly. However, the effort to get u-boot to be a 64-bit clean just has never warranted the investment for the few minor cases people have raised for wanting to address 4G directly. The one case I usually hear about is DDR test. We suggest its easier to try and getting DDR testing to utilize a window scheme into memory than it is for one to go make u-boot 64-bit. :) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] pci: fix errant data types and corresponding access functions
On Aug 29, 2012, at 7:16 PM, Andrew Sharp wrote:
In a couple of places, unsigned int and pci_config_*_dword were being
used when u16 and _word should be used. Unsigned int was also being
used in a couple of places that should be pci_addr_t.
Signed-off-by: Andrew Sharp andywy...@gmail.com
---
drivers/pci/pci.c |7 ---
drivers/pci/pci_auto.c | 15 ---
2 files changed, 12 insertions(+), 10 deletions(-)
some of these changes cause warnings now:
pci.c: In function 'pci_map_bar':
pci.c:124:2: warning: passing argument 3 of 'pci_read_config_dword' from
incompatible pointer type
pci.c:69:1: note: expected 'u32 *' but argument is of type 'pci_addr_t *'
pci.c: In function 'pci_hose_config_device':
pci.c:406:3: warning: passing argument 4 of 'pci_hose_read_config_dword' from
incompatible pointer type
pci.c:48:1: note: expected 'u32 *' but argument is of type 'pci_addr_t *'
pci_auto.c: In function 'pciauto_setup_device':
pci_auto.c:111:3: warning: passing argument 4 of 'pci_hose_read_config_dword'
from incompatible pointer type
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 398542b..cd78312 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -118,11 +118,11 @@ PCI_WRITE_VIA_DWORD_OP(word, u16, 0x02, 0x)
void *pci_map_bar(pci_dev_t pdev, int bar, int flags)
{
pci_addr_t pci_bus_addr;
- u32 bar_response;
+ pci_addr_t bar_response;
this should really be a u32 not pci_addr_t.
/* read BAR address */
pci_read_config_dword(pdev, bar, bar_response);
- pci_bus_addr = (pci_addr_t)(bar_response ~0xf);
+ pci_bus_addr = bar_response ~0xf;
/*
* Pass 0 as the length argument to pci_bus_to_virt. The arg
@@ -385,7 +385,8 @@ int pci_hose_config_device(struct pci_controller *hose,
pci_addr_t mem,
unsigned long command)
{
- unsigned int bar_response, old_command;
+ pci_addr_t bar_response;
+ unsigned int old_command;
Same comment here.
pci_addr_t bar_value;
pci_size_t bar_size;
unsigned char pin;
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 87ee2c2..2338706 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -88,15 +88,15 @@ void pciauto_setup_device(struct pci_controller *hose,
struct pci_region *prefetch,
struct pci_region *io)
{
- unsigned int bar_response;
+ pci_addr_t bar_response;
again, this should not be pci_addr_t
pci_addr_t bar_value;
pci_size_t bar_size;
- unsigned int cmdstat = 0;
+ u16 cmdstat = 0;
struct pci_region *bar_res;
int bar, bar_nr = 0;
int found_mem64 = 0;
- pci_hose_read_config_dword(hose, dev, PCI_COMMAND, cmdstat);
+ pci_hose_read_config_word(hose, dev, PCI_COMMAND, cmdstat);
cmdstat = (cmdstat ~(PCI_COMMAND_IO | PCI_COMMAND_MEMORY)) |
PCI_COMMAND_MASTER;
for (bar = PCI_BASE_ADDRESS_0; bar PCI_BASE_ADDRESS_0 + (bars_num*4);
bar += 4) {
@@ -167,7 +167,7 @@ void pciauto_setup_device(struct pci_controller *hose,
bar_nr++;
}
- pci_hose_write_config_dword(hose, dev, PCI_COMMAND, cmdstat);
+ pci_hose_write_config_word(hose, dev, PCI_COMMAND, cmdstat);
pci_hose_write_config_byte(hose, dev, PCI_CACHE_LINE_SIZE,
CONFIG_SYS_PCI_CACHE_LINE_SIZE);
pci_hose_write_config_byte(hose, dev, PCI_LATENCY_TIMER, 0x80);
@@ -179,9 +179,9 @@ void pciauto_prescan_setup_bridge(struct pci_controller
*hose,
struct pci_region *pci_mem = hose-pci_mem;
struct pci_region *pci_prefetch = hose-pci_prefetch;
struct pci_region *pci_io = hose-pci_io;
- unsigned int cmdstat;
+ u16 cmdstat;
- pci_hose_read_config_dword(hose, dev, PCI_COMMAND, cmdstat);
+ pci_hose_read_config_word(hose, dev, PCI_COMMAND, cmdstat);
/* Configure bus number registers */
pci_hose_write_config_byte(hose, dev, PCI_PRIMARY_BUS,
@@ -229,7 +229,8 @@ void pciauto_prescan_setup_bridge(struct pci_controller
*hose,
}
/* Enable memory and I/O accesses, enable bus master */
- pci_hose_write_config_dword(hose, dev, PCI_COMMAND, cmdstat |
PCI_COMMAND_MASTER);
+ pci_hose_write_config_word(hose, dev, PCI_COMMAND,
+ cmdstat | PCI_COMMAND_MASTER);
}
void pciauto_postscan_setup_bridge(struct pci_controller *hose,
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pci: fix some warnings related to assumptions about
The following commit introduced some warnings associated with using
pci_addr_t instead of a proper 32-bit data type.
commit af778c6d9e2b945ee03cbc53bb976238a3374f33
Author: Andrew Sharp andywy...@gmail.com
Date: Wed Aug 1 12:27:16 2012 +
pci: fix errant data types and corresponding access functions
On some platforms pci_addr_t is defined as a 64-bit data type so its not
proper to use with pci_{read,write}_config_dword.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/pci/pci.c |6 +++---
drivers/pci/pci_auto.c |2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 2a6d0a7..d864f13 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -118,11 +118,11 @@ PCI_WRITE_VIA_DWORD_OP(word, u16, 0x02, 0x)
void *pci_map_bar(pci_dev_t pdev, int bar, int flags)
{
pci_addr_t pci_bus_addr;
- pci_addr_t bar_response;
+ u32 bar_response;
/* read BAR address */
pci_read_config_dword(pdev, bar, bar_response);
- pci_bus_addr = bar_response ~0xf;
+ pci_bus_addr = (pci_addr_t)(bar_response ~0xf);
/*
* Pass 0 as the length argument to pci_bus_to_virt. The arg
@@ -389,7 +389,7 @@ int pci_hose_config_device(struct pci_controller *hose,
pci_addr_t mem,
unsigned long command)
{
- pci_addr_t bar_response;
+ u32 bar_response;
unsigned int old_command;
pci_addr_t bar_value;
pci_size_t bar_size;
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index ae61e24..cd78030 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -89,7 +89,7 @@ void pciauto_setup_device(struct pci_controller *hose,
struct pci_region *prefetch,
struct pci_region *io)
{
- pci_addr_t bar_response;
+ u32 bar_response;
pci_size_t bar_size;
u16 cmdstat = 0;
int bar, bar_nr = 0;
--
1.7.9.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/fsl-corenet: remove dead variant symbols
On Aug 15, 2012, at 12:19 PM, Scott Wood wrote: On 08/15/2012 09:21 AM, Kumar Gala wrote: On Aug 14, 2012, at 4:45 PM, Scott Wood wrote: On 08/14/2012 04:31 PM, Kumar Gala wrote: On Aug 14, 2012, at 3:14 PM, Scott Wood wrote: These are not supported as individual build targets, but instead are supported by another target. The dead p4040 defines in particular had bitrotted significantly. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/cpu/mpc85xx/Makefile |3 -- arch/powerpc/include/asm/config_mpc85xx.h | 68 ++--- arch/powerpc/include/asm/immap_85xx.h |2 +- drivers/net/fm/Makefile |1 - include/configs/P2041RDB.h|2 +- include/configs/P4080DS.h |1 + include/configs/P5020DS.h |2 +- 7 files changed, 7 insertions(+), 72 deletions(-) I had put these in for customer specific boards... Why wouldn't they use the p2041/p4080/p5020 symbol? The point is we support both at runtime. I understand we might have bit rot, but I guess I'd rather we added: P2040RDB, P4040DS, and P5010DS to boards.cfg to test these SoC builds than remove the code. I disagree. That adds extra builds to test and maintain for no real gain. It was an attempt to try and reduce some confusion for customers if they happen to utilize a P4040/P2040/P5010. Well, I did add comments saying this also supports foo. I think documentation is the way to deal with this, or maybe a target name alias mechanism if we're really having problems with customers unable to figure this out. If we do add separate builds I predict they will receive approximately zero test coverage beyond the occasional (now slightly slower) MAKEALL. We have the same issue with P1/P2 SoCs and single core vs dual core devices. I'd be happy to see those extra builds go away too. -Scott Ok, I'll bite. Acked-by: Kumar Gala ga...@kernel.crashing.org - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] hwconfig: Move HWCONFIG_BUFFER_SIZE into hwconfig.h
On Aug 15, 2012, at 7:53 PM, York Sun wrote:
Before proper environment is setup, we extract hwconfig and put it into a
buffer with size HWCONFIG_BUFFER_SIZE. We need to enlarge the buffer to
accommodate longer string. Since this macro is used in multiple files, we
move it into hwconfig.h.
Signed-off-by: York Sun york...@freescale.com
---
arch/powerpc/cpu/mpc85xx/cpu_init.c |2 --
arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |2 --
arch/powerpc/cpu/mpc8xxx/ddr/options.c|1 -
include/hwconfig.h|2 ++
4 files changed, 2 insertions(+), 5 deletions(-)
1. I don't think HWCONFIG_BUFFER_SIZE should be getting set in
include/hwconfig.h, this is unique to FSL 8xxx usage not to hwconfig
2. if you are doing to something like this it should be:
#ifndef CONFIG_HWCONFIG_BUFFER_SIZE
#define CONFIG_HWCONFIG_BUFFER_SIZE 128
#endif
This allowing a board port to set it as needed.
- k
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index c13c45f..2397547 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -56,8 +56,6 @@
#include ../../../../drivers/block/fsl_sata.h
-#define HWCONFIG_BUFFER_SIZE 128
-
DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_SECURE_BOOT
diff --git a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
index 9300e7f..69399aa 100644
--- a/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
+++ b/arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c
@@ -46,8 +46,6 @@
static u32 serdes_prtcl_map;
-#define HWCONFIG_BUFFER_SIZE 128
-
#ifdef DEBUG
static const char *serdes_prtcl_str[] = {
[NONE] = NA,
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
index 00ec57b..24c8a51 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/options.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/options.c
@@ -19,7 +19,6 @@
* This is pretty fragile on both the use of stack and if the buffer is big
* enough. However we will get a warning from getenv_f for the later.
*/
-#define HWCONFIG_BUFFER_SIZE 128
/* Board-specific functions defined in each board's ddr.c */
extern void fsl_ddr_board_options(memctl_options_t *popts,
diff --git a/include/hwconfig.h b/include/hwconfig.h
index a037ed8..64861c4 100644
--- a/include/hwconfig.h
+++ b/include/hwconfig.h
@@ -18,6 +18,8 @@
#include linux/types.h
#include asm/errno.h
+#define HWCONFIG_BUFFER_SIZE 256
+
#ifdef CONFIG_HWCONFIG
extern int hwconfig_f(const char *opt, char *buf);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] powerpc/85xx: update P4080DS MDIO bus multiplexer support
On Aug 14, 2012, at 11:47 AM, Timur Tabi wrote: The Freescale P4080DS has a complex multiplexed MDIO bus, where the muxing varies per SerDes protocol. This is because the protocol determines in which PCI slot the various SGMII and XGMII interface cards belong, as well as whether the RGMII ports are enabled. The Freescale SDK includes support for MDIO bus multiplexing, but the upstream Linux kernel uses David Daney's (Cavium) method instead. Therefore, the P4080 code needs to be migrated to the new method. The device tree contains two top-level mdio-mux nodes, one for EMI1 (RGMII and SGMII) and the other for EMI2 (XGMII). The U-boot code depends on several device tree aliases to help it find the nodes that need to be updated. Signed-off-by: Timur Tabi ti...@freescale.com --- board/freescale/corenet_ds/eth_p4080.c | 172 1 files changed, 129 insertions(+), 43 deletions(-) I think we need to hold on this patch until we have a kernel somewhere that can actually utilize it. I'm guessing this would break the SDK mux support for p4080ds? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] powerpc/85xx: update P4080DS MDIO bus multiplexer support
On Aug 14, 2012, at 11:47 AM, Timur Tabi wrote: The Freescale P4080DS has a complex multiplexed MDIO bus, where the muxing varies per SerDes protocol. This is because the protocol determines in which PCI slot the various SGMII and XGMII interface cards belong, as well as whether the RGMII ports are enabled. The Freescale SDK includes support for MDIO bus multiplexing, but the upstream Linux kernel uses David Daney's (Cavium) method instead. Therefore, the P4080 code needs to be migrated to the new method. The device tree contains two top-level mdio-mux nodes, one for EMI1 (RGMII and SGMII) and the other for EMI2 (XGMII). The U-boot code depends on several device tree aliases to help it find the nodes that need to be updated. Signed-off-by: Timur Tabi ti...@freescale.com --- board/freescale/corenet_ds/eth_p4080.c | 172 1 files changed, 129 insertions(+), 43 deletions(-) I think we need to hold on this patch until we have a kernel somewhere that can actually utilize it. I'm guessing this would break the SDK mux support for p4080ds? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/fsl-corenet: remove dead variant symbols
On Aug 14, 2012, at 4:45 PM, Scott Wood wrote: On 08/14/2012 04:31 PM, Kumar Gala wrote: On Aug 14, 2012, at 3:14 PM, Scott Wood wrote: These are not supported as individual build targets, but instead are supported by another target. The dead p4040 defines in particular had bitrotted significantly. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/cpu/mpc85xx/Makefile |3 -- arch/powerpc/include/asm/config_mpc85xx.h | 68 ++--- arch/powerpc/include/asm/immap_85xx.h |2 +- drivers/net/fm/Makefile |1 - include/configs/P2041RDB.h|2 +- include/configs/P4080DS.h |1 + include/configs/P5020DS.h |2 +- 7 files changed, 7 insertions(+), 72 deletions(-) I had put these in for customer specific boards... Why wouldn't they use the p2041/p4080/p5020 symbol? The point is we support both at runtime. I understand we might have bit rot, but I guess I'd rather we added: P2040RDB, P4040DS, and P5010DS to boards.cfg to test these SoC builds than remove the code. I disagree. That adds extra builds to test and maintain for no real gain. It was an attempt to try and reduce some confusion for customers if they happen to utilize a P4040/P2040/P5010. We have the same issue with P1/P2 SoCs and single core vs dual core devices. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] Makefile: cosmetic: optimize usage of LIBS-y
On Aug 10, 2012, at 4:17 PM, Wolfgang Denk wrote: Dear daniel.schwierz...@gmail.com, In message 1342741198-9105-1-git-send-email-daniel.schwierz...@gmail.com you wrote: From: Daniel Schwierzeck daniel.schwierz...@gmail.com Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- Changes for v2: - optimized HAVE_VENDOR_COMMON_LIB macro as suggested by Mike - optimized HAVE_VENDOR_COMMON_LIB macro also in spl/Makefile --- Makefile | 17 ++--- spl/Makefile | 3 +-- 2 files changed, 7 insertions(+), 13 deletions(-) Applied, thanks. Best regards, Wolfgang Denk I spoke too soon, this patch is causing build issues on P4080DS_config: [galak@right u-boot]$ make -j40 -s arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `ft_cpu_setup': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/fdt.c:614: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `get_sys_info': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/speed.c:77: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x344): undefined reference to `tlb_table' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x348): undefined reference to `num_tlb_entries' arch/powerpc/lib/libpowerpc.o: In function `board_init_r': /local/home/galak/git/u-boot/arch/powerpc/lib/board.c:850: undefined reference to `mac_read_from_eeprom' common/libcommon.o:(.u_boot_cmd+0x370): undefined reference to `do_mac' drivers/misc/libmisc.o:(.got2+0x14): undefined reference to `law_table' drivers/misc/libmisc.o:(.got2+0x18): undefined reference to `num_law_entries' drivers/pci/libpci.o: In function `pci_init': /local/home/galak/git/u-boot/drivers/pci/pci.c:731: undefined reference to `pci_init_board' board/freescale/corenet_ds/libcorenet_ds.o: In function `ft_board_setup': /local/home/galak/git/u-boot/board/freescale/corenet_ds/corenet_ds.c:231: undefined reference to `pci_of_setup' board/freescale/corenet_ds/libcorenet_ds.o: In function `board_ft_fman_fixup_port': /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:230: undefined reference to `fdt_set_phy_handle' /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:238: undefined reference to `fdt_set_phy_handle' make: *** [u-boot] Error 1 [galak@right u-boot]$ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dts/Makefile: Check for empty $(LDSCRIPT)
On Aug 10, 2012, at 4:46 PM, Wolfgang Denk wrote: Dear Horst Kronstorfer, In message 1342097912-8652-1-git-send-email-hkron...@frequentis.com you wrote: Make sure that $(LDSCRIPT) is not empty before calling process_lds with 'cat $(LDSCRIPT)' else cat will block waiting for input from stdin. Signed-off-by: Horst Kronstorfer hkron...@frequentis.com --- dts/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk This patch is breaking builds on (P4080DS_config) on ppc: arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `ft_cpu_setup': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/fdt.c:614: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `get_sys_info': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/speed.c:77: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x344): undefined reference to `tlb_table' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x348): undefined reference to `num_tlb_entries' arch/powerpc/lib/libpowerpc.o: In function `board_init_r': /local/home/galak/git/u-boot/arch/powerpc/lib/board.c:850: undefined reference to `mac_read_from_eeprom' common/libcommon.o:(.u_boot_cmd+0x370): undefined reference to `do_mac' drivers/misc/libmisc.o:(.got2+0x14): undefined reference to `law_table' drivers/misc/libmisc.o:(.got2+0x18): undefined reference to `num_law_entries' drivers/pci/libpci.o: In function `pci_init': /local/home/galak/git/u-boot/drivers/pci/pci.c:731: undefined reference to `pci_init_board' board/freescale/corenet_ds/libcorenet_ds.o: In function `ft_board_setup': /local/home/galak/git/u-boot/board/freescale/corenet_ds/corenet_ds.c:231: undefined reference to `pci_of_setup' board/freescale/corenet_ds/libcorenet_ds.o: In function `board_ft_fman_fixup_port': /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:230: undefined reference to `fdt_set_phy_handle' /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:238: undefined reference to `fdt_set_phy_handle' make: *** [u-boot] Error 1 [ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 1/2] mpc85xx: Initial SP alignment is wrong.
On Jul 23, 2012, at 3:58 PM, Joakim Tjernlund wrote: PowerPC mandates SP to be 16 bytes aligned. Furthermore, a stack frame is added, pointing to the reset vector which may in the way when gdb is walking the stack because the reset vector may not accessible depending on emulator settings. Also use a temp register so gdb doesn't pick up intermediate values. Signed-off-by: Joakim Tjernlund joakim.tjernl...@transmode.se --- v2 - Address Scott Wood's comments arch/powerpc/cpu/mpc85xx/start.S | 16 +--- 1 files changed, 5 insertions(+), 11 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/fsl-corenet: remove dead variant symbols
On Aug 14, 2012, at 3:14 PM, Scott Wood wrote: These are not supported as individual build targets, but instead are supported by another target. The dead p4040 defines in particular had bitrotted significantly. Signed-off-by: Scott Wood scottw...@freescale.com --- arch/powerpc/cpu/mpc85xx/Makefile |3 -- arch/powerpc/include/asm/config_mpc85xx.h | 68 ++--- arch/powerpc/include/asm/immap_85xx.h |2 +- drivers/net/fm/Makefile |1 - include/configs/P2041RDB.h|2 +- include/configs/P4080DS.h |1 + include/configs/P5020DS.h |2 +- 7 files changed, 7 insertions(+), 72 deletions(-) I had put these in for customer specific boards... I understand we might have bit rot, but I guess I'd rather we added: P2040RDB, P4040DS, and P5010DS to boards.cfg to test these SoC builds than remove the code. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] Makefile: cosmetic: optimize usage of LIBS-y
On Aug 14, 2012, at 8:52 AM, Kumar Gala wrote: On Aug 10, 2012, at 4:17 PM, Wolfgang Denk wrote: Dear daniel.schwierz...@gmail.com, In message 1342741198-9105-1-git-send-email-daniel.schwierz...@gmail.com you wrote: From: Daniel Schwierzeck daniel.schwierz...@gmail.com Signed-off-by: Daniel Schwierzeck daniel.schwierz...@gmail.com --- Changes for v2: - optimized HAVE_VENDOR_COMMON_LIB macro as suggested by Mike - optimized HAVE_VENDOR_COMMON_LIB macro also in spl/Makefile --- Makefile | 17 ++--- spl/Makefile | 3 +-- 2 files changed, 7 insertions(+), 13 deletions(-) Applied, thanks. Best regards, Wolfgang Denk I spoke too soon, this patch is causing build issues on P4080DS_config: [galak@right u-boot]$ make -j40 -s arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `ft_cpu_setup': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/fdt.c:614: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `get_sys_info': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/speed.c:77: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x344): undefined reference to `tlb_table' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x348): undefined reference to `num_tlb_entries' arch/powerpc/lib/libpowerpc.o: In function `board_init_r': /local/home/galak/git/u-boot/arch/powerpc/lib/board.c:850: undefined reference to `mac_read_from_eeprom' common/libcommon.o:(.u_boot_cmd+0x370): undefined reference to `do_mac' drivers/misc/libmisc.o:(.got2+0x14): undefined reference to `law_table' drivers/misc/libmisc.o:(.got2+0x18): undefined reference to `num_law_entries' drivers/pci/libpci.o: In function `pci_init': /local/home/galak/git/u-boot/drivers/pci/pci.c:731: undefined reference to `pci_init_board' board/freescale/corenet_ds/libcorenet_ds.o: In function `ft_board_setup': /local/home/galak/git/u-boot/board/freescale/corenet_ds/corenet_ds.c:231: undefined reference to `pci_of_setup' board/freescale/corenet_ds/libcorenet_ds.o: In function `board_ft_fman_fixup_port': /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:230: undefined reference to `fdt_set_phy_handle' /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:238: undefined reference to `fdt_set_phy_handle' make: *** [u-boot] Error 1 [galak@right u-boot]$ - k This is fixed by: http://patchwork.ozlabs.org/patch/177235/ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dts/Makefile: Check for empty $(LDSCRIPT)
On Aug 14, 2012, at 8:42 AM, Kumar Gala wrote: On Aug 10, 2012, at 4:46 PM, Wolfgang Denk wrote: Dear Horst Kronstorfer, In message 1342097912-8652-1-git-send-email-hkron...@frequentis.com you wrote: Make sure that $(LDSCRIPT) is not empty before calling process_lds with 'cat $(LDSCRIPT)' else cat will block waiting for input from stdin. Signed-off-by: Horst Kronstorfer hkron...@frequentis.com --- dts/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk This patch is breaking builds on (P4080DS_config) on ppc: arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `ft_cpu_setup': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/fdt.c:614: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o: In function `get_sys_info': /local/home/galak/git/u-boot/arch/powerpc/cpu/mpc85xx/speed.c:77: undefined reference to `get_board_sys_clk' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x344): undefined reference to `tlb_table' arch/powerpc/cpu/mpc85xx/libmpc85xx.o:(.got2+0x348): undefined reference to `num_tlb_entries' arch/powerpc/lib/libpowerpc.o: In function `board_init_r': /local/home/galak/git/u-boot/arch/powerpc/lib/board.c:850: undefined reference to `mac_read_from_eeprom' common/libcommon.o:(.u_boot_cmd+0x370): undefined reference to `do_mac' drivers/misc/libmisc.o:(.got2+0x14): undefined reference to `law_table' drivers/misc/libmisc.o:(.got2+0x18): undefined reference to `num_law_entries' drivers/pci/libpci.o: In function `pci_init': /local/home/galak/git/u-boot/drivers/pci/pci.c:731: undefined reference to `pci_init_board' board/freescale/corenet_ds/libcorenet_ds.o: In function `ft_board_setup': /local/home/galak/git/u-boot/board/freescale/corenet_ds/corenet_ds.c:231: undefined reference to `pci_of_setup' board/freescale/corenet_ds/libcorenet_ds.o: In function `board_ft_fman_fixup_port': /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:230: undefined reference to `fdt_set_phy_handle' /local/home/galak/git/u-boot/board/freescale/corenet_ds/eth_p4080.c:238: undefined reference to `fdt_set_phy_handle' make: *** [u-boot] Error 1 [ - k This is fixed by: http://patchwork.ozlabs.org/patch/177235/ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] usb ethernet working on panda?
On Feb 29, 2012, at 12:17 AM, Govindraj wrote: On Wed, Feb 29, 2012 at 4:47 AM, Kumar Gala ga...@kernel.crashing.org wrote: Does anyone have usb ethernet working on top of git tree on a panda board? yes. If so any gotcha's or details on how you have it working. I use following commands: setenv usbethaddr 0:0:1:2:3:4;usb start; After Ethernet enumerates, from u-boot I use following bootargs setenv ipaddr xxx.xxx.xxx.xxx;setenv serverip xxx.xxx.xxx.xxx;setenv gatewayip xxx.xxx.xxx.xxx;setenv netmask xxx.xxx.xxx.xx; setenv bootfile xx;setenv bootcmd 'tftp 8030;bootm 8030'; setenv bootargs console=ttyO2,115200n8 noinitrd root=/dev/nfs rw nfsroot=path_to_fs,nolock,tcp, wsize=1024,rsize=1024 ip=dhcp devfs=mount; boot; I try and get: Panda # setenv usbethaddr 0:0:1:2:3:4;usb start; (Re)start USB... USB: Register 1313 NbrPorts 3 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found Panda # setenv ipaddr 192.168.1.100; setenv serverip 192.168.1.1 Panda # setenv gatewayip 192.168.1.1 Panda # setenv netmask 255.255.255.0 Panda # ping 192.168.1.1 Waiting for Ethernet connection... done. Using sms0 device EHCI timed out on TD - token=0x8008d80 ping failed; host 192.168.1.1 is not alive Panda # Not sure if the 'EHCI timed out...' message is normal or expected. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] usb ethernet working on panda?
Does anyone have usb ethernet working on top of git tree on a panda board? If so any gotcha's or details on how you have it working. thanks - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] please pull u-boot-mpc85xx
On Jan 13, 2012, at 10:24 AM, Paul Gortmaker wrote: Hi Kumar, Was there a problem with my add printout of LCRR patch: http://patchwork.ozlabs.org/patch/131707/ or did it just get lost over the usual holiday period chaos? Thanks for merging the others, as they were the more important ones anyway. Paul. was just over looked, will take a look at it now. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] eXMeritus HWW-1U-1A: Add support for the AT24C128N I2C EEPROM
On Dec 15, 2011, at 9:26 PM, Kyle Moffett wrote: This EEPROM is hardware-write-protected and used to persist key information such as the serial number and MAC addresses even if the primary environment sector in NOR FLASH is overwritten. During manufacturing, the environment is initialized from Linux and then the key parameters copied to the EEPROM via U-Boot: env export -c -s 0x2000 $loadaddr serial# macaddr mac1addr mac2addr eeprom write $loadaddr 0x 0x2000 The chip is then locked via hardware for delivery. When doing a field U-Boot upgrade, the environment is erased and reset to the defaults to avoid problems with hwconfig changes, etc. After loading the new U-Boot image, the hardware data is reloaded: i2c dev 0 eeprom read $loadaddr 0x 0x2000 env import -c $loadaddr 0x2000 saveenv The first three commands are saved in the restore_eeprom variable for user convenience. (EG: run restore_eeprom saveenv) Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com Cc: Andy Fleming aflem...@gmail.com Cc: Kumar Gala kumar.g...@freescale.com --- include/configs/HWW1U1A.h | 29 +++-- 1 files changed, 27 insertions(+), 2 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] eXMeritus HWW-1U-1A: Minor environment variable tweaks
On Dec 15, 2011, at 9:26 PM, Kyle Moffett wrote: Most of the ethernet connections are internal links with specialized hardware and are not useful for dhcp or general-purpose networking; U-Boot should not be cycling through them. Force the primary external network interface in ethprime and disable the interface cycling with ethrotate=no. Additionally, the environment variable preboot has its own config option and means something entirely different from what the HWW-1U-1A variable was intended for. Rename the board variable to setbootargs to avoid potential confusion. Finally, fix an incorrect address for the kernel in FLASH memory. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com Cc: Andy Fleming aflem...@gmail.com Cc: Kumar Gala kumar.g...@freescale.com --- include/configs/HWW1U1A.h |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 85xx-next 0/8] Updates for Wind River sbc8548 board
On Dec 30, 2011, at 10:53 PM, Paul Gortmaker wrote: This updates the sbc8548 board support with several improvements for the end users. -ability to use SPD DDR config for easy RAM upgrades -ability to use alternate SODIMM flash for backup u-boot image -localbus config settings fixed so 128MB LBC SDRAM works reliably The discovery of a hardware errata (overlapping I2C SPD addresses) is at the core of what now allows the use of SPD configuration. The relocation of the 64MB user flash is to align it on a 64MB boundary, which simplifies a whole lot of things, both in the code and for the end user. (The previous mapping meant the last sector on the chip wasn't consistently the last sector in the address space assigned to the chip for all jumper configurations.) Reverting a bogus commit from the past that incorrectly set the windows for the 64MB flash to 128MB was the starting point for getting this all working. Paul. --- The following changes since commit cba9a894fdb1cb49b60fcd1d1d6919cbd7995dd5: Prepare v2011.12 (2011-12-23 20:25:35 +0100) are available in the git repository at: git://openlinux.windriver.com/people/paulg/u-boot sbc8548-Dec30_2011 Paul Gortmaker (8): Revert SBC8548: fix address mask to allow 64M flash sbc8548: relocate 64MB user flash to sane boundary sbc8548: enable ability to boot from alternate flash sbc8548: Fix LBC SDRAM initialization settings sbc8548: Make enabling SPD RAM configuration work sbc8548: relocate fixed ddr init code to ddr.c file sbc8548: enable support for hardware SPD errata workaround sbc8548: Fix up local bus init to be frequency aware board/sbc8548/ddr.c | 77 +++ board/sbc8548/law.c | 16 +- board/sbc8548/sbc8548.c | 111 +++-- board/sbc8548/tlb.c | 24 ++-- doc/README.sbc8548| 79 ++-- include/configs/sbc8548.h | 151 +++-- 6 files changed, 355 insertions(+), 103 deletions(-) -- applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_lbc: add printout of LCRR and LBCR to local bus regs
On Dec 15, 2011, at 9:22 AM, Paul Gortmaker wrote: It can be handy to have these in the output when trying to debug odd behaviour. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] powerpc/srio: Correct the register defined errors in the struct ccsr_rio_t
On Jan 10, 2012, at 5:42 AM, Liu Gang wrote: + u32 didcar; /* 0xc - Device Identity CAR */ Drop the '0xc' prefix in the comment, same comment for all registers. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] post/Makefile: Only build FP post tests if enabled via CONFIG_SYS_POST_FPU
Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- post/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/post/Makefile b/post/Makefile index 200e2f1..55b7d21 100644 --- a/post/Makefile +++ b/post/Makefile @@ -32,7 +32,7 @@ COBJS-$(CONFIG_POST_STD_LIST) += tests.o SPLIB-$(CONFIG_HAS_POST) = drivers/libpostdrivers.o SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d lib_$(ARCH) ]; then echo \ lib_$(ARCH)/libpost$(ARCH).o; fi) -SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d lib_$(ARCH)/fpu ]; then echo \ +SPLIB-$(CONFIG_SYS_POST_FPU) += $(shell if [ -d lib_$(ARCH)/fpu ]; then echo \ lib_$(ARCH)/fpu/libpost$(ARCH)fpu.o; fi) SPLIB-$(CONFIG_HAS_POST) += $(shell if [ -d cpu/$(CPU) ]; then echo \ cpu/$(CPU)/libpost$(CPU).o; fi) -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] please pull u-boot-mpc85xx
The following changes since commit 9a4209869bd2c37affd931d627b3c3e72952: Rob Herring (1): ARM: highbank: enable networking and pxe are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kyle Moffett (2): eXMeritus HWW-1U-1A: Minor environment variable tweaks eXMeritus HWW-1U-1A: Add support for the AT24C128N I2C EEPROM Paul Gortmaker (9): MPC85xxCDS: Fix missing LCRR_DBYP bits for 66-133MHz LBC Revert SBC8548: fix address mask to allow 64M flash sbc8548: relocate 64MB user flash to sane boundary sbc8548: enable ability to boot from alternate flash sbc8548: Fix LBC SDRAM initialization settings sbc8548: Make enabling SPD RAM configuration work sbc8548: relocate fixed ddr init code to ddr.c file sbc8548: enable support for hardware SPD errata workaround sbc8548: Fix up local bus init to be frequency aware board/freescale/mpc8541cds/mpc8541cds.c |2 +- board/freescale/mpc8555cds/mpc8555cds.c |2 +- board/sbc8548/ddr.c | 77 board/sbc8548/law.c | 16 +++- board/sbc8548/sbc8548.c | 111 +++ board/sbc8548/tlb.c | 24 - doc/README.sbc8548 | 79 +++- include/configs/HWW1U1A.h | 36 +++- include/configs/sbc8548.h | 151 --- 9 files changed, 389 insertions(+), 109 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Remove CONFIG_NET_MULTI from board files
On Jan 11, 2012, at 6:47 AM, Fabio Estevam wrote: CONFIG_NET_MULTI is not used anymore, so remove it from board files. Cc: Marek Vasut marek.va...@gmail.com Cc: Stefano Babic sba...@denx.de Cc: Kumar Gala kumar.g...@freescale.com Cc: Sandeep Paulraj s-paul...@ti.com Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/P1010RDB.h |5 - include/configs/PM826.h|2 -- include/configs/PM828.h|2 -- include/configs/cam_enc_4xx.h |1 - include/configs/coreboot.h |6 -- include/configs/da850_am18xxevm.h |1 - include/configs/ecovec.h |1 - include/configs/efikamx.h |1 - include/configs/enbw_cmc.h |1 - include/configs/ethernut5.h|1 - include/configs/flea3.h|1 - include/configs/m28evk.h |1 - include/configs/omap3_evm_common.h |1 - include/configs/omap3_mvblx.h |1 - include/configs/p1_p2_rdb_pc.h |7 --- include/configs/tam3517-common.h |1 - 16 files changed, 0 insertions(+), 33 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org For P1010RDB p1_p2_rdb_pc.h - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sdhc_boot: Introduce CONFIG_FSL_FIXED_MMC_LOCATION option
On Dec 20, 2011, at 10:33 AM, Fabio Estevam wrote:
Since commit 97039ab98 (env_mmc: Allow board code to override the environment
address)
mmc_get_env_addr is a weak-aliased function in common/env_mmc.c
The mmc_get_env_addr implementation that exists at
board/freescale/common/sdhc_boot.c is meant to be used only for PowerPC
boards,
but currently it is being used for all platforms that have
CONFIG_ENV_IS_IN_MMC defined.
Introduce CONFIG_FSL_FIXED_MMC_LOCATION so that the boards that need to use
the mmc_get_env_addr version from board/freescale/common/sdhc_boot.c could
activate
this config option on their board file.
This fixes the retrieval of CONFIG_ENV_OFFSET on non-PowerPC boards.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/common/Makefile|2 +-
board/freescale/common/sdhc_boot.c |2 ++
include/configs/MPC8536DS.h|1 +
include/configs/P1010RDB.h |1 +
include/configs/P1_P2_RDB.h|1 +
include/configs/P2020COME.h|1 +
include/configs/P2020DS.h |1 +
include/configs/P2041RDB.h |1 +
include/configs/corenet_ds.h |1 +
include/configs/p1_p2_rdb_pc.h |1 +
10 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 9077aaf..5f8f7c6 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -39,7 +39,7 @@ COBJS-$(CONFIG_PQ_MDS_PIB) += pq-mds-pib.o
COBJS-$(CONFIG_ID_EEPROM) += sys_eeprom.o
COBJS-$(CONFIG_FSL_SGMII_RISER) += sgmii_riser.o
ifndef CONFIG_RAMBOOT_PBL
-COBJS-$(CONFIG_ENV_IS_IN_MMC)+= sdhc_boot.o
+COBJS-$(CONFIG_FSL_FIXED_MMC_LOCATION) += sdhc_boot.o
endif
COBJS-$(CONFIG_MPC8541CDS)+= cds_pci_ft.o
diff --git a/board/freescale/common/sdhc_boot.c
b/board/freescale/common/sdhc_boot.c
index e432318..68c335b 100644
--- a/board/freescale/common/sdhc_boot.c
+++ b/board/freescale/common/sdhc_boot.c
@@ -32,6 +32,7 @@
#define ESDHC_BOOT_IMAGE_SIZE 0x48
#define ESDHC_BOOT_IMAGE_ADDR 0x50
+#ifdef CONFIG_FSL_FIXED_MMC_LOCATION
Why is this ifdef needed since we already have it dealt with in the Makefile?
int mmc_get_env_addr(struct mmc *mmc, u32 *env_addr)
{
u8 *tmp_buf;
@@ -61,3 +62,4 @@ int mmc_get_env_addr(struct mmc *mmc, u32 *env_addr)
return 0;
}
+#endif
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 16db98f..4b5373c 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -659,6 +659,7 @@
#define CONFIG_ENV_SECT_SIZE 0x1
#elif defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE 0x2000
#define CONFIG_SYS_MMC_ENV_DEV 0
#else
diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index af4609f..0a22a5c 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -609,6 +609,7 @@ extern unsigned long get_sdram_size(void);
#if defined(CONFIG_SYS_RAMBOOT)
#if defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_SYS_MMC_ENV_DEV0
#define CONFIG_ENV_SIZE 0x2000
#elif defined(CONFIG_RAMBOOT_SPIFLASH)
diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h
index 00fa74d..29f016b 100644
--- a/include/configs/P1_P2_RDB.h
+++ b/include/configs/P1_P2_RDB.h
@@ -519,6 +519,7 @@ extern unsigned long get_board_sys_clk(unsigned long
dummy);
#define CONFIG_ENV_OFFSET ((512 * 1024) +
CONFIG_SYS_NAND_BLOCK_SIZE)
#elif defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE 0x2000
#define CONFIG_SYS_MMC_ENV_DEV0
#elif defined(CONFIG_RAMBOOT_SPIFLASH)
diff --git a/include/configs/P2020COME.h b/include/configs/P2020COME.h
index cf20d2b..f3d1db0 100644
--- a/include/configs/P2020COME.h
+++ b/include/configs/P2020COME.h
@@ -350,6 +350,7 @@ extern unsigned long get_board_sys_clk(unsigned long
dummy);
*/
#if defined(CONFIG_RAMBOOT_SDCARD)
#define CONFIG_ENV_IS_IN_MMC1
+ #define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE 0x2000
#define CONFIG_SYS_MMC_ENV_DEV 0
#elif defined(CONFIG_RAMBOOT_SPIFLASH)
diff --git a/include/configs/P2020DS.h b/include/configs/P2020DS.h
index 2d9657a..2d9b916 100644
--- a/include/configs/P2020DS.h
+++ b/include/configs/P2020DS.h
@@ -596,6 +596,7 @@
*/
#if defined(CONFIG_SDCARD)
#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_FSL_FIXED_MMC_LOCATION
#define CONFIG_ENV_SIZE 0x2000
#define CONFIG_SYS_MMC_ENV_DEV0
#elif defined(CONFIG_SPIFLASH)
diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h
index
Re: [U-Boot] __mmc_get_env_addr() is not being called?
On Dec 16, 2011, at 3:42 AM, Stefano Babic wrote: On 16/12/2011 10:33, Fabio Estevam wrote: The weak function was introduced by this commit: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=97039ab98c551c7860bc0977d684ef686159e0d7 which breaks non CONFIG_FSL_ESDHC users. Ok, I see - the patch is more related to Freescale SOCs as to the MMC, and it is sometimes unknown who whould pick it up. Andy, not CONFIG_FSL_ESDHC means IMX users - if you do not complain, I merge it into u-boot-imx. Thanks, Stefano If I'm reading the patch correct it will break things (or I'm not sure which patch you're referring to). How would the PPC specific version ever get called? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/fm: check the old and new Fman microcode locations in NOR flash
On Dec 14, 2011, at 4:34 PM, Timur Tabi wrote: On some Freescale reference boards for SOCs with Fman devices, the Fman microcode is located at address 0xEF00 in NOR flash. Unfortunately, this address is in the middle of nowhere and makes it difficult to partition flash space for other images. So we change the expected address to 0xEFF4, which is the flash sector adjacent to the environment. To support older boards, we use macro CONFIG_SYS_QE_FMAN_FW_ADDR_OLD to look for the microcode in the old location if it cannot be found in the new one. The code which uploads the microcode checks the new default location, and if the microcode is not found, then it checks the old location. This allows newer U-Boots to work on older boards. However, during boot, the error messages are a bit confusing: Net: Fman1: Data at eff4 is not a firmware Fman1: Uploading microcode version 101.8.0 Fman2: Data at eff4 is not a firmware Fman2: Uploading microcode version 101.8.0 Signed-off-by: Timur Tabi ti...@freescale.com --- drivers/net/fm/fm.c |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) I see no reason for this patch, if you're flashing a new u-boot flash the microcode to the new address as well. Don't we already have a warning if we don't find the ucode at the expected address. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/fm: check the old and new Fman microcode locations in NOR flash
On Dec 15, 2011, at 2:09 PM, Timur Tabi wrote: Kumar Gala wrote: I see no reason for this patch, if you're flashing a new u-boot flash the microcode to the new address as well. This is useful for people who have not moved the microcode. Are we going to ensure that everyone who updates U-Boot will also move their microcode to the new location? We can always revert this patch after everyone has migrated, if that's really necessary. You know as well as I do that if don't provide backwards compatibility, someone is going to break and won't know why. Sure, but they'll get the message about invalid ucode. It will be easy to debug. At some point they're going to have to flash ucode to the new address. I see no reason to delay that. Don't we already have a warning if we don't find the ucode at the expected address. No. The warning just says that microcode is invalid, not that that it's at the wrong address. Invalid is sufficient to say you need to check the ucode at the address its being attempted to be loaded from. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerpc: FOO uses hard float, BAR uses soft float
On Dec 8, 2011, at 4:09 PM, Wolfgang Denk wrote:
Hi,
I'm looking for help to get rid of linker warnigns like these:
- ./MAKEALL sequoia
Configuring for sequoia - Board: sequoia, Options: SEQUOIA
powerpc-linux-ld: Warning: 20010226-1.o uses hard float, libpostpowerpcfpu.o
uses soft float
powerpc-linux-ld: Warning: acc1.o uses hard float, libpostpowerpcfpu.o uses
soft float
powerpc-linux-ld: Warning:
/opt/eldk-5.1/powerpc/sysroots/powerpc-linux/usr/lib/powerpc-linux/4.6.1/libgcc.a(darwin-ldouble.o)
uses hard float, u-boot uses soft float
These warnings are cause by the fact that we always build U-Boot with
-msoft-float, but boards that have POST enabled may pull in the FPU
test code, which naturally will have to be compiled with
-mhard-float instead.
Is there any way to silence these warnings (ideally only for these
specific set of files, where we know they are to be expected) ?
I tried playing tricks to get rid of them - the information about
using the FPU is envoded in the .gnu.attributes section of the ELF
file:
- readelf -A /work/wd/tmp-ppc/post/lib_powerpc/fpu/acc1.o
Attribute Section: gnu
File Attributes
Tag_GNU_Power_ABI_FP: Hard float
- readelf -e /work/wd/tmp-ppc/post/lib_powerpc/fpu/acc1.o | grep
gnu.attributes
[129] .gnu.attributes LOOS+ff5 004e5c 10 00 0 0
1
We can remove this information using brute force, like
${CROSS_COMPILE}objcopy -R .gnu.attributes
which indeed gets rid of most of the warnings - but it will still
result in the
powerpc-linux-ld: Warning:
/opt/eldk-5.1/powerpc/sysroots/powerpc-linux/usr/lib/powerpc-linux/4.6.1/libgcc.a(darwin-ldouble.o)
uses hard float, u-boot uses soft float
warning.
Anybody any ideas?
Look at commit, we dealt with this in the past
commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
Author: Yuri Tikhonov y...@emcraft.com
Date: Sat Dec 20 14:54:21 2008 +0300
FPU POST: fix warnings when building with 2.18 binutils
Also:
commit e009cdeb63308f291c54b173484401aab4a3fe54
Author: Kumar Gala ga...@kernel.crashing.org
Date: Tue Jan 25 03:00:08 2011 -0600
powerpc: Fix FPU post related link warnings
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] please pull u-boot-mpc85xx
The following changes since commit c4eba6ec5c58083b38340724c006294c7a4fe2eb: common/usb_kbd.c: fix bug introduced in commit 00b7d6e (2011-12-09 12:09:35 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Kyle Moffett (1): mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices MAINTAINERS |4 + board/exmeritus/hww1u1a/Makefile | 48 board/exmeritus/hww1u1a/ddr.c | 34 +++ board/exmeritus/hww1u1a/gpios.h | 69 ++ board/exmeritus/hww1u1a/hww1u1a.c | 277 +++ board/exmeritus/hww1u1a/law.c | 34 +++ board/exmeritus/hww1u1a/tlb.c | 106 + boards.cfg|1 + include/configs/HWW1U1A.h | 451 + 9 files changed, 1024 insertions(+), 0 deletions(-) create mode 100644 board/exmeritus/hww1u1a/Makefile create mode 100644 board/exmeritus/hww1u1a/ddr.c create mode 100644 board/exmeritus/hww1u1a/gpios.h create mode 100644 board/exmeritus/hww1u1a/hww1u1a.c create mode 100644 board/exmeritus/hww1u1a/law.c create mode 100644 board/exmeritus/hww1u1a/tlb.c create mode 100644 include/configs/HWW1U1A.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: Add board support for the eXMeritus HWW-1U-1A devices
On Dec 7, 2011, at 3:39 PM, Kyle Moffett wrote: The eXMeritus HWW-1U-1A unit is a DO-160-certified 13lb 1U chassis with 3 independent TEMPEST zones. Two independent P2020 computers may be found inside each zone. Complete hardware support is included. High-level hardware overview: * DO-160 certified for passenger aircraft (noncritical) * TEMPEST ceritified for RED/BLACK separation * 3 zones per chassis, 2 computers per zone (total of 6) * Dual-core 1.066GHz P2020 per computer * One 2GB DDR2 SO-RDIMM module per computer (upgradable to 4GB) * Removable 80GB or 160GB Intel X18-M SSD per computer * Front-accessible dual-port E1000E per computer * Front-accessible serial console per computer * Front-accessible USB port per computer * Internal Gigabit crossover within each TEMPEST zone * Internal unidirectional fiber links across TEMPEST zones * Battery-backed DS1339 I2C RTC on each CPU. Combined, each 13lb 1U chassis contains 12GB RAM, 12 cores @ 1.066GHz, 12 front-accessible Gigabit Ethernet ports and 960GB of solid-state storage with a total power consumption of ~200W. Additional notes: * SPD detection is only known to work with the DO-160-certified DIMMs * CPU reset is a little quirky due to hardware misfeature. Proper support for the hardware reset mechanism has been left for a later patch series to address. Signed-off-by: Kyle Moffett kyle.d.moff...@boeing.com Cc: Andy Fleming aflem...@gmail.com Cc: Kumar Gala kumar.g...@freescale.com -- applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p2041rdb: fix serdes clock map
On Dec 1, 2011, at 7:38 PM, Shaohui Xie wrote: Description of SerDes clock Bank2 setting in p2041 hardware specification is wrong, the clock map which based on it is wrong either, so fix the serdes clock map. wrong setting of SERDES Reference Clocks Bank2: SW2[5:6] = ON OFF =100MHz for PCI mode SW2[5:6] = OFF ON =125MHz for SGMII mode right setting of SERDES Reference Clocks Bank2: SW2[5:6] = OFF OFF=100MHz for PCI mode SW2[5:6] = OFF ON =125MHz for SGMII mode SW2[5:6] = ON OFF =156.25MHZ Signed-off-by: Shaohui Xie shaohui@freescale.com --- board/freescale/p2041rdb/p2041rdb.c | 25 +++-- 1 files changed, 15 insertions(+), 10 deletions(-) applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] Allow for parallel builds and saved output
On Nov 21, 2011, at 5:40 PM, Andy Fleming wrote:
The MAKEALL script cleverly runs make with the appropriate options
to use all of the cores on the system, but your average U-Boot build
can't make much use of more than a few cores. If you happen to have
a many-core server, your builds will leave most of the system idle.
In order to make full use of such a system, we need to build multiple
targets in parallel, and this requires directing make output into
multiple directories. We add a BUILD_NBUILDS variable, which allows
users to specify how many builds to run in parallel.
When BUILD_NBUILDS is set greater than 1, we redefine BUILD_DIR for
each build to be ${BUILD_DIR}/${target}. Also, we make ./build the
default BUILD_DIR when BUILD_NBUILDS is greater than 1.
MAKEALL now tracks which builds are still running, and when one
finishes, it starts a new build.
Once each build finishes, we run make tidy on its directory, to reduce
the footprint.
As a result, we are left with a build directory with all of the built
targets still there for use, which means anyone who wanted to use
MAKEALL as part of a test harness can now do so.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
v2: - Update to keep BUILD_NBUILDS builds in flight, rather than batching
- Clean up style things
- Defer error output until build completion to make output *slightly*
more readable
Can you re-fresh patch against top of tree.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/bootm: Flush ramdisk and device tree image when booting on MP
We already flush the kernel image after we've loaded it to ensure
visiblity to the other cores. We need to do the same thing for the
ramdisk and device tree images. In AMP boot scenarios we might not be
HW cache coherent with the secondary core that we are loading and
setting the ramdisk and device tree up for. Thus we need to ensure
we've flushed the regions of memory utilized by ramdisk and device tree
so the loadding and any modifications (from decompression or fdt updates)
are made visible to the secondary cores.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/lib/bootm.c | 22 --
common/image.c |8
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 8233f1f..efcfe84 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -174,6 +174,18 @@ void arch_lmb_reserve(struct lmb *lmb)
return ;
}
+static void boot_prep_linux(bootm_headers_t *images)
+{
+#ifdef CONFIG_MP
+ /*
+* if we are MP make sure to flush the device tree so any changes are
+* made visibile to all other cores. In AMP boot scenarios the cores
+* might not be HW cache coherent with each other.
+*/
+ flush_cache((unsigned long)images-ft_addr, images-ft_len);
+#endif
+}
+
static int boot_cmdline_linux(bootm_headers_t *images)
{
ulong of_size = images-ft_len;
@@ -329,19 +341,17 @@ int do_bootm_linux(int flag, int argc, char * const
argv[], bootm_headers_t *ima
return 0;
}
- /*
-* We do nothing report success to retain compatiablity with older
-* versions of u-boot in which this use to flush the dcache on MP
-* systems
-*/
- if (flag BOOTM_STATE_OS_PREP)
+ if (flag BOOTM_STATE_OS_PREP) {
+ boot_prep_linux(images);
return 0;
+ }
if (flag BOOTM_STATE_OS_GO) {
boot_jump_linux(images);
return 0;
}
+ boot_prep_linux(images);
ret = boot_body_linux(images);
if (ret)
return ret;
diff --git a/common/image.c b/common/image.c
index aacae5a..77ca6e4 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1104,6 +1104,14 @@ int boot_ramdisk_high(struct lmb *lmb, ulong rd_data,
ulong rd_len,
memmove_wd((void *)*initrd_start,
(void *)rd_data, rd_len, CHUNKSZ);
+#ifdef CONFIG_MP
+ /*
+* Ensure the image is flushed to memory to handle
+* AMP boot scenarios in which we might not be
+* HW cache coherent
+*/
+ flush_cache((unsigned long)*initrd_start, rd_len);
+#endif
puts(OK\n);
}
} else {
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/bootm: Flush ramdisk and device tree image when booting on MP
On Dec 7, 2011, at 10:17 AM, Tabi Timur-B04825 wrote:
On Wed, Dec 7, 2011 at 8:42 AM, Kumar Gala ga...@kernel.crashing.org wrote:
+ if (flag BOOTM_STATE_OS_PREP) {
+ boot_prep_linux(images);
return 0;
+ }
if (flag BOOTM_STATE_OS_GO) {
boot_jump_linux(images);
return 0;
}
+ boot_prep_linux(images);
Why are we calling boot_prep_linux(images) when flag
BOOTM_STATE_OS_PREP is zero? If we don't want the OS to be PREPped,
then why call a function named boot_prep_linux()?
We call it in both cases, one is for 'normal' bootm command the other is for
'bootm subcommand'.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Include common.h in qsort.c to fix build warning
On Dec 6, 2011, at 5:37 PM, Simon Glass wrote: exports.h no longer includes common.h, which contains assert(). qsort.c needs to be updated. This fixes this warning: qsort.c: In function 'qsort': qsort.c:30:3: warning: implicit declaration of function 'assert' [-Wimplicit-function-declaration] Signed-off-by: Simon Glass s...@chromium.org --- lib/qsort.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org --- w/o this we actually have compile failure with the tree: In file included from qsort.c:19:0: /local/home/galak/git/u-boot/include/exports.h:19:27: error: expected declaration specifiers or '...' before 'va_list' qsort.c: In function 'qsort': qsort.c:30:3: warning: implicit declaration of function 'assert' - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Standalone Apps: Standalone apps should need only exports.h.
On Dec 6, 2011, at 1:53 PM, Wolfgang Denk wrote: Dear Mike Partington, In message 1288211469-32443-1-git-send-email-mpart...@lexmark.com you wrote: Modify exports.h to remove its dependencies on other files, thus enabling standalone apps to require only exports.h from the U-Boot source tree. This appears to be the intent based on the following note: http://lists.denx.de/pipermail/u-boot/2010-January/067174.html Signed-off-by: Mike Partington mpart...@lexmark.com --- Changes for v2: - Replace domain specific email address with generic address examples/standalone/atmel_df_pow2.c |1 + examples/standalone/stubs.c |1 + include/exports.h |5 + 3 files changed, 3 insertions(+), 4 deletions(-) Applied, thanks. Best regards, Wolfgang Denk This breaks builds: In file included from qsort.c:19:0: /local/home/galak/git/u-boot/include/exports.h:19:27: error: expected declaration specifiers or '...' before 'va_list' qsort.c: In function 'qsort': qsort.c:30:3: warning: implicit declaration of function 'assert' Simon has posted a patch that fixes: http://patchwork.ozlabs.org/patch/129855/ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request u-boot-85xx.git
The following changes since commit ea45cb0adcf4baa8f939fea4c848f3e1906f19d9: net: Make sure IPaddr_t is 32 bits in size (2011-12-06 22:15:32 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Shaohui Xie (1): p2041rdb: fix serdes clock map board/freescale/p2041rdb/p2041rdb.c | 25 +++-- 1 files changed, 15 insertions(+), 10 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MAKEALL: Add -l option to only list build targets
Would be nice if the commit message explained why you're adding this feature. - k On Dec 3, 2011, at 1:32 AM, Marek Vasut wrote: Signed-off-by: Marek Vasut marek.va...@gmail.com Cc: Wolfgang Denk w...@denx.de --- MAKEALL | 15 +-- 1 files changed, 13 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/14] arch/powerpc/cpu/mpc86xx/cpu.c: Fix GCC 4.6 build warning
On Nov 30, 2011, at 2:17 AM, Wolfgang Denk wrote: Fix: cpu.c: In function 'checkcpu': cpu.c:51:7: warning: variable 'ver' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de Cc: Kumar Gala ga...@kernel.crashing.org --- total: 0 errors, 0 warnings, 21 lines checked NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE Acked-by: Kumar Gala ga...@kernel.crashing.org - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/14] board/freescale/mpc8610hpcd/mpc8610hpcd.c: Fix GCC 4.6 build warning
On Nov 30, 2011, at 2:17 AM, Wolfgang Denk wrote: Fix: mpc8610hpcd.c: In function 'pci_init_board': mpc8610hpcd.c:238:15: warning: variable 'pordevsr' set but not used [-Wunused-but-set-variable] Signed-off-by: Wolfgang Denk w...@denx.de Cc: Kumar Gala ga...@kernel.crashing.org --- total: 0 errors, 0 warnings, 13 lines checked NOTE: Ignored message types: COMPLEX_MACRO CONSIDER_KSTRTO MINMAX MULTISTATEMENT_MACRO_USE_DO_WHILE board/freescale/mpc8610hpcd/mpc8610hpcd.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) Acked-by: Kumar Gala ga...@kernel.crashing.org - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [u-boot][PATCH] uboot/flexcan: fixup flexcan clock-frequency
On Nov 15, 2011, at 1:04 AM, Jia Hongtao wrote: Make the fixup matchable with dts and kernel. Update the compatible from fsl,flexcan-v1.0 to fsl,p1010-flexcan and Change the clock-freq property to clock-frequency. We also change flexcan frequency from CCB-clock to CCB-clock/2 according to P1010 spec. We now keep the old interfaces to make previous kernel work. They should be removed in the future. Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- arch/powerpc/cpu/mpc85xx/fdt.c | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Add workaround for erratum A-003474
On Nov 20, 2011, at 12:01 PM, York Sun wrote: Erratum A-003474: Internal DDR calibration circuit is not supported Impact: Experience shows no significant benefit to device operation with auto-calibration enabled versus it disabled. To ensure consistent timing results, Freescale recommends this feature be disabled in future customer products. There should be no impact to parts that are already operating in the field. Workaround: Prior to setting DDR_SDRAM_CFG[MEM_EN]=1, do the following: 1. Write a value of 0x_0015 to the register at offset CCSRBAR + DDR OFFSET + 0xf30 2. Write a value of 0x2400_ to the register at offset CCSRBAR + DDR OFFSET + 0xf54 Signed-off-by: York Sun york...@freescale.com --- arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++ arch/powerpc/cpu/mpc85xx/ddr-gen3.c |5 + arch/powerpc/include/asm/config_mpc85xx.h |7 +++ 3 files changed, 15 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [v2] powerpc/85xx: clean up and document the QE/FMAN microcode macros
On Nov 22, 2011, at 9:21 AM, Timur Tabi wrote: Several macros are used to identify and locate the microcode binary image that U-boot needs to upload to the QE or Fman. Both the QE and the Fman use the QE Firmware binary format to package their respective microcode data, which is why the same macros are used for both. A given SOC will only have a QE or an Fman, so this is safe. Unfortunately, the current macro definition and usage has inconsistencies. For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address of NAND. There's no way to know by looking at a variable how it's supposed to be used. In the future, the code which uploads QE firmware and Fman firmware will be merged. Signed-off-by: Timur Tabi ti...@freescale.com --- README | 38 +++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 12 +- arch/powerpc/cpu/mpc85xx/fdt.c |2 +- drivers/net/fm/fm.c | 32 ++-- drivers/qe/qe.c |4 +- include/configs/MPC8569MDS.h|3 +- include/configs/P1023RDS.h | 10 +--- include/configs/P2041RDB.h | 16 +- include/configs/corenet_ds.h| 16 +- include/configs/p1_p2_rdb_pc.h |5 ++- 10 files changed, 94 insertions(+), 44 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] powerpc/85xx: CONFIG_FSL_SATA_V2 should be defined in config_mpc85xx.h
On Nov 21, 2011, at 5:10 PM, Timur Tabi wrote: Macro CONFIG_FSL_SATA_V2 is defined if the SOC has a V2 Freescale SATA controller, so it should be defined in config_mpc85xx.h instead of the various board header files. So now CONFIG_FSL_SATA_V2 is always defined on the P1013, P1022, P2041, P3041, P5010, and P5020. It was already defined for the P1010 and P1014. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/include/asm/config_mpc85xx.h |6 ++ include/configs/P1022DS.h |1 - include/configs/P2041RDB.h|5 ++--- include/configs/P3041DS.h |1 - include/configs/P5020DS.h |1 - 5 files changed, 8 insertions(+), 6 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/85xx: always implement the work-around for Erratum SATA_A001
On Nov 21, 2011, at 5:10 PM, Timur Tabi wrote: On the P1022/P1013, the work-around for erratum SATA_A001 was implemented only if U-Boot initializes SATA, but SATA is not initialized by default. So move the work-around to the CPU initialization function, so that it's always executed on the SOCs that need it. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/cpu/mpc85xx/cpu_init.c | 37 +++--- drivers/block/fsl_sata.c| 21 --- drivers/block/fsl_sata.h|1 + 3 files changed, 34 insertions(+), 25 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p3060qds: Add board related support for P3060QDS platform
On Nov 22, 2011, at 2:51 AM, Shengzhou Liu wrote: The P3060QDS is a Freescale reference board for the six-core P3060 SOC. P3060QDS Board Overview: Memory subsystem: - 2G Bytes unbuffered DDR3 SDRAM SO-DIMM(64bit bus) - 128M Bytes NOR flash single-chip memory - 16M Bytes SPI flash - 8K Bytes AT24C64 I2C EEPROM for RCW Ethernet: - Eight Ethernet controllers (4x1G + 4x1G/2.5G) - Three VSC8641 PHYs on board (2xRGMII + 1xMII) - Suport multiple Vitesse VSC8234 SGMII Cards in Slot1/2/3 PCIe: Two PCI Express 2.0 controllers/ports USB: Two USB2.0, USB1(TYPE-A) and USB2(TYPE-AB) on board I2C: Four I2C controllers UART: Supports two dUARTs up to 115200 bps for console RapidIO: Two RapidIO, sRIO1 and sRIO2 Signed-off-by: Shengzhou Liu shengzhou@freescale.com Signed-off-by: York Sun york...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- based on 'master' branch of Wolfgang's tree. board/freescale/common/Makefile |3 + board/freescale/common/ics307_clk.c | 21 +- board/freescale/common/qixis.c| 151 + board/freescale/common/qixis.h| 101 ++ board/freescale/p3060qds/Makefile | 54 board/freescale/p3060qds/ddr.c| 248 +++ board/freescale/p3060qds/eth.c| 482 + board/freescale/p3060qds/fixed_ddr.c | 214 + board/freescale/p3060qds/p3060qds.c | 341 board/freescale/p3060qds/p3060qds.h | 30 ++ board/freescale/p3060qds/p3060qds_qixis.h | 74 + boards.cfg|3 + doc/README.p3060qds | 111 +++ include/configs/P3060QDS.h| 48 +++ include/configs/corenet_ds.h |6 +- 15 files changed, 1878 insertions(+), 9 deletions(-) create mode 100644 board/freescale/common/qixis.c create mode 100644 board/freescale/common/qixis.h create mode 100644 board/freescale/p3060qds/Makefile create mode 100644 board/freescale/p3060qds/ddr.c create mode 100644 board/freescale/p3060qds/eth.c create mode 100644 board/freescale/p3060qds/fixed_ddr.c create mode 100644 board/freescale/p3060qds/p3060qds.c create mode 100644 board/freescale/p3060qds/p3060qds.h create mode 100644 board/freescale/p3060qds/p3060qds_qixis.h create mode 100644 doc/README.p3060qds create mode 100644 include/configs/P3060QDS.h applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/3] mpc8xxx: update module_type values from JEDEC DDR3 SPD Specification
On Nov 21, 2011, at 3:20 PM, Ira W. Snyder wrote: Newer JEDEC DDR3 SPD Specifications define several additional values for the DDR3 module_type field which were undefined when this code was written. Update the code to handle the newer module types. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu Cc: York Sun york...@freescale.com --- New in v5. Supercedes the patch titled: [PATCH v4 2/3] mpc8xxx: assume unregistered DIMM for invalid SPD module_type JEDEC Specification used: http://www.jedec.org/standards-documents/docs/spd-4010211 arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |7 +++ include/ddr_spd.h |7 +++ 2 files changed, 14 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/3] mpc85xx: support board-specific reset function
On Nov 21, 2011, at 3:20 PM, Ira W. Snyder wrote: This is useful for boards which cannot be reset in the usual way for the 85xx CPU. An example is a board which can only be reset by a hardware watchdog. Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- Unchanged from v1. arch/powerpc/cpu/mpc85xx/cpu.c | 17 - 1 files changed, 16 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: verify the localbus device tree address before booting the OS
On Nov 16, 2011, at 1:28 PM, Timur Tabi wrote: The localbus controller node in the device tree is typically a root node, even though the controller is part of CCSR. If we were to put the lbc node under the SOC node, then the 'ranges' property in the lbc node would translate through the 'ranges' property of the parent SOC node, and we don't want that. Since the lbc is a separate node, it's possible for the 'reg' property to be wrong. This happened with the original version of p1022ds.dts, which used a 32-bit value in the 'reg' address, instead of a 36-bit address. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/cpu/mpc85xx/fdt.c | 48 --- 1 files changed, 39 insertions(+), 9 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6] mpc85xx: support for Freescale COM Express P2020
On Nov 23, 2011, at 10:25 AM, Ira W. Snyder wrote: This adds support for the Freescale COM Express P2020 board. This board is similar to the P1_P2_RDB, but has some extra (as well as missing) peripherals. Unlike all other mpc85xx boards, it uses a watchdog timeout to reset. Using the HRESET_REQ register does not work. This board has no NOR flash, and can only be booted via SD or SPI. This procedure is documented in Freescale Document Number AN3659 Booting from On-Chip ROM (eSDHC or eSPI). Some alternative documentation is provided in Freescale Document Number P2020RM P2020 QorIQ Integrated Processor Reference Manual (section 4.5). Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request u-boot-85xx.git
The following changes since commit a63d9652757605ec5f7104addc5d38bf10ba8671: menu.c: use puts() instead of printf() where possible (2011-11-28 20:19:41 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Ira W. Snyder (3): mpc8xxx: update module_type values from JEDEC DDR3 SPD Specification mpc85xx: support board-specific reset function mpc85xx: support for Freescale COM Express P2020 Jia Hongtao (1): powerpc/85xx: fixup flexcan device tree clock-frequency Kumar Gala (2): powerpc/85xx: Add workaround for erratum CPU-A003999 arch/powerpc/cpu/mpc8xxx/ddr/interactive.c: Fix GCC 4.6 build warning Shengzhou Liu (1): powerpc/p3060qds: Add board related support for P3060QDS platform Timur Tabi (4): powerpc/85xx: CONFIG_FSL_SATA_V2 should be defined in config_mpc85xx.h powerpc/85xx: always implement the work-around for Erratum SATA_A001 powerpc/85xx: clean up and document the QE/FMAN microcode macros powerpc/85xx: verify the localbus device tree address before booting the OS York Sun (1): powerpc/85xx: Add workaround for erratum A-003474 MAINTAINERS |4 + README | 38 ++ arch/powerpc/cpu/mpc85xx/cmd_errata.c |6 + arch/powerpc/cpu/mpc85xx/cpu.c | 17 +- arch/powerpc/cpu/mpc85xx/cpu_init.c | 49 ++- arch/powerpc/cpu/mpc85xx/ddr-gen3.c |5 + arch/powerpc/cpu/mpc85xx/fdt.c | 63 ++- arch/powerpc/cpu/mpc85xx/release.S |6 + arch/powerpc/cpu/mpc85xx/start.S|6 + arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |7 + arch/powerpc/cpu/mpc8xxx/ddr/interactive.c |3 +- arch/powerpc/include/asm/config_mpc85xx.h | 19 + arch/powerpc/include/asm/immap_85xx.h |1 + board/freescale/common/Makefile |3 + board/freescale/common/ics307_clk.c | 21 +- board/freescale/common/qixis.c | 151 ++ board/freescale/common/qixis.h | 101 board/freescale/p2020come/Makefile | 46 ++ board/freescale/p2020come/ddr.c | 45 ++ board/freescale/p2020come/law.c | 39 ++ board/freescale/p2020come/p2020come.c | 287 +++ board/freescale/p2020come/tlb.c | 99 board/freescale/p3060qds/Makefile | 54 +++ board/freescale/p3060qds/ddr.c | 248 ++ board/freescale/p3060qds/eth.c | 482 +++ board/freescale/p3060qds/fixed_ddr.c| 214 + board/freescale/p3060qds/p3060qds.c | 341 ++ board/freescale/p3060qds/p3060qds.h | 30 ++ board/freescale/p3060qds/p3060qds_qixis.h | 74 +++ boards.cfg |5 + doc/README.p3060qds | 111 + drivers/block/fsl_sata.c| 21 - drivers/block/fsl_sata.h|1 + drivers/net/fm/fm.c | 32 +- drivers/qe/qe.c |4 +- include/configs/MPC8569MDS.h|3 +- include/configs/P1022DS.h |1 - include/configs/P1023RDS.h | 10 +- include/configs/P2020COME.h | 576 +++ include/configs/P2041RDB.h | 21 +- include/configs/P3041DS.h |1 - include/configs/P3060QDS.h | 48 ++ include/configs/P5020DS.h |1 - include/configs/corenet_ds.h| 22 +- include/configs/p1_p2_rdb_pc.h |5 +- include/ddr_spd.h |7 + 46 files changed, 3231 insertions(+), 97 deletions(-) create mode 100644 board/freescale/common/qixis.c create mode 100644 board/freescale/common/qixis.h create mode 100644 board/freescale/p2020come/Makefile create mode 100644 board/freescale/p2020come/ddr.c create mode 100644 board/freescale/p2020come/law.c create mode 100644 board/freescale/p2020come/p2020come.c create mode 100644 board/freescale/p2020come/tlb.c create mode 100644 board/freescale/p3060qds/Makefile create mode 100644 board/freescale/p3060qds/ddr.c create mode 100644 board/freescale/p3060qds/eth.c create mode 100644 board/freescale/p3060qds/fixed_ddr.c create mode 100644 board/freescale/p3060qds/p3060qds.c create mode 100644 board/freescale/p3060qds/p3060qds.h create mode 100644 board/freescale/p3060qds/p3060qds_qixis.h create mode 100644 doc/README.p3060qds create mode 100644 include/configs/P2020COME.h create mode 100644 include/configs/P3060QDS.h ___ U-Boot mailing list U-Boot@lists.denx.de
Re: [U-Boot] [PATCH] drivers/bios_emulator/x86emu/ops2.c: Fix GCC 4.6 build warning
On Nov 24, 2011, at 11:14 AM, Marek Vasut wrote: Fix: x86emu/ops2.c: In function 'x86emuOp2_set_byte': x86emu/ops2.c:171:11: warning: variable 'name' set but not used [-Wunused-but-set-variable] Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- drivers/bios_emulator/x86emu/ops2.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/bios_emulator/x86emu/ops2.c b/drivers/bios_emulator/x86emu/ops2.c index 937bf4c..59dbb42 100644 --- a/drivers/bios_emulator/x86emu/ops2.c +++ b/drivers/bios_emulator/x86emu/ops2.c @@ -42,6 +42,7 @@ ** **/ #include common.h +#include linux/compiler.h #include x86emu/x86emui.h /*- Implementation */ @@ -168,7 +169,7 @@ void x86emuOp2_set_byte(u8 op2) int mod, rl, rh; uint destoffset; u8 *destreg; -char *name = 0; +__maybe_unused char *name = 0; I don't like this __maybe_unused stuff, it seems like you're hiding possible errors. welcome for ideas on a better fix. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/3] mpc85xx: support for Freescale COM Express P2020
On Nov 21, 2011, at 3:20 PM, Ira W. Snyder wrote: This adds support for the Freescale COM Express P2020 board. This board is similar to the P1_P2_RDB, but has some extra (as well as missing) peripherals. Unlike all other mpc85xx boards, it uses a watchdog timeout to reset. Using the HRESET_REQ register does not work. This board has no NOR flash, and can only be booted via SD or SPI. This procedure is documented in Freescale Document Number AN3659 Booting from On-Chip ROM (eSDHC or eSPI). Some alternative documentation is provided in Freescale Document Number P2020RM P2020 QorIQ Integrated Processor Reference Manual (section 4.5). Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu --- Changes v4 - v5: - unchanged Changes v3 - v4: - address review comments (magic numbers, etc.) - boot via L2 SRAM - use SPD EEPROM to initialize DDR SDRAM Changes v2 - v3: - re-enable CCSR relocation Changes v1 - v2: - fix checkpatch warnings - remove all references to NAND - update to top of tree U-Boot - remove CCSR relocation MAINTAINERS |4 + arch/powerpc/include/asm/immap_85xx.h |1 + board/freescale/p2020come/Makefile| 46 +++ board/freescale/p2020come/ddr.c | 45 +++ board/freescale/p2020come/law.c | 39 +++ board/freescale/p2020come/p2020come.c | 287 board/freescale/p2020come/tlb.c | 99 ++ boards.cfg|2 + include/configs/P2020COME.h | 576 + 9 files changed, 1099 insertions(+), 0 deletions(-) create mode 100644 board/freescale/p2020come/Makefile create mode 100644 board/freescale/p2020come/ddr.c create mode 100644 board/freescale/p2020come/law.c create mode 100644 board/freescale/p2020come/p2020come.c create mode 100644 board/freescale/p2020come/tlb.c create mode 100644 include/configs/P2020COME.h Some compiler warnings to deal with: speed.c: In function 'get_sys_info': speed.c:184:4: warning: implicit declaration of function 'get_board_ddr_clk' speed.c: In function 'get_sys_info': speed.c:184:4: warning: implicit declaration of function 'get_board_ddr_clk' Do you want 'CONFIG_FSL_DDR_INTERACTIVE' turned on by default? interactive.c: In function 'fsl_ddr_interactive': interactive.c:1357:15: warning: variable 'len' set but not used [-Wunused-but-set-variable] I'll look at this one. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arch/powerpc/cpu/mpc8xxx/ddr/interactive.c: Fix GCC 4.6 build warning
Fix:
interactive.c: In function 'fsl_ddr_interactive':
interactive.c:1357:15: warning: variable 'len' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/cpu/mpc8xxx/ddr/interactive.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/interactive.c
b/arch/powerpc/cpu/mpc8xxx/ddr/interactive.c
index d7d66ef..5b72437 100644
--- a/arch/powerpc/cpu/mpc8xxx/ddr/interactive.c
+++ b/arch/powerpc/cpu/mpc8xxx/ddr/interactive.c
@@ -1354,7 +1354,6 @@ unsigned long long fsl_ddr_interactive(fsl_ddr_info_t
*pinfo)
{
unsigned long long ddrsize;
const char *prompt = FSL DDR;
- unsigned int len;
char buffer[CONFIG_SYS_CBSIZE];
char *argv[CONFIG_SYS_MAXARGS + 1]; /* NULL terminated */
int argc;
@@ -1389,7 +1388,7 @@ unsigned long long fsl_ddr_interactive(fsl_ddr_info_t
*pinfo)
* No need to worry for buffer overflow here in
* this function; readline() maxes out at CFG_CBSIZE
*/
- len = readline_into_buffer(prompt, buffer);
+ readline_into_buffer(prompt, buffer);
argc = parse_line(buffer, argv);
if (argc == 0)
continue;
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] drivers/bios_emulator/x86emu/ops2.c: Fix GCC 4.6 build warning
Fix: x86emu/ops2.c: In function 'x86emuOp2_set_byte': x86emu/ops2.c:171:11: warning: variable 'name' set but not used [-Wunused-but-set-variable] Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- drivers/bios_emulator/x86emu/ops2.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/bios_emulator/x86emu/ops2.c b/drivers/bios_emulator/x86emu/ops2.c index 937bf4c..59dbb42 100644 --- a/drivers/bios_emulator/x86emu/ops2.c +++ b/drivers/bios_emulator/x86emu/ops2.c @@ -42,6 +42,7 @@ / #include common.h +#include linux/compiler.h #include x86emu/x86emui.h /*- Implementation */ @@ -168,7 +169,7 @@ void x86emuOp2_set_byte(u8 op2) int mod, rl, rh; uint destoffset; u8 *destreg; -char *name = 0; +__maybe_unused char *name = 0; int cond = 0; START_OF_INSTR(); -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_nvedit.c: Fix compiler warning introduced by checkpatch cleanup
cmd_nvedit.c: In function 'do_env_grep':
cmd_nvedit.c:182:3: warning: suggest parentheses around assignment used as
truth value
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
common/cmd_nvedit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 7409a36..5995354 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -179,7 +179,7 @@ static int do_env_grep(cmd_tbl_t *cmdtp, int flag,
while (arg = argc) {
idx = 0;
- while (idx = hstrstr_r(argv[arg], idx, match, env_htab)) {
+ while ((idx = hstrstr_r(argv[arg], idx, match, env_htab))) {
if (!(matched[idx / 8] (1 (idx 7 {
puts(match-key);
puts(=);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: clean up and document the QE/FMAN microcode macros
On Nov 8, 2011, at 5:40 PM, Timur Tabi wrote: Several macros are used to identify and locate the microcode binary image that U-boot needs to upload to the QE or Fman. Both the QE and the Fman use the QE Firmware binary format to package their respective microcode data, which is why the same macros are used for both. A given SOC will only have a QE or an Fman, so this is safe. Unfortunately, the current macro definition and usage has inconsistencies. For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address of NAND. There's no way to know by looking at a variable how it's supposed to be used. In the future, the code which uploads QE firmware and Fman firmware will be merged. Signed-off-by: Timur Tabi ti...@freescale.com --- README | 38 +++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 12 +- arch/powerpc/cpu/mpc85xx/fdt.c |2 +- drivers/net/fm/fm.c | 32 ++-- drivers/qe/qe.c |4 +- include/configs/MPC8569MDS.h|3 +- include/configs/P1023RDS.h | 10 +--- include/configs/P2041RDB.h | 13 +++ include/configs/corenet_ds.h| 16 +- include/configs/p1_p2_rdb_pc.h |5 ++- 10 files changed, 92 insertions(+), 43 deletions(-) Can your respin against current upstream HEAD. For some reason this doesn't apply cleanly there. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Allow for parallel builds and saved output
On Nov 20, 2011, at 12:11 AM, Simon Glass wrote:
Hi Kumar,
On Tue, Nov 8, 2011 at 5:48 AM, Kumar Gala ga...@kernel.crashing.org wrote:
On Nov 3, 2011, at 11:22 AM, Simon Glass wrote:
Hi Andy,
On Thu, Nov 3, 2011 at 12:28 AM, Andy Fleming aflem...@freescale.com
wrote:
The MAKEALL script cleverly runs make with the appropriate options
to use all of the cores on the system, but your average U-Boot build
can't make much use of more than a few cores. If you happen to have
a many-core server, your builds will leave most of the system idle.
In order to make full use of such a system, we need to build multiple
targets in parallel, and this requires directing make output into
multiple directories. We add a BUILD_NBUILDS variable, which allows
users to specify how many builds to run in parallel. I've found that
16 is too many on my system (fork starts to fail). When BUILD_NBUILDS
is set greater than 1, we redefine BUILD_DIR for each build to be
${BUILD_DIR}/${target}. Also, we make ./build the default BUILD_DIR
when BUILD_NBUILDS is greater than 1.
Once each build finishes, we run make clean on its directory, to reduce
the footprint, and also remove all .depend files.
As a result, we are left with a build directory with all of the built
targets still there for use, which means anyone who wanted to use
MAKEALL as part of a test harness can now do so.
Signed-off-by: Andy Fleming aflem...@freescale.com
---
Inspired by all the MAKEALL improvements, I decided to clean up my old
one for parallel builds. I think this version addresses the concerns
raised last time...
I see an issue if I have a build in working tree already. I think we might
need a distclean before starting
I also it seems this does things in clumps of BUILD_NBUILDS. What I mean
is, if BUILD_NBUILDS is 4, you do 4 and wait for all 4 to finish before
starting the 5th job once the 1st is complete. Anything we can do about
that to always try and have 4 builds going until the end?
- k
What is the issue you see? Given that it uses an empty output dir for
each build, I can't see what could be wrong.
I think if I have an existing build in my source tree it screws up between that
and the O= build.
I am seeing a strange issue which is probably my fault. In a whole
MAKEALL maybe one build (always mx31 so far) fails with errors like
this:
$ more logs/mx31pdk.ERR
mv: cannot stat
`/c/cosarm/buildall/u-boot/build/mx31pdk/include/autoconf.mk.tmp
': No such file or directory
/c/cosarm/buildall/u-boot/include/timestamp.h:27: fatal error:
generated/timesta
mp_autogenerated.h: No such file or directory
compilation terminated.
make[1]: *** No rule to make target
`/c/cosarm/buildall/u-boot/build/mx31pdk/arc
h/arm/cpu/arm1136/.depend', needed by `_depend'. Stop.
In file included from /c/cosarm/buildall/u-boot/include/version.h:27:0,
from mkimage.c:26:
/c/cosarm/buildall/u-boot/include/timestamp.h:27:47: fatal error:
generated/time
stamp_autogenerated.h: No such file or directory
compilation terminated.
/c/cosarm/buildall/u-boot/include/timestamp.h:27: fatal error:
generated/timesta
mp_autogenerated.h: No such file or directory
compilation terminated.
make[1]: *** No rule to make target
`/c/cosarm/buildall/u-boot/build/imx31_phyco
re/arch/arm/cpu/arm1136/.depend', needed by `_depend'. Stop.
In file included from /c/cosarm/buildall/u-boot/include/version.h:27:0,
from mkimage.c:26:
/c/cosarm/buildall/u-boot/include/timestamp.h:27:47: fatal error:
generated/time
stamp_autogenerated.h: No such file or directory
compilation terminated.
make[1]: *** [/c/cosarm/buildall/u-boot/build/imx31_phycore/tools/mkimage.o]
Err
or 1
make: *** [tools] Error 2
I really can't see that Andy's change can affect this, but perhaps it
provokes an existing bug by changing the timing. I see the issue when
building 16 U-Boots at a time.
I haven't looked into it in detail - maybe there is a dependency
missing in the Makefile. But I would have thought that this line would
ensure that these files exist before anything else is done:
depend dep: $(TIMESTAMP_FILE) $(VERSION_FILE) \
...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] mpc85xx: support for Freescale COM Express P2020
If you look at current board/freescale/p1_p2_rdb/law.c it doesn't have PCI
LAWs anymore. I think for your example you just need an empty data
structure:
struct law_entry law_table[] = {
};
this should hopefully make num_law_entries = 0;
+};
+
+int num_law_entries = ARRAY_SIZE(law_table);
Unfortunately, having a law_table with no entries causes a bug. A nasty
bug which was hard to track down.
When law_table is empty, and when num_law_entries = 0, both variables
exist in BSS only.
Both the law_table and num_law_entries are used in init_laws(), called
from cpu_init_early_f(). This happens before BSS is initialized. Also
before DDR is initialized.
And now you see the bug. The U-Boot hangs due to an invalid memory
access. This is before the console is initialized, making it hard to
track down.
Yeah, that's nasty. need to think on this a bit to see if I can come up with
any good answer.
How do you suggest I work around this? A single redundant entry in the
law_table works (the system boots).
For now I'd go with that and add a comment in law.c about it.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: clean up and document the QE/FMAN microcode macros
On Nov 8, 2011, at 5:40 PM, Timur Tabi wrote:
Several macros are used to identify and locate the microcode binary image
that U-boot needs to upload to the QE or Fman. Both the QE and the Fman
use the QE Firmware binary format to package their respective microcode data,
which is why the same macros are used for both. A given SOC will only have
a QE or an Fman, so this is safe.
Unfortunately, the current macro definition and usage has inconsistencies.
For example, CONFIG_SYS_FMAN_FW_ADDR was used to define the address of Fman
firmware in NOR flash, but CONFIG_SYS_QE_FW_IN_NAND contains the address
of NAND. There's no way to know by looking at a variable how it's supposed
to be used.
In the future, the code which uploads QE firmware and Fman firmware will
be merged.
Signed-off-by: Timur Tabi ti...@freescale.com
---
README | 38 +++
arch/powerpc/cpu/mpc85xx/cpu_init.c | 12 +-
arch/powerpc/cpu/mpc85xx/fdt.c |2 +-
drivers/net/fm/fm.c | 32 ++--
drivers/qe/qe.c |4 +-
include/configs/MPC8569MDS.h|3 +-
include/configs/P1023RDS.h | 10 +---
include/configs/P2041RDB.h | 13 +++
include/configs/corenet_ds.h| 16 +-
include/configs/p1_p2_rdb_pc.h |5 ++-
10 files changed, 92 insertions(+), 43 deletions(-)
diff --git a/README b/README
index c05c40a..33cd678 100644
--- a/README
+++ b/README
@@ -3263,6 +3263,44 @@ Low Level (hardware related) configuration options:
be used if available. These functions may be faster under some
conditions but may increase the binary size.
+Freescale QE/FMAN Firmware Support:
+---
+
+The Freescale QUICCEngine (QE) and Frame Manager (FMAN) both support the
+loading of firmware, which is encoded in the QE firmware binary format.
+This firmware often needs to be loaded during U-Boot booting, so macros
+are used to identify the storage device (NOR flash, SPI, etc) and the address
+within that device.
+
+- CONFIG_SYS_QE_FMAN_FW_ADDR
+ The address in the storage device where the firmware is located. The
+ meaning of this address depends on which CONFIG_SYS_QE_FW_IN_xxx macro
+ is also specified.
+
+- CONFIG_SYS_QE_FMAN_FW_LENGTH
+ The maximum possible size of the firmware. The firmware binary format
+ has a field that specifies the actual size of the firmware, but it
+ might not be possible to read any part of the firmware unless some
+ local storage is allocated to hold the entire firmware first.
+
+- CONFIG_SYS_QE_FMAN_FW_IN_NOR
+ Specifies that QE/FMAN firmware is located in NOR flash, mapped as
+ normal addressable memory via the LBC. CONFIG_SYS_FMAN_FW_ADDR is the
+ virtual address in NOR flash.
+
+- CONFIG_SYS_QE_FMAN_FW_IN_NAND
+ Specifies that QE/FMAN firmware is located in NAND flash.
+ CONFIG_SYS_FMAN_FW_ADDR is the offset within NAND flash.
+
+- CONFIG_SYS_QE_FMAN_FW_IN_MMC
+ Specifies that QE/FMAN firmware is located on the primary SD/MMC
+ device. CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
+
+- CONFIG_SYS_QE_FMAN_FW_IN_SPIFLASH
+ Specifies that QE/FMAN firmware is located on the primary SPI
+ device. CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
+
+
Building the Software:
==
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 0a4ce53..5e42955 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -38,7 +38,7 @@
#include asm/fsl_law.h
#include asm/fsl_serdes.h
#include mp.h
-#ifdef CONFIG_SYS_QE_FW_IN_NAND
+#ifdef CONFIG_SYS_QE_FMAN_FW_IN_NAND
#include nand.h
#include errno.h
#endif
@@ -524,17 +524,17 @@ void cpu_secondary_init_r(void)
{
#ifdef CONFIG_QE
uint qe_base = CONFIG_SYS_IMMR + 0x0008; /* QE immr base */
-#ifdef CONFIG_SYS_QE_FW_IN_NAND
+#ifdef CONFIG_SYS_QE_FMAN_FW_IN_NAND
int ret;
- size_t fw_length = CONFIG_SYS_QE_FW_LENGTH;
+ size_t fw_length = CONFIG_SYS_QE_FMAN_FW_LENGTH;
/* load QE firmware from NAND flash to DDR first */
- ret = nand_read(nand_info[0], (loff_t)CONFIG_SYS_QE_FW_IN_NAND,
- fw_length, (u_char *)CONFIG_SYS_QE_FW_ADDR);
+ ret = nand_read(nand_info[0], (loff_t)CONFIG_SYS_QE_FMAN_FW_IN_NAND,
+ fw_length, (u_char *)CONFIG_SYS_QE_FMAN_FW_ADDR);
if (ret ret == -EUCLEAN) {
printf (NAND read for QE firmware at offset %x failed %d\n,
- CONFIG_SYS_QE_FW_IN_NAND, ret);
+ CONFIG_SYS_QE_FMAN_FW_IN_NAND, ret);
}
#endif
qe_init(qe_base);
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c
Re: [U-Boot] [STATUS] Help needed - urgently
On Nov 17, 2011, at 6:40 AM, Stefano Babic wrote: On 11/16/2011 10:35 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message d75ba016-4e89-4cea-acec-cc322ff58...@kernel.crashing.org you wrote: Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. On suggestion I'd have is we improve our use of patchworks. Right now there is way too much 'stale' on patchworks so its difficult to extract what needs to be looked at from what might be owned by existing maintainers. As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Sure, but anyway to avoid conflicts I suggest that who takes care of a patch *firstly* sets his name as delegate into patchwork before doing something. Agreed, my thinking was that for the non-maintained patches, the maintainer that pulls a patch in to their tree would mark themselves as the delegate of the patch. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
On Nov 16, 2011, at 3:35 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message d75ba016-4e89-4cea-acec-cc322ff58...@kernel.crashing.org you wrote: Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. On suggestion I'd have is we improve our use of patchworks. Right now there is way too much 'stale' on patchworks so its difficult to extract what needs to be looked at from what might be owned by existing maintainers. As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Can we say no new patches are going into upstream (your tree) until maintainers go cleanup patchworks? Such that the # of non-delegated patches is only one or two pages worth, rather than 11. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
On Nov 17, 2011, at 8:10 AM, Wolfgang Denk wrote: Dear Kumar Gala, In message dec2dbe6-d658-4504-b157-7b57bb637...@kernel.crashing.org you wrote: As a first step this requires someone who is brave enought oclean up the existing state, which is indeed a mess. Can we say no new patches are going into upstream (your tree) until maintainers go cleanup patchworks? Such that the # of non-delegated patches is only one or two pages worth, rather than 11. With no new patches you mean that I will stop applying already posted patches, or new postings to the ML? I'm fine with both... I meant the stop applying patches… not sure how we'd stop people posting new patches to the ML ;) - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Nov 17, 2011, at 7:55 AM, Albert ARIBAUD wrote: Hi Sandeep, Le 16/11/2011 16:24, s-paul...@ti.com a écrit : The following changes since commit 75acc4d7c1c9081e06d1197c6da01361cf1bce92: Heiko Schocher (1): arm, davinci: add DAVINCI_MMC_CLKID are available in the git repository at: git://git.denx.de/u-boot-ti.git master Sanjeev Premi (2): part_efi: Fix compile errors omap3evm: Add support for EFI partitions disk/part_efi.c |6 +++--- include/configs/omap3_evm.h |1 + 2 files changed, 4 insertions(+), 3 deletions(-) Applied to u-boot-arm/master, thanks! Guys, can you please cleanup patchworks for all the ARM patches and other ARM sub-maintainers: http://patchwork.ozlabs.org/project/uboot/list/ - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] sbc8548 build broken?
On Nov 17, 2011, at 5:33 PM, Robert Hurdle wrote: Hello Mr. Denk, You wrote: you wrote: I downloaded the ELDK 4.2 and installed it. I got the u-boot source from git://git.denx.de/u-boot-mpc85xx.git. When I try to build u-boot for sbc8548 I get the following error: arch/powerpc/cpu/mpc8xxx/ddr/libddr.o: In function `fsl_ddr_compute': /home/rhurdle/proj/u-boot/arch/powerpc/cpu/mpc8xxx/ddr/main.c:375: undefined reference to `fsl_ddr_get_dimm_params' make: *** [u-boot] Error 1 I cannot confirm this - using current top of tree I get: + MAKEALL_LOGDIR=/work/wd/tmp-ppc-LOG + BUILD_DIR=/work/wd/tmp-ppc + ./MAKEALL sbc8548 Configuring for sbc8548 board... textdata bss dec hex filename 1999288956 24576 233460 38ff4 /work/wd/tmp-ppc/u-boot - SUMMARY Boards compiled: 1 -- I have obtained the source from the current top of the tree. When I make using the following: make CROSS_COMPILE=ppc_85xx- sbc8548_PCI_33_PCIE_config make CROSS_COMPILE=ppc_85xx- OPTFLAGS=-O2 all I am still having the same undefined reference above. Should I be building with ppc_8xx instead? If yes, why? Thanks, This appears to be due to you trying to build with OPTFLAGS=-O2. Remove that and see what happens. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] Help needed - urgently
On Nov 15, 2011, at 9:01 AM, Wolfgang Denk wrote: Hello all, I guess most of you will already have noticed that my activity on the mailing list has significantly declined recently. I'm sorry for that, but I find myself in a situation where I have even less time available for U-Boot than usually. In the result, the number of unapplied (and sometimes unreviewed) patches is growing and growing. I need your help. we need to find a way to distribute the workload for general patches (i. e. those that don't fall obviously into the responsibility of a specific custodian) across more shoulders than just mine. Pressure on me has been building up already for some time, and now we've reached the point where we need to find a solution. One possible approach has been suggested before: Maybe the load can be spread here - maintainers can put these in designated branches in their repositories. I know this will cause the odd conflict, If you script this (based on pwapply) you can bail out early if the patch is no longer in state New. but we (the maintainers) could also periodically sync between each other. Another alternative is to create a new repo that all the custodians have access to... That would be easy to do... Maybe that's what we do - Once a patch reaches maturity (a revision with an Ack and maybe a Tested-by) any maintainer can just put it in the 'next' repo - You can always veto it and not pull it into mainline anyway, but at least it gives everyone a semi-stable platform to base patches for the next merge window I would like to try this out now, taking effect immediately. I have created a new repository u-boot-staging, where all current custodians (should) have write access to. My proposal is as follows (please feel free to comment): - Any custodian is able (and encouraged) to pick up unapplied patches that have reached maturity (ideally an Ack and maybe a Tested-by), but at least no negative feedback on the mailing list, and re-review these. If they are considered OK and do not cause any new build issues, they can be applied. Please don't forget to update the entries in Patchwork. - To ensure quality, no custodian should apply his own patches. - After reviewing and build testing (MAKEALL for at least two different architectures) the stuff can be pushed into a _branch_ of the u-boot-staging repository. I suggest to use the custodian's e-mail address as branch name. - After that, the custodian can send a pull request to me. Please let's try if this works. If you have any suggestions how to help better, please don't hesitate to tell us. On suggestion I'd have is we improve our use of patchworks. Right now there is way too much 'stale' on patchworks so its difficult to extract what needs to be looked at from what might be owned by existing maintainers. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Add workaround for erratum CPU-A003999
Erratum A-003999: Running Floating Point instructions requires special initialization. Impact: Floating point arithmetic operations may result in an incorrect value. Workaround: Perform a read modify write to set bit 7 to a 1 in SPR 977 before executing any floating point arithmetic operation. This bit can be set when setting MSR[FP], and can be cleared when clearing MSR[FP]. Alternatively, the bit can be set once at boot time, and never cleared. There will be no performance degradation due to setting this bit. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++ arch/powerpc/cpu/mpc85xx/release.S|6 ++ arch/powerpc/cpu/mpc85xx/start.S |6 ++ arch/powerpc/include/asm/config_mpc85xx.h |6 ++ 4 files changed, 21 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/cmd_errata.c b/arch/powerpc/cpu/mpc85xx/cmd_errata.c index 07be03e..f7c0934 100644 --- a/arch/powerpc/cpu/mpc85xx/cmd_errata.c +++ b/arch/powerpc/cpu/mpc85xx/cmd_errata.c @@ -53,6 +53,9 @@ static int do_errata(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) #if defined(CONFIG_SYS_P4080_ERRATUM_CPU22) puts(Work-around for Erratum CPU22 enabled\n); #endif +#if defined(CONFIG_SYS_FSL_ERRATUM_CPU_A003999) + puts(Work-around for Erratum CPU-A003999 enabled\n); +#endif #if defined(CONFIG_SYS_FSL_ERRATUM_DDR_MSYNC_IN) puts(Work-around for DDR MSYNC_IN Erratum enabled\n); #endif diff --git a/arch/powerpc/cpu/mpc85xx/release.S b/arch/powerpc/cpu/mpc85xx/release.S index 6678ed4..c81e19c 100644 --- a/arch/powerpc/cpu/mpc85xx/release.S +++ b/arch/powerpc/cpu/mpc85xx/release.S @@ -68,6 +68,12 @@ __secondary_start_page: mtspr SPRN_HID1,r3 #endif +#ifdef CONFIG_SYS_FSL_ERRATUM_CPU_A003999 + mfspr r3,977 + orisr3,r3,0x0100 + mtspr 977,r3 +#endif + /* Enable branch prediction */ lis r3,BUCSR_ENABLE@h ori r3,r3,BUCSR_ENABLE@l diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 39f1438..d032788 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -264,6 +264,12 @@ l2_disabled: mtspr HID1,r0 #endif +#ifdef CONFIG_SYS_FSL_ERRATUM_CPU_A003999 + mfspr r3,977 + orisr3,r3,0x0100 + mtspr 977,r3 +#endif + /* Enable Branch Prediction */ #if defined(CONFIG_BTB) lis r0,BUCSR_ENABLE@h diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 424ab79..dba9eda 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -316,6 +316,7 @@ #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_SYS_FSL_ERRATUM_USB138 +#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999 #elif defined(CONFIG_PPC_P2041) #define CONFIG_MAX_CPUS4 @@ -335,6 +336,7 @@ #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_SYS_FSL_ERRATUM_USB138 +#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999 #elif defined(CONFIG_PPC_P3041) #define CONFIG_MAX_CPUS4 @@ -354,6 +356,7 @@ #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY #define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_SYS_FSL_ERRATUM_USB138 +#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999 #elif defined(CONFIG_PPC_P3060) #define CONFIG_MAX_CPUS8 @@ -369,6 +372,7 @@ #define CONFIG_SYS_FSL_PCIE_COMPAT fsl,qoriq-pcie-v2.2 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 #define CONFIG_SYS_FSL_ERRATUM_DDR_A003 +#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999 #elif defined(CONFIG_PPC_P4040) #define CONFIG_MAX_CPUS4 @@ -379,6 +383,7 @@ #define CONFIG_SYS_FSL_TBCLK_DIV 16 #define CONFIG_SYS_FSL_PCIE_COMPAT fsl,p4080-pcie #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 +#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999 #elif defined(CONFIG_PPC_P4080) #define CONFIG_MAX_CPUS8 @@ -407,6 +412,7 @@ #define CONFIG_SYS_P4080_ERRATUM_SERDES9 #define CONFIG_SYS_P4080_ERRATUM_SERDES_A001 #define CONFIG_SYS_P4080_ERRATUM_SERDES_A005 +#define CONFIG_SYS_FSL_ERRATUM_CPU_A003999 /* P5010 is single core version of P5020 */ #elif defined(CONFIG_PPC_P5010) -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert sandbox: Change md command to use map_physmem
On Nov 12, 2011, at 2:07 PM, Simon Glass wrote:
Hi Kumar,
On Sat, Nov 12, 2011 at 10:02 AM, Kumar Gala ga...@kernel.crashing.org
wrote:
This reverts commit 355a835747c6f7c5071ead295a7dfc489c73cb03.
The original commit broke long standing assumption that md commands work
on effective addresses. This normally isn't an issue for most systems
that map 1:1, however on systems with a 36-bit address map it breaks.
What is the system that shows this problem?
Any PPC system that have _36BIT and some that imply it in boards.cfg
With sandbox we need some sort of mapping here - what do you suggest?
map_virtmem?
Not sure, what the need is w/sandbox so hard to suggest a solution.
It would be good to get a solution to this rather than just reverting.
Sure, but I'd rather revert in short term so the mainline tree works for all
existing boards, rather than for the new feature until we come up with a
solution.
Regards,
Simon
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
common/cmd_mem.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 461ee19..28476d7 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -33,7 +33,6 @@
#include dataflash.h
#endif
#include watchdog.h
-#include asm/io.h
#ifdef CMD_MEM_DEBUG
#definePRINTF(fmt,args...) printf (fmt ,##args)
@@ -142,13 +141,9 @@ int do_mem_md ( cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
# endif
{
- ulong bytes = size * length;
- void *buf = map_physmem(addr, bytes, MAP_WRBACK);
-
/* Print the lines. */
- print_buffer(addr, buf, size, length, DISP_LINE_LEN / size);
- addr += bytes;
- unmap_physmem(buf, bytes);
+ print_buffer(addr, (void*)addr, size, length,
DISP_LINE_LEN/size);
+ addr += size*length;
}
#endif
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Revert sandbox: Change md command to use map_physmem
This reverts commit 355a835747c6f7c5071ead295a7dfc489c73cb03.
The original commit broke long standing assumption that md commands work
on effective addresses. This normally isn't an issue for most systems
that map 1:1, however on systems with a 36-bit address map it breaks.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
common/cmd_mem.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/common/cmd_mem.c b/common/cmd_mem.c
index 461ee19..28476d7 100644
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -33,7 +33,6 @@
#include dataflash.h
#endif
#include watchdog.h
-#include asm/io.h
#ifdef CMD_MEM_DEBUG
#definePRINTF(fmt,args...) printf (fmt ,##args)
@@ -142,13 +141,9 @@ int do_mem_md ( cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
# endif
{
- ulong bytes = size * length;
- void *buf = map_physmem(addr, bytes, MAP_WRBACK);
-
/* Print the lines. */
- print_buffer(addr, buf, size, length, DISP_LINE_LEN / size);
- addr += bytes;
- unmap_physmem(buf, bytes);
+ print_buffer(addr, (void*)addr, size, length,
DISP_LINE_LEN/size);
+ addr += size*length;
}
#endif
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/2] mpc85xx: support for Freescale COM Express P2020
+phys_size_t fixed_sdram(void)
+{
+ char buf[32];
+ fsl_ddr_cfg_regs_t ddr_cfg_regs;
+ size_t ddr_size;
+ struct cpu_type *cpu;
+ ulong ddr_freq, ddr_freq_mhz;
+
+ cpu = gd-cpu;
+ /* P1020 and it's derivatives support max 32bit DDR width */
+ if (cpu-soc_ver == SVR_P1020 || cpu-soc_ver == SVR_P1020_E ||
+ cpu-soc_ver == SVR_P1011 || cpu-soc_ver == SVR_P1011_E) {
+ ddr_size = (CONFIG_SYS_SDRAM_SIZE * 1024 * 1024 / 2);
These checks don't make sense if you are a P2020 SoC
This entire file is identical to board/freescale/p1_p2_rdb/ddr.c. In
fact, since this board only boots via the On-Chip ROM, the whole file is
useless: fixed_sdram() should just return the RAM size. We're running
from RAM when this function executes.
Is it ok with you if I replace the entire file with the following?
phys_size_t fixed_sdram(void)
{
return CONFIG_SYS_SDRAM_SIZE 20;
}
If the board has SO-DIMMs than I'd expect SPD support. Sounds like you're
working on this w/Matt York.
diff --git a/board/freescale/p2020come/law.c
b/board/freescale/p2020come/law.c
new file mode 100644
index 000..56508db
--- /dev/null
+++ b/board/freescale/p2020come/law.c
@@ -0,0 +1,36 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/fsl_law.h
+#include asm/mmu.h
+
+struct law_entry law_table[] = {
+ SET_LAW(CONFIG_SYS_PCIE1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCIE_1),
+ SET_LAW(CONFIG_SYS_PCIE1_IO_PHYS, LAW_SIZE_64K, LAW_TRGT_IF_PCIE_1),
+ SET_LAW(CONFIG_SYS_PCIE2_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCIE_2),
+ SET_LAW(CONFIG_SYS_PCIE2_IO_PHYS, LAW_SIZE_64K, LAW_TRGT_IF_PCIE_2),
+ SET_LAW(CONFIG_SYS_PCIE3_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCIE_3),
+ SET_LAW(CONFIG_SYS_PCIE3_IO_PHYS, LAW_SIZE_64K, LAW_TRGT_IF_PCIE_3),
We normally set these up dynamically.
This is a modified version of the code from
board/freescale/p1_p2_rdb/law.c. Can you suggest an in tree example of
the way you'd like the code to look? I copied what I assume is a good
example…
If you look at current board/freescale/p1_p2_rdb/law.c it doesn't have PCI LAWs
anymore. I think for your example you just need an empty data structure:
struct law_entry law_table[] = {
};
this should hopefully make num_law_entries = 0;
+};
+
+int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/p2020come/p2020come.c
b/board/freescale/p2020come/p2020come.c
new file mode 100644
index 000..2e334cf
--- /dev/null
+++ b/board/freescale/p2020come/p2020come.c
@@ -0,0 +1,401 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include hwconfig.h
+#include command.h
+#include asm/processor.h
+#include asm/mmu.h
+#include asm/cache.h
+#include asm/immap_85xx.h
+#include asm/fsl_serdes.h
+#include asm/io.h
+#include miiphy.h
+#include libfdt.h
+#include fdt_support.h
+#include fsl_mdio.h
+#include tsec.h
+#include vsc7385.h
+#include netdev.h
+#include mmc.h
+#include malloc.h
+#include i2c.h
+
+#if defined(CONFIG_PCI)
+#include asm/fsl_pci.h
+#include pci.h
+#endif
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#if defined(CONFIG_PCI)
+void pci_init_board(void)
+{
+ fsl_pcie_init_board(0);
+}
+
+void
Re: [U-Boot] [PATCH v3 2/2] mpc85xx: support for Freescale COM Express P2020
On Nov 10, 2011, at 3:11 PM, Ira W. Snyder wrote:
This adds support for the Freescale COM Express P2020 board. This board
is similar to the P1_P2_RDB, but has some extra (as well as missing)
peripherals.
Unlike all other mpc85xx boards, it uses a watchdog timeout to reset.
Using the HRESET_REQ register does not work.
This board has no NOR flash, and can only be booted via SD or SPI. This
procedure is documented in Freescale Document Number AN3659 Booting
from On-Chip RAM (eSDHC or eSPI). Some alternative documentation is
provided in Freescale Document Number P2020RM P2020 QorIQ Integrated
Processor Reference Manual (section 4.5).
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
diff --git a/board/freescale/p2020come/ddr.c b/board/freescale/p2020come/ddr.c
new file mode 100644
index 000..dd2a4dd
--- /dev/null
+++ b/board/freescale/p2020come/ddr.c
@@ -0,0 +1,245 @@
+/*
+ * Copyright 2009, 2011 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include asm/mmu.h
+#include asm/immap_85xx.h
+#include asm/processor.h
+#include asm/fsl_ddr_sdram.h
+#include asm/io.h
+#include asm/fsl_law.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define CONFIG_SYS_DDR_CS0_BNDS 0x003F
+#define CONFIG_SYS_DDR_CS0_CONFIG0x80014202
+#define CONFIG_SYS_DDR_CS0_CONFIG_2 0x
+#define CONFIG_SYS_DDR_INIT_ADDR 0x
+#define CONFIG_SYS_DDR_INIT_EXT_ADDR 0x
+#define CONFIG_SYS_DDR_MODE_CONTROL 0x
+#define CONFIG_SYS_DDR_ZQ_CONTROL0x
+#define CONFIG_SYS_DDR_WRLVL_CONTROL 0x
+#define CONFIG_SYS_DDR_SR_CNTR 0x
+#define CONFIG_SYS_DDR_RCW_1 0x
+#define CONFIG_SYS_DDR_RCW_2 0x
+#define CONFIG_SYS_DDR_CONTROL 0x4300 /* Type = DDR2*/
+#define CONFIG_SYS_DDR_CONTROL_2 0x24401000
+#define CONFIG_SYS_DDR_TIMING_4 0x
+#define CONFIG_SYS_DDR_TIMING_5 0x
+
+#define CONFIG_SYS_DDR_TIMING_3_400 0x0001
+#define CONFIG_SYS_DDR_TIMING_0_400 0x00260802
+#define CONFIG_SYS_DDR_TIMING_1_400 0x39355322
+#define CONFIG_SYS_DDR_TIMING_2_400 0x1f9048ca
+#define CONFIG_SYS_DDR_CLK_CTRL_400 0x0280
+#define CONFIG_SYS_DDR_MODE_1_4000x00480432
+#define CONFIG_SYS_DDR_MODE_2_4000x
+#define CONFIG_SYS_DDR_INTERVAL_400 0x06180100
+
+#define CONFIG_SYS_DDR_TIMING_3_533 0x0002
+#define CONFIG_SYS_DDR_TIMING_0_533 0x00260802
+#define CONFIG_SYS_DDR_TIMING_1_533 0x4c47c432
+#define CONFIG_SYS_DDR_TIMING_2_533 0x0f9848ce
+#define CONFIG_SYS_DDR_CLK_CTRL_533 0x0280
+#define CONFIG_SYS_DDR_MODE_1_5330x00040642
+#define CONFIG_SYS_DDR_MODE_2_5330x
+#define CONFIG_SYS_DDR_INTERVAL_533 0x08200100
+
+#define CONFIG_SYS_DDR_TIMING_3_667 0x0003
+#define CONFIG_SYS_DDR_TIMING_0_667 0x55770802
+#define CONFIG_SYS_DDR_TIMING_1_667 0x5f599543
+#define CONFIG_SYS_DDR_TIMING_2_667 0x0fa074d1
+#define CONFIG_SYS_DDR_CLK_CTRL_667 0x0300
+#define CONFIG_SYS_DDR_MODE_1_6670x00040852
+#define CONFIG_SYS_DDR_MODE_2_6670x
+#define CONFIG_SYS_DDR_INTERVAL_667 0x0a280100
+
+#define CONFIG_SYS_DDR_TIMING_3_800 0x0004
+#define CONFIG_SYS_DDR_TIMING_0_800 0x00770802
+#define CONFIG_SYS_DDR_TIMING_1_800 0x6f6b6543
+#define CONFIG_SYS_DDR_TIMING_2_800 0x0fa074d1
+#define CONFIG_SYS_DDR_CLK_CTRL_800 0x0280
+#define CONFIG_SYS_DDR_MODE_1_8000x00040852
+#define CONFIG_SYS_DDR_MODE_2_8000x
+#define CONFIG_SYS_DDR_INTERVAL_800 0x0c300100
+
+fsl_ddr_cfg_regs_t ddr_cfg_regs_400 = {
+ .cs[0].bnds = CONFIG_SYS_DDR_CS0_BNDS,
+ .cs[0].config = CONFIG_SYS_DDR_CS0_CONFIG,
+ .cs[0].config_2 = CONFIG_SYS_DDR_CS0_CONFIG_2,
+ .timing_cfg_3 = CONFIG_SYS_DDR_TIMING_3_400,
+ .timing_cfg_0 = CONFIG_SYS_DDR_TIMING_0_400,
+ .timing_cfg_1 = CONFIG_SYS_DDR_TIMING_1_400,
+ .timing_cfg_2 = CONFIG_SYS_DDR_TIMING_2_400,
+ .ddr_sdram_cfg = CONFIG_SYS_DDR_CONTROL,
+ .ddr_sdram_cfg_2 = CONFIG_SYS_DDR_CONTROL_2,
+ .ddr_sdram_mode = CONFIG_SYS_DDR_MODE_1_400,
Re: [U-Boot] [PATCH 2/2] P1022DS: set max alloc length to 10MB
On Nov 1, 2011, at 8:16 PM, chang-ming.hu...@freescale.com chang-ming.hu...@freescale.com wrote: From: Jerry Huang chang-ming.hu...@freescale.com In order to support 1920x01080 resolution, we must increase the alloc length. Acked-by: Timur Tabi ti...@freescale.com Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com CC: Anatolij Gustschin ag...@denx.de --- include/configs/P1022DS.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] powerpc/mpc85xx: Set SYSCLK to the required frequency
On Nov 3, 2011, at 2:18 AM, chang-ming.hu...@freescale.com chang-ming.hu...@freescale.com wrote: From: Jerry Huang chang-ming.hu...@freescale.com For ICS307-02, there is one general expression to generate SYSCLK: CLK1Frequency = InputFrequency * 2 * (VDW + 8) / ((RDW + 2) * OD) If we want the required frequency for SYSCLK, we must find one solution to generate this frequency, this solution includes VDW, RDW and OD. For OD, there are only eight option value: 10, 2, 8, 4, 5, 7, 3, 6. For RDW, the range is 1 to 127. For VDW, the range is 4 to 511. First, we use one OD, RDW and required SYSCLK to calculate the VDW, if VDW is in it's range, we will calculate the CLK1Frequency with the OD, RDW and VDW calculated, and we will check this percent (CLK1Frequency / required SYSCLK), and the precision is 1/1000. if the percent is less than 1/1000, we think the CLK1Frequency is we want. Otherwise, We will continue to calculate it with the next OD and RDW. Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com CC: Kumar Gala kumar.g...@freescale.com --- changes for v2: - move these macro to .c file - change the subject to powerpc/mpc85xx - add CC board/freescale/common/ics307_clk.c | 69 +++ board/freescale/common/ics307_clk.h |4 ++- board/freescale/common/ngpixis.c| 27 ++ 3 files changed, 99 insertions(+), 1 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH]powerpc/85xx: Make inclusion of USB device fixup conditional
On Nov 7, 2011, at 10:51 PM, Ramneek Mehresh wrote: Include call to usb device-fixup only when CONFIG_HAS_FSL_DR_USB is defined for the platform - P1020RDB, P1010RDB, P1020-PC Signed-off-by: Ramneek Mehresh ramneek.mehr...@freescale.com --- board/freescale/p1010rdb/p1010rdb.c |2 ++ board/freescale/p1_p2_rdb/p1_p2_rdb.c |2 ++ board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c |3 +++ 3 files changed, 7 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] phylib: Enable AR8021 phy support
On Nov 11, 2011, at 3:19 AM, Xie Xiaobo wrote: Enable AR8021 as it used on Freescale Combo boards. The Combo boards included P1020RDB-PC, P1021RDB-PC, P2020RDB-PC, P1020UTM-PC, and P1020MSBG-PC. Signed-off-by: Xie Xiaobo x@freescale.com --- include/config_phylib_all_drivers.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied to 85xx - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Fix NAND SPL support
On Nov 9, 2011, at 9:15 AM, Kumar Gala wrote: We cause CCSRBAR to be relocated in the SPL phase of NAND boot which isn't expected and breaks things. Fixing the board config.h to NOT relocate CCSR during the CONFIG_NAND_SPL phase. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/configs/MPC8536DS.h|2 +- include/configs/MPC8569MDS.h |2 +- include/configs/MPC8572DS.h|2 +- include/configs/P1_P2_RDB.h|2 +- include/configs/p1_p2_rdb_pc.h |2 +- 5 files changed, 5 insertions(+), 5 deletions(-) applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx: Fix MPC8572DS NAND build
On Nov 8, 2011, at 11:04 AM, Kumar Gala wrote: Reduce NAND SPL build size by not include TLB entries that arent used by it. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- board/freescale/mpc8572ds/tlb.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) applied - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/16] Fix GCC 4.6 build warning related to MPC85xx builds
On Nov 9, 2011, at 10:29 AM, Kumar Gala wrote: Address 85xx specific gcc 4.6 warnings applied 1-16 - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: Fix builds of P1020/P2020RDB-PC_36BIT_NAND
Size grew a bit so nand-spl didn't fit in 4k, reduce done by removing
LAW entries not needed during SPL phase.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
board/freescale/p1_p2_rdb_pc/law.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/board/freescale/p1_p2_rdb_pc/law.c
b/board/freescale/p1_p2_rdb_pc/law.c
index 5ff6ea6..7968919 100644
--- a/board/freescale/p1_p2_rdb_pc/law.c
+++ b/board/freescale/p1_p2_rdb_pc/law.c
@@ -25,15 +25,17 @@
#include asm/mmu.h
struct law_entry law_table[] = {
- SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_64M, LAW_TRGT_IF_LBC),
+#ifndef CONFIG_NAND_SPL
SET_LAW(CONFIG_SYS_CPLD_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
SET_LAW(CONFIG_SYS_PMC_BASE_PHYS, LAW_SIZE_64K, LAW_TRGT_IF_LBC),
-#ifdef CONFIG_SYS_NAND_BASE_PHYS
- SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
-#endif
#ifdef CONFIG_VSC7385_ENET
SET_LAW(CONFIG_SYS_VSC7385_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
#endif
+#endif
+ SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_64M, LAW_TRGT_IF_LBC),
+#ifdef CONFIG_SYS_NAND_BASE_PHYS
+ SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
+#endif
};
int num_law_entries = ARRAY_SIZE(law_table);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request u-boot-85xx.git
The following changes since commit 5721385b187b3154c7768e6c182501022f4e2e45: Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx (2011-11-08 07:44:52 +0100) are available in the git repository at: git://git.denx.de/u-boot-mpc85xx.git master Jerry Huang (2): powerpc/mpc85xx: Set SYSCLK to the required frequency powerpc/85xx: Set max alloc length to 10MB on P1022DS Kumar Gala (20): powerpc/85xx: Add support for Book-E MMU Arch v2.0 powerpc/85xx: Fix MPC8572DS NAND build powerpc/85xx: Fix NAND SPL support arch/powerpc/cpu/mpc85xx/cpu_init.c: Fix GCC 4.6 build warning arch/powerpc/cpu/mpc85xx/tlb.c: Fix GCC 4.6 build warning arch/powerpc/cpu/mpc8xxx/fsl_lbc.c: Fix GCC 4.6 build warning board/freescale/common/cds_pci_ft.c: Fix GCC 4.6 build warning board/freescale/common/pixis.c: Fix GCC 4.6 build warning board/freescale/mpc8548cds/mpc8548cds.c: Fix GCC 4.6 build warning board/freescale/mpc8568mds/mpc8568mds.c: Fix GCC 4.6 build warning board/freescale/mpc8569mds/mpc8569mds.c: Fix GCC 4.6 build warning board/sbc8548/sbc8548.c: Fix GCC 4.6 build warning board/sbc8560/sbc8560.c: Fix GCC 4.6 build warning drivers/net/fm/fm.c: Fix GCC 4.6 build warning drivers/usb/host/ehci-fsl.c: Fix GCC 4.6 build warning drivers/qe/uec.c: Fix GCC 4.6 build warning arch/powerpc/cpu/mpc8xxx/ddr/options.c: Fix GCC 4.6 build warning arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c: Fix GCC 4.6 build warning arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c: Fix GCC 4.6 build warning powerpc/85xx: Fix builds of P1020/P2020RDB-PC_36BIT_NAND Poonam Aggrwal (1): fsl_ifc: Fixed a bug in the erratum handling code for IFC_A003399 Ramneek Mehresh (2): powerpc/85xx: Fix warning for USB device-fixup powerpc/85xx: Make inclusion of USB device fixup conditional Roy Zang (1): powerpc/QorIQ: fix network frame manager TBI PHY address settings Timur Tabi (5): powerpc/85xx: fix definition of MAS register macros powerpc/85xx: fix some comments in the CCSR relocation code powerpc/85xx: add some missing sync instructions in the CCSR relocation code powerpc/85xx: verify the current address of CCSR before relocating it powerpc/85xx: resize the boot page TLB before relocating CCSR Xie Xiaobo (1): phylib: Enable AR8021 phy support chenhui zhao (2): powerpc/mpc8548: Add workaround for erratum NMG_eTSEC129 powerpc/mpc8548cds: Fix network initialization arch/powerpc/cpu/mpc85xx/cmd_errata.c |4 + arch/powerpc/cpu/mpc85xx/cpu_init.c |3 +- arch/powerpc/cpu/mpc85xx/cpu_init_early.c |4 +- arch/powerpc/cpu/mpc85xx/fsl_corenet_serdes.c |7 ++- arch/powerpc/cpu/mpc85xx/start.S | 84 ++- arch/powerpc/cpu/mpc85xx/tlb.c| 17 +++-- arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c |7 +-- arch/powerpc/cpu/mpc8xxx/ddr/options.c|4 + arch/powerpc/cpu/mpc8xxx/fdt.c| 24 --- arch/powerpc/cpu/mpc8xxx/fsl_lbc.c|4 +- arch/powerpc/include/asm/config_mpc85xx.h |1 + arch/powerpc/include/asm/mmu.h| 10 ++-- arch/powerpc/include/asm/processor.h |6 ++ board/freescale/common/cds_pci_ft.c |3 +- board/freescale/common/ics307_clk.c | 69 ++ board/freescale/common/ics307_clk.h |4 +- board/freescale/common/ngpixis.c | 27 +++ board/freescale/common/pixis.c|4 +- board/freescale/corenet_ds/eth_hydra.c|8 -- board/freescale/corenet_ds/eth_p4080.c|8 -- board/freescale/mpc8548cds/mpc8548cds.c | 69 +++--- board/freescale/mpc8568mds/mpc8568mds.c |3 +- board/freescale/mpc8569mds/mpc8569mds.c |2 - board/freescale/mpc8572ds/tlb.c |2 + board/freescale/p1010rdb/p1010rdb.c |2 + board/freescale/p1_p2_rdb/p1_p2_rdb.c |2 + board/freescale/p1_p2_rdb_pc/law.c| 10 ++- board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c |3 + board/freescale/p2041rdb/eth.c|8 -- board/sbc8548/sbc8548.c |2 - board/sbc8560/sbc8560.c |3 +- drivers/net/fm/fm.c |3 +- drivers/net/tsec.c| 93 + drivers/qe/uec.c |7 -- drivers/usb/host/ehci-fsl.c |4 +- include/config_phylib_all_drivers.h |1 + include/configs/MPC8536DS.h |2 +- include/configs/MPC8548CDS.h |2 + include/configs/MPC8569MDS.h |2 +- include/configs/MPC8572DS.h |2 +- include/configs/P1022DS.h |2 +- include/configs
[U-Boot] [PATCH] powerpc/85xx: Fix NAND SPL support
We cause CCSRBAR to be relocated in the SPL phase of NAND boot which isn't expected and breaks things. Fixing the board config.h to NOT relocate CCSR during the CONFIG_NAND_SPL phase. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- include/configs/MPC8536DS.h|2 +- include/configs/MPC8569MDS.h |2 +- include/configs/MPC8572DS.h|2 +- include/configs/P1_P2_RDB.h|2 +- include/configs/p1_p2_rdb_pc.h |2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h index d4e3ef5..16db98f 100644 --- a/include/configs/MPC8536DS.h +++ b/include/configs/MPC8536DS.h @@ -131,7 +131,7 @@ #define CONFIG_SYS_CCSRBAR 0xffe0 #define CONFIG_SYS_CCSRBAR_PHYS_LOWCONFIG_SYS_CCSRBAR -#if defined(CONFIG_RAMBOOT_NAND) !defined(CONFIG_NAND_SPL) +#if defined(CONFIG_NAND_SPL) #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE #endif diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h index 19d3271..ab27b98 100644 --- a/include/configs/MPC8569MDS.h +++ b/include/configs/MPC8569MDS.h @@ -108,7 +108,7 @@ extern unsigned long get_clock_freq(void); #define CONFIG_SYS_CCSRBAR 0xe000 #define CONFIG_SYS_CCSRBAR_PHYS_LOWCONFIG_SYS_CCSRBAR -#if defined(CONFIG_RAMBOOT_NAND) !defined(CONFIG_NAND_SPL) +#if defined(CONFIG_NAND_SPL) #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE #endif diff --git a/include/configs/MPC8572DS.h b/include/configs/MPC8572DS.h index ffee8fc..d7910e1 100644 --- a/include/configs/MPC8572DS.h +++ b/include/configs/MPC8572DS.h @@ -115,7 +115,7 @@ #define CONFIG_SYS_CCSRBAR 0xffe0 #define CONFIG_SYS_CCSRBAR_PHYS_LOWCONFIG_SYS_CCSRBAR -#if defined(CONFIG_RAMBOOT_NAND) !defined(CONFIG_NAND_SPL) +#if defined(CONFIG_NAND_SPL) #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE #endif diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h index 883d44e..00fa74d 100644 --- a/include/configs/P1_P2_RDB.h +++ b/include/configs/P1_P2_RDB.h @@ -151,7 +151,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_SYS_CCSRBAR 0xffe0 #define CONFIG_SYS_CCSRBAR_PHYS_LOWCONFIG_SYS_CCSRBAR -#if defined(CONFIG_RAMBOOT_NAND) !defined(CONFIG_NAND_SPL) +#if defined(CONFIG_NAND_SPL) #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE #endif diff --git a/include/configs/p1_p2_rdb_pc.h b/include/configs/p1_p2_rdb_pc.h index bcfb034..5a69902 100644 --- a/include/configs/p1_p2_rdb_pc.h +++ b/include/configs/p1_p2_rdb_pc.h @@ -221,7 +221,7 @@ /* IN case of NAND bootloader relocate CCSRBAR in RAMboot code not in the 4k SPL code*/ -#if defined(CONFIG_NAND_U_BOOT) defined(CONFIG_NAND_SPL) +#if defined(CONFIG_NAND_SPL) #define CONFIG_SYS_CCSR_DO_NOT_RELOCATE #endif -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] drivers/block/ahci.c: Fix GCC 4.6 build warning
Fix:
ahci.c: In function 'ata_scsiop_read10':
ahci.c:564:6: warning: variable 'lba' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/block/ahci.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index 015b341..7b2ec50 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -561,12 +561,9 @@ static int ata_scsiop_inquiry(ccb *pccb)
*/
static int ata_scsiop_read10(ccb * pccb)
{
- u64 lba = 0;
u32 len = 0;
u8 fis[20];
- lba = (((u64) pccb-cmd[2]) 24) | (((u64) pccb-cmd[3]) 16)
- | (((u64) pccb-cmd[4]) 8) | ((u64) pccb-cmd[5]);
len = (((u32) pccb-cmd[7]) 8) | ((u32) pccb-cmd[8]);
/* For 10-byte and 16-byte SCSI R/W commands, transfer
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] drivers/bios_emulator/x86emu/ops.c: Fix GCC 4.6 build warning
Fix:
x86emu/ops.c: In function 'x86emuOp_int3':
x86emu/ops.c:3521:9: warning: variable 'tmp' set but not used
[-Wunused-but-set-variable]
x86emu/ops.c: In function 'x86emuOp_int_IMM':
x86emu/ops.c:3549:9: warning: variable 'tmp' set but not used
[-Wunused-but-set-variable]
x86emu/ops.c: In function 'x86emuOp_into':
x86emu/ops.c:3579:9: warning: variable 'tmp' set but not used
[-Wunused-but-set-variable]
x86emu/ops.c: In function 'x86emuOp_aad':
x86emu/ops.c:3993:8: warning: variable 'a' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
drivers/bios_emulator/x86emu/ops.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/bios_emulator/x86emu/ops.c
b/drivers/bios_emulator/x86emu/ops.c
index c836a20..f8e093d 100644
--- a/drivers/bios_emulator/x86emu/ops.c
+++ b/drivers/bios_emulator/x86emu/ops.c
@@ -3518,11 +3518,9 @@ Handles opcode 0xcc
/
void x86emuOp_int3(u8 X86EMU_UNUSED(op1))
{
-u16 tmp;
-
START_OF_INSTR();
DECODE_PRINTF(INT 3\n);
-tmp = (u16) mem_access_word(3 * 4 + 2);
+(void)mem_access_word(3 * 4 + 2);
/* access the segment register */
TRACE_AND_STEP();
if (_X86EMU_intrTab[3]) {
@@ -3546,14 +3544,13 @@ Handles opcode 0xcd
/
void x86emuOp_int_IMM(u8 X86EMU_UNUSED(op1))
{
-u16 tmp;
u8 intnum;
START_OF_INSTR();
DECODE_PRINTF(INT\t);
intnum = fetch_byte_imm();
DECODE_PRINTF2(%x\n, intnum);
-tmp = mem_access_word(intnum * 4 + 2);
+(void)mem_access_word(intnum * 4 + 2);
TRACE_AND_STEP();
if (_X86EMU_intrTab[intnum]) {
(*_X86EMU_intrTab[intnum])(intnum);
@@ -3576,13 +3573,11 @@ Handles opcode 0xce
/
void x86emuOp_into(u8 X86EMU_UNUSED(op1))
{
-u16 tmp;
-
START_OF_INSTR();
DECODE_PRINTF(INTO\n);
TRACE_AND_STEP();
if (ACCESS_FLAG(F_OF)) {
- tmp = mem_access_word(4 * 4 + 2);
+ (void)mem_access_word(4 * 4 + 2);
if (_X86EMU_intrTab[4]) {
(*_X86EMU_intrTab[4])(4);
} else {
@@ -3990,11 +3985,9 @@ Handles opcode 0xd5
/
void x86emuOp_aad(u8 X86EMU_UNUSED(op1))
{
-u8 a;
-
START_OF_INSTR();
DECODE_PRINTF(AAD\n);
-a = fetch_byte_imm();
+(void)fetch_byte_imm();
TRACE_AND_STEP();
M.x86.R_AX = aad_word(M.x86.R_AX);
DECODE_CLEAR_SEGOVR();
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] drivers/block/sata_sil3114.c: Fix GCC 4.6 build warning
Fix: sata_sil3114.c: In function 'scan_sata': sata_sil3114.c:793:7: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:794:7: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:795:39: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:795:7: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:797:7: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:800:7: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:801:7: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:802:39: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:802:7: warning: array subscript is above array bounds [-Warray-bounds] sata_sil3114.c:804:7: warning: array subscript is above array bounds [-Warray-bounds] Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- drivers/block/sata_sil3114.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/block/sata_sil3114.c b/drivers/block/sata_sil3114.c index 1e60636..34fe038 100644 --- a/drivers/block/sata_sil3114.c +++ b/drivers/block/sata_sil3114.c @@ -782,6 +782,7 @@ int scan_sata (int dev) (iobase[5] + VND_TF2_CH0) | ATA_PCI_CTL_OFS; port[0].ioaddr.bmdma_addr = iobase[5] + VND_BMDMA_CH0; break; +#if (CONFIG_SYS_SATA_MAX_DEVICE = 1) case 1: port[1].port_no = 0; port[1].ioaddr.cmd_addr = iobase[5] + VND_TF0_CH1; @@ -789,6 +790,7 @@ int scan_sata (int dev) (iobase[5] + VND_TF2_CH1) | ATA_PCI_CTL_OFS; port[1].ioaddr.bmdma_addr = iobase[5] + VND_BMDMA_CH1; break; +#elif (CONFIG_SYS_SATA_MAX_DEVICE = 2) case 2: port[2].port_no = 0; port[2].ioaddr.cmd_addr = iobase[5] + VND_TF0_CH2; @@ -796,6 +798,7 @@ int scan_sata (int dev) (iobase[5] + VND_TF2_CH2) | ATA_PCI_CTL_OFS; port[2].ioaddr.bmdma_addr = iobase[5] + VND_BMDMA_CH2; break; +#elif (CONFIG_SYS_SATA_MAX_DEVICE = 3) case 3: port[3].port_no = 0; port[3].ioaddr.cmd_addr = iobase[5] + VND_TF0_CH3; @@ -803,6 +806,7 @@ int scan_sata (int dev) (iobase[5] + VND_TF2_CH3) | ATA_PCI_CTL_OFS; port[3].ioaddr.bmdma_addr = iobase[5] + VND_BMDMA_CH3; break; +#endif default: printf (Tried to scan unknown port: ata%d\n, dev); return 1; -- 1.7.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 00/16] Fix GCC 4.6 build warning related to MPC85xx builds
Address 85xx specific gcc 4.6 warnings - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/16] arch/powerpc/cpu/mpc85xx/cpu_init.c: Fix GCC 4.6 build warning
Fix:
cpu_init.c: In function 'cpu_init_r':
cpu_init.c:320:7: warning: variable 'l2srbar' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/cpu/mpc85xx/cpu_init.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 0a4ce53..b9a8193 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -317,7 +317,6 @@ int cpu_init_r(void)
volatile ccsr_l2cache_t *l2cache = (void *)CONFIG_SYS_MPC85xx_L2_ADDR;
volatile uint cache_ctl;
uint svr, ver;
- uint l2srbar;
u32 l2siz_field;
svr = get_svr();
@@ -385,8 +384,8 @@ int cpu_init_r(void)
if (l2cache-l2ctl MPC85xx_L2CTL_L2E) {
puts(already enabled);
- l2srbar = l2cache-l2srbar0;
#if defined(CONFIG_SYS_INIT_L2_ADDR) defined(CONFIG_SYS_FLASH_BASE)
+ u32 l2srbar = l2cache-l2srbar0;
if (l2cache-l2ctl MPC85xx_L2CTL_L2SRAM_ENTIRE
l2srbar = CONFIG_SYS_FLASH_BASE) {
l2srbar = CONFIG_SYS_INIT_L2_ADDR;
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/16] arch/powerpc/cpu/mpc85xx/tlb.c: Fix GCC 4.6 build warning
Fix:
tlb.c: In function 'disable_tlb':
tlb.c:175:34: warning: variable '_mas7' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/cpu/mpc85xx/tlb.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
index 80ad04a..929f6a6 100644
--- a/arch/powerpc/cpu/mpc85xx/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/tlb.c
@@ -172,7 +172,7 @@ void set_tlb(u8 tlb, u32 epn, u64 rpn,
void disable_tlb(u8 esel)
{
- u32 _mas0, _mas1, _mas2, _mas3, _mas7;
+ u32 _mas0, _mas1, _mas2, _mas3;
free_tlb_cam(esel);
@@ -180,14 +180,13 @@ void disable_tlb(u8 esel)
_mas1 = 0;
_mas2 = 0;
_mas3 = 0;
- _mas7 = 0;
mtspr(MAS0, _mas0);
mtspr(MAS1, _mas1);
mtspr(MAS2, _mas2);
mtspr(MAS3, _mas3);
#ifdef CONFIG_ENABLE_36BIT_PHYS
- mtspr(MAS7, _mas7);
+ mtspr(MAS7, 0);
#endif
asm volatile(isync;msync;tlbwe;isync);
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/16] arch/powerpc/cpu/mpc8xxx/fsl_lbc.c: Fix GCC 4.6 build warning
Fix:
fsl_lbc.c: In function 'upmconfig':
fsl_lbc.c:110:9: warning: variable 'mdr' set but not used
[-Wunused-but-set-variable]
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/cpu/mpc8xxx/fsl_lbc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/fsl_lbc.c
b/arch/powerpc/cpu/mpc8xxx/fsl_lbc.c
index d78962f..587576b 100644
--- a/arch/powerpc/cpu/mpc8xxx/fsl_lbc.c
+++ b/arch/powerpc/cpu/mpc8xxx/fsl_lbc.c
@@ -107,7 +107,7 @@ void init_early_memctl_regs(void)
void upmconfig(uint upm, uint *table, uint size)
{
fsl_lbc_t *lbc = LBC_BASE_ADDR;
- int i, mdr, mad, old_mad = 0;
+ int i, mad, old_mad = 0;
u32 mask = (~MxMR_OP_MSK ~MxMR_MAD_MSK);
u32 msel = BR_UPMx_TO_MSEL(upm);
u32 *mxmr = lbc-mamr + upm;
@@ -138,7 +138,7 @@ void upmconfig(uint upm, uint *table, uint size)
for (i = 0; i size; i++) {
out_be32(mxmr, (in_be32(mxmr) mask) | MxMR_OP_WARR | i);
out_be32(lbc-mdr, table[i]);
- mdr = in_be32(lbc-mdr);
+ (void)in_be32(lbc-mdr);
*dummy = 0;
do {
mad = in_be32(mxmr) MxMR_MAD_MSK;
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
