Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi,
In message you
wrote:
...
> >> +/* ranges for parameters:
> >> + * =A0wr_data_delay =3D 0-6
> >> + * =A0clk adjust =3D 0-8
> >> + * =A0cpo 2-0x1E (30)
> >> + */
> >
> > Incorrect multiline comment style.
>
> Sorry, what's wrong with this, specifically? Should it look like this:
>
> /*
> * ranges for parameters:
> * wr_data_delay =3D 0-6
> * clk adjust =3D 0-8
> * cpo 2-0x1E (30)
> */
Yes,indeed. Please see the Coding Style document in case of further
questions.
> > Please use TABs for vertical alignment.
>
> I thought I did.
You did not.
> >> + /* Set pmuxcr to allow both i2c1 and i2c2 */
> >> + setbits_be32(&gur->pmuxcr, 0x1000);
> >> + in_be32(&gur->pmuxcr);
> >
> > What is this in_be32() needed for? Either add a comment why it's
> > needed, or remove it.
>
> Ok. It's for serializing the I/O. The PIXIS won't complete the read
> until after the write is finished.
Please add such a comment, then.
> >> + dram_size = fsl_ddr_sdram();
> >> + dram_size = setup_ddr_tlbs(dram_size / 0x10);
> >> + dram_size *= 0x10;
> >> +
> >> + puts("DDR: ");
> >> + return dram_size;
> >
> > How about using get_ram_size() for autosizing / testing?
>
> That's what fsl_ddr_sdram() does. It returns the size based on SPD.
fsl_ddr_sdram() does NOT the same as get_ram_size(). It does not
perform any actual testing, and will not detect errors in the SPD
information or in the code processing it.
...
> >> + if (!(pordevsr & MPC85xx_PORDEVSR_SGMII2_DIS))
> >> + printf("eTSEC2 is in sgmii mode.\n");
> >> + if (!(pordevsr & MPC85xx_PORDEVSR_SGMII3_DIS))
> >> + printf("eTSEC3 is in sgmii mode.\n");
> >> +
> >> + puts("\n");
> >
> > Drop that.
I should have been more specific here. Hiere, at the first repetition
of this code, I only meant you should drop the ``puts("\n");'' line.
> This code is identical to the code in the p2020ds.c, so I'm just
> mirroring it. The only difference is the names of the slots in the
> printf. I would prefer to keep this new code as close as possible to
> our existing code. I suspect that we'll be unifying the PCI code in
> the future, and keeping it similar will make it easier.
Thanks for pointing this out. so we have even more occurrences of this
block of code - time has come to factor this out into a common
function that is used for this board and for p2020ds as well.
> > Hm... looks as if you were repeating the same code 3 times. Please make
> > this a function.
>
> The code isn't really the same. I would need to pass a lot of
> parameters to this function: the hose, the devdisr mask, the slot
> name, the slot number, the bus number, and so on.
Actually it is not that many arguments.
In any case, there are so many occurrences of this block of code that
it really should be turned into a function.
> >> +#ifdef CONFIG_GET_CLK_FROM_ICS307
> >
> > This CONFIG_GET_CLK_FROM_ICS307 is documented?
>
> We've been using it for years. Now you complain? It's the same code
> in almost all of our recent boards.
Please document it.
> > Please do not use any CamelCase or UPPER CASE identifiers.
>
> Again, this is the same code as always. You've accepted this code a
> dozen times over. Why are you picking on me about it now?
I complain about things when I see them.
Do you really expect me to review all patches submitted on this list
in scrupulous detail? I skim through most of them. I read many of
them more carefully. I try to review as many patches as time permits,
but I never claimed 100% coverage.
Maybe this slept through in the past.
Now it got caught.
It would be nice if you also fixed all the other dozen places where
such code has crept in.
> >> +#ifdef CONFIG_PCIE3
> >> + ft_fsl_pci_setup(blob, "pci2", &pcie3_hose);
> >> +#endif
> >> +#ifdef CONFIG_PCIE2
> >> + ft_fsl_pci_setup(blob, "pci0", &pcie2_hose);
> >> +#endif
> >> +#ifdef CONFIG_PCIE1
> >> + ft_fsl_pci_setup(blob, "pci1", &pcie1_hose);
> >> +#endif
> >
> > Is this intentional? Looks weird to me...
> >
> > PCIE1 => pci1 => pcie1_hose
> > PCIE2 => pci0 => pcie2_hose
> > PCIE3 => pci2 => pcie3_hose
> >
> > Weird, weird...
>
> I asked Kumar about it, but he didn't really have much to say, so I left it.
You mean neither of you knows if this is correct or wrong ???
> >> +++ b/board/freescale/p1022ds/p1022ds_diu.c
> >> @@ -0,0 +1,151 @@
> >
> > This should probably go to drivers/video/ ?
>
> It's p1022-specific, so I don't see why.
No, it's not. It is largely the same as mpc8610hpcd_diu.c; common
video driver code belongs into drivers/video/
> > Hmmm... this looks pretty much similar to
> > board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c;
> >
> > I think you should merge these two into one driver.
>
> And one day I will. But not today. It's going to take me a long time
> to analyze both code and test it on both boards. I can't solve every
> problem at once.
It's only about 200 LOC, and large par
Re: [U-Boot] Flash Erase and Write timeout for S29GL512P
Dear prakash bedge, In message you wrote: > > Flash chip I am using is S29GL512P and as per datasheet flash erase time is > 1024 Seconds and flash program time is 492 Seconds. Be careful. 1024 s is chip erase time, but we use sector erase only, so it's only 3.5 seconds. Same for the 492 s - this is Chip Program Time which does not matter here. > But, in Uboot, I am seeing that most boards have configured > CONFIG_SYS_FLASH_ERASE_TOUT > to 24 ms and CONFIG_SYS_FLASH_WRITE_TOUT to 200-400 ms range for > flash of size 1GB or moroe. > > Can anyone please tell what value I should use for my chip. The CFI driver accesses the flash in sectors only, so sector times apply, not chip times. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Even if you aren't in doubt, consider the mental welfare of the per- son who has to maintain the code after you, and who will probably put parens in the wrong place. - Larry Wall in the perl man page ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Video Driver Support
Hi Stefan, I just want know whether the following GPU is supported by u-boot driver. ATI RADEON E4690(M96). Or Is there any other way to add support for this GPU. I want linux need to be booted on this GPU based Graphics Card. -Thirumalai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Support for MB86R01 cpu
Hi Thirumalai, > Hi Matthias, > >> Hi Thirumalai >> >> Am 18.05.2010 08:29, schrieb Thirumalai: >>> Hi Matthias, >>> I am going to use u-boot alone for my development. Which debugger >>> is >>> suitable for debugging u-boot and initial board bringup activity? >>> My choice is BDI2000. Is it ok. >> >> Yes. As I said. But I never used it to debug u-boot together together >> with GDB. After the serial console was up I used printf-like debugging. >> And before that point I could live quite good with simple BDI commands. >> > > Whether source level debugging is possible with BDI2000? Yes of course this is possible. It's even in the documentation: http://www.denx.de/wiki/view/DULG/DebuggingUBoot Cheers Detlev -- Wenn ein Kopf und ein Buch zusammenstossen und es klingt hohl; ist denn das allemal im Buche? - Lichtenberg -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Watchdog support for ppc4xx
Hi Wolfgang, > Dear Stefan Roese, > > In message <201005201355.01964...@denx.de> you wrote: >> >> > Also I would like to determine in u-boot if a >> > reset was caused by the watchdog timer using the TSR WRS field. If it >> > was reset by the watchdog we will boot into a failsafe partition to >> > protect against system update errors. >> > >> > Has anyone done something like this? >> >> Such a detection is not implemented for PPC4xx. Not sure if it's implemented >> for any other architecture. > > I think lwmon5 performs such checking; eventually this is buryied > somewhere in the POST code. Well, at least I know that for mpc5121 we read the reser status register at boot and copy it to global data (arch/powerpc/cpu/mpc512x/cpu_init.c:64). The value is also output in the U-Boot prompt (arch/powerpc/cpu/mpc512x/cpu.c:68) which is a nice thing IMHO. Checking a "git grep reset_status" one can see that something similar is done for other PowerPC cpus as well, so I'd suggest reusing this method for ppc4xx and providing a mechanism to access this information from a script. Cheers Detlev -- Wenn ein Kopf und ein Buch zusammenstossen und es klingt hohl; ist denn das allemal im Buche? - Lichtenberg -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Convert Makefiles from COBJS-${} to COBJS-$()
Match style we use almost everywhere else
Signed-off-by: Kumar Gala
---
arch/powerpc/cpu/mpc512x/Makefile| 10 +-
board/freescale/common/Makefile | 22 +++---
board/freescale/mpc8610hpcd/Makefile |2 +-
3 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/cpu/mpc512x/Makefile
b/arch/powerpc/cpu/mpc512x/Makefile
index 9cfdb0f..28926e0 100644
--- a/arch/powerpc/cpu/mpc512x/Makefile
+++ b/arch/powerpc/cpu/mpc512x/Makefile
@@ -37,11 +37,11 @@ COBJS-y += interrupts.o
COBJS-y += iopin.o
COBJS-y += serial.o
COBJS-y += speed.o
-COBJS-${CONFIG_FSL_DIU_FB} += diu.o
-COBJS-${CONFIG_FSL_DIU_FB} += ../../../../board/freescale/common/fsl_diu_fb.o
-COBJS-${CONFIG_FSL_DIU_FB} += ../../../../board/freescale/common/fsl_logo_bmp.o
-COBJS-${CONFIG_CMD_IDE} += ide.o
-COBJS-${CONFIG_IIM} += iim.o
+COBJS-$(CONFIG_FSL_DIU_FB) += diu.o
+COBJS-$(CONFIG_FSL_DIU_FB) += ../../../../board/freescale/common/fsl_diu_fb.o
+COBJS-$(CONFIG_FSL_DIU_FB) += ../../../../board/freescale/common/fsl_logo_bmp.o
+COBJS-$(CONFIG_CMD_IDE) += ide.o
+COBJS-$(CONFIG_IIM) += iim.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS := $(COBJS-y)
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 620eb16..df289aa 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -29,18 +29,18 @@ endif
LIB= $(obj)lib$(VENDOR).a
-COBJS-${CONFIG_FSL_CADMUS} += cadmus.o
-COBJS-${CONFIG_FSL_VIA}+= cds_via.o
-COBJS-${CONFIG_FSL_DIU_FB} += fsl_diu_fb.o fsl_logo_bmp.o
-COBJS-${CONFIG_FSL_PIXIS} += pixis.o
-COBJS-${CONFIG_FSL_NGPIXIS}+= ngpixis.o
-COBJS-${CONFIG_PQ_MDS_PIB} += pq-mds-pib.o
-COBJS-${CONFIG_ID_EEPROM} += sys_eeprom.o
-COBJS-${CONFIG_FSL_SGMII_RISER}+= sgmii_riser.o
+COBJS-$(CONFIG_FSL_CADMUS) += cadmus.o
+COBJS-$(CONFIG_FSL_VIA)+= cds_via.o
+COBJS-$(CONFIG_FSL_DIU_FB) += fsl_diu_fb.o fsl_logo_bmp.o
+COBJS-$(CONFIG_FSL_PIXIS) += pixis.o
+COBJS-$(CONFIG_FSL_NGPIXIS)+= ngpixis.o
+COBJS-$(CONFIG_PQ_MDS_PIB) += pq-mds-pib.o
+COBJS-$(CONFIG_ID_EEPROM) += sys_eeprom.o
+COBJS-$(CONFIG_FSL_SGMII_RISER)+= sgmii_riser.o
-COBJS-${CONFIG_MPC8541CDS} += cds_pci_ft.o
-COBJS-${CONFIG_MPC8548CDS} += cds_pci_ft.o
-COBJS-${CONFIG_MPC8555CDS} += cds_pci_ft.o
+COBJS-$(CONFIG_MPC8541CDS) += cds_pci_ft.o
+COBJS-$(CONFIG_MPC8548CDS) += cds_pci_ft.o
+COBJS-$(CONFIG_MPC8555CDS) += cds_pci_ft.o
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
diff --git a/board/freescale/mpc8610hpcd/Makefile
b/board/freescale/mpc8610hpcd/Makefile
index 930a206..847edaf 100644
--- a/board/freescale/mpc8610hpcd/Makefile
+++ b/board/freescale/mpc8610hpcd/Makefile
@@ -27,7 +27,7 @@ COBJS-y += $(BOARD).o
COBJS-$(CONFIG_FSL_DDR2) += ddr.o
COBJS-y+= law.o
-COBJS-${CONFIG_FSL_DIU_FB} += mpc8610hpcd_diu.o
+COBJS-$(CONFIG_FSL_DIU_FB) += mpc8610hpcd_diu.o
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 85xx: Add is_serdes_configured() support for P2020 SERDES
Add the ability to determine if a given IP block connected on SERDES is
configured. This is useful for things like PCIe and SRIO since they are
only ever connected on SERDES.
Signed-off-by: Kumar Gala
---
arch/powerpc/cpu/mpc85xx/Makefile |6 ++-
arch/powerpc/cpu/mpc85xx/p2020_serdes.c | 73 +++
2 files changed, 78 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/cpu/mpc85xx/p2020_serdes.c
diff --git a/arch/powerpc/cpu/mpc85xx/Makefile
b/arch/powerpc/cpu/mpc85xx/Makefile
index f064fee..f1abf0e 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -62,11 +62,15 @@ COBJS-$(CONFIG_PPC_P4080) += ddr-gen3.o
COBJS-$(CONFIG_CPM2) += ether_fcc.o
COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
COBJS-$(CONFIG_MP) += mp.o
-COBJS-$(CONFIG_MPC8536) += mpc8536_serdes.o
COBJS-$(CONFIG_PCI)+= pci.o
COBJS-$(CONFIG_QE) += qe_io.o
COBJS-$(CONFIG_CPM2) += serial_scc.o
+# SERDES support
+COBJS-$(CONFIG_MPC8536) += mpc8536_serdes.o
+COBJS-$(CONFIG_P2010) += p2020_serdes.o
+COBJS-$(CONFIG_P2020) += p2020_serdes.o
+
COBJS = $(COBJS-y)
COBJS += cpu.o
COBJS += cpu_init.o
diff --git a/arch/powerpc/cpu/mpc85xx/p2020_serdes.c
b/arch/powerpc/cpu/mpc85xx/p2020_serdes.c
new file mode 100644
index 000..79fb9bb
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/p2020_serdes.c
@@ -0,0 +1,73 @@
+/*
+ * Copyright 2010 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
+#include
+#include
+#include
+#include
+
+#define SRDS1_MAX_LANES4
+
+static u8 serdes1_cfg_tbl[][SRDS1_MAX_LANES] = {
+ [0x0] = {PCIE1, NONE, NONE, NONE},
+ [0x2] = {PCIE1, PCIE2, PCIE3, PCIE3},
+ [0x4] = {PCIE1, PCIE1, PCIE3, PCIE3},
+ [0x6] = {PCIE1, PCIE1, PCIE1, PCIE1},
+ [0x7] = {SRIO2, SRIO1, NONE, NONE},
+ [0x8] = {SRIO2, SRIO2, SRIO2, SRIO2},
+ [0x9] = {SRIO2, SRIO2, SRIO2, SRIO2},
+ [0xa] = {SRIO2, SRIO2, SRIO2, SRIO2},
+ [0xb] = {SRIO2, SRIO1, SGMII_TSEC2, SGMII_TSEC3},
+ [0xc] = {SRIO2, SRIO1, SGMII_TSEC2, SGMII_TSEC3},
+ [0xd] = {PCIE1, SRIO1, SGMII_TSEC2, SGMII_TSEC3},
+ [0xe] = {PCIE1, PCIE2, SGMII_TSEC2, SGMII_TSEC3},
+ [0xf] = {PCIE1, PCIE1, SGMII_TSEC2, SGMII_TSEC3},
+};
+
+int is_serdes_configured(enum srds_prtcl device)
+{
+ int i;
+ ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ u32 pordevsr = in_be32(&gur->pordevsr);
+ u32 srds1_cfg = (pordevsr & MPC85xx_PORDEVSR_IO_SEL) >>
+ MPC85xx_PORDEVSR_IO_SEL_SHIFT;
+
+ debug("%s: dev = %d\n", __FUNCTION__, device);
+ debug("PORDEVSR[IO_SEL] = %x\n", srds1_cfg);
+
+ if (srds1_cfg > ARRAY_SIZE(serdes1_cfg_tbl)) {
+ printf("Invalid PORDEVSR[IO_SEL] = %d\n", srds1_cfg);
+ return 0;
+ }
+
+ for (i = 0; i < SRDS1_MAX_LANES; i++) {
+ if (serdes1_cfg_tbl[srds1_cfg][i] == device)
+ return 1;
+ }
+
+ return 0;
+}
+
+void fsl_serdes_init(void)
+{
+}
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 85xx/p2020ds: Use is_serdes_configured() to determine of PCIe enabled
The new is_serdes_configured covers a broader range of devices than the
PCI specific code. Use it instead as we convert away from the
is_fsl_pci_cfg() code.
Additionally move to setting LAWs for PCI based on if its configured.
Also updated PCI FDT fixup code to remove PCI controllers from dtb if
they are not configured.
Signed-off-by: Kumar Gala
---
board/freescale/p2020ds/law.c |6 --
board/freescale/p2020ds/p2020ds.c | 27 +++
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/board/freescale/p2020ds/law.c b/board/freescale/p2020ds/law.c
index 28ed2ed..c90c9ae 100644
--- a/board/freescale/p2020ds/law.c
+++ b/board/freescale/p2020ds/law.c
@@ -29,12 +29,6 @@
struct law_entry law_table[] = {
SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_256M, LAW_TRGT_IF_LBC),
- 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),
SET_LAW(PIXIS_BASE_PHYS, LAW_SIZE_4K, LAW_TRGT_IF_LBC),
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
};
diff --git a/board/freescale/p2020ds/p2020ds.c
b/board/freescale/p2020ds/p2020ds.c
index f0ff209..7b76be8 100644
--- a/board/freescale/p2020ds/p2020ds.c
+++ b/board/freescale/p2020ds/p2020ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2007-2009 Freescale Semiconductor, Inc.
+ * Copyright 2007-2010 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -210,9 +211,13 @@ void pci_init_board(void)
puts("\n");
#ifdef CONFIG_PCIE2
- pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_2, io_sel);
+ pcie_configured = is_serdes_configured(PCIE2);
if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE2)) {
+ set_next_law(CONFIG_SYS_PCIE2_MEM_PHYS, LAW_SIZE_512M,
+ LAW_TRGT_IF_PCIE_2);
+ set_next_law(CONFIG_SYS_PCIE2_IO_PHYS, LAW_SIZE_64K,
+ LAW_TRGT_IF_PCIE_2);
SET_STD_PCIE_INFO(pci_info[num], 2);
pcie_ep = fsl_setup_hose(&pcie2_hose, pci_info[num].regs);
printf("PCIE2 connected to ULI as %s (base addr %lx)\n",
@@ -250,9 +255,13 @@ void pci_init_board(void)
#endif
#ifdef CONFIG_PCIE3
- pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_3, io_sel);
+ pcie_configured = is_serdes_configured(PCIE3);
if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE3)) {
+ set_next_law(CONFIG_SYS_PCIE3_MEM_PHYS, LAW_SIZE_512M,
+ LAW_TRGT_IF_PCIE_3);
+ set_next_law(CONFIG_SYS_PCIE3_IO_PHYS, LAW_SIZE_64K,
+ LAW_TRGT_IF_PCIE_3);
SET_STD_PCIE_INFO(pci_info[num], 3);
pcie_ep = fsl_setup_hose(&pcie3_hose, pci_info[num].regs);
printf("PCIE3 connected to Slot 1 as %s (base addr %lx)\n",
@@ -269,9 +278,13 @@ void pci_init_board(void)
#endif
#ifdef CONFIG_PCIE1
- pcie_configured = is_fsl_pci_cfg(LAW_TRGT_IF_PCIE_1, io_sel);
+ pcie_configured = is_serdes_configured(PCIE1);
if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE)) {
+ set_next_law(CONFIG_SYS_PCIE1_MEM_PHYS, LAW_SIZE_512M,
+ LAW_TRGT_IF_PCIE_1);
+ set_next_law(CONFIG_SYS_PCIE1_IO_PHYS, LAW_SIZE_64K,
+ LAW_TRGT_IF_PCIE_1);
SET_STD_PCIE_INFO(pci_info[num], 1);
pcie_ep = fsl_setup_hose(&pcie1_hose, pci_info[num].regs);
printf("PCIE1 connected to Slot 2 as %s (base addr %lx)\n",
@@ -517,12 +530,18 @@ void ft_board_setup(void *blob, bd_t *bd)
#ifdef CONFIG_PCIE3
ft_fsl_pci_setup(blob, "pci0", &pcie3_hose);
+#else
+ ft_fsl_pci_setup(blob, "pci0", NULL);
#endif
#ifdef CONFIG_PCIE2
ft_fsl_pci_setup(blob, "pci1", &pcie2_hose);
+#else
+ ft_fsl_pci_setup(blob, "pci1", NULL);
#endif
#ifdef CONFIG_PCIE1
ft_fsl_pci_setup(blob, "pci2", &pcie1_hose);
+#else
+ ft_fsl_pci_setup(blob, "pci2", NULL);
#endif
#ifdef CONFIG_FSL_SGMII_RISER
fsl_sgmii_riser_fdt_fixup(blob);
--
1.6.0.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc/85xx: Convert MPC8572DS to using board common ICS307 code
Signed-off-by: Kumar Gala
---
board/freescale/common/Makefile |1 +
board/freescale/mpc8572ds/mpc8572ds.c | 145 +
include/configs/MPC8572DS.h | 14 +--
3 files changed, 7 insertions(+), 153 deletions(-)
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index d18445b..3498638 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_MPC8541CDS)+= cds_pci_ft.o
COBJS-$(CONFIG_MPC8548CDS) += cds_pci_ft.o
COBJS-$(CONFIG_MPC8555CDS) += cds_pci_ft.o
+COBJS-$(CONFIG_MPC8572DS) += ics307_clk.o
COBJS-$(CONFIG_P2020DS)+= ics307_clk.o
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
diff --git a/board/freescale/mpc8572ds/mpc8572ds.c
b/board/freescale/mpc8572ds/mpc8572ds.c
index 6029a51..81d481a 100644
--- a/board/freescale/mpc8572ds/mpc8572ds.c
+++ b/board/freescale/mpc8572ds/mpc8572ds.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2007-2009 Freescale Semiconductor, Inc.
+ * Copyright 2007-2010 Freescale Semiconductor, Inc.
*
* See file CREDITS for list of people who contributed to this
* project.
@@ -284,149 +284,6 @@ int board_early_init_r(void)
return 0;
}
-#ifdef CONFIG_GET_CLK_FROM_ICS307
-/* decode S[0-2] to Output Divider (OD) */
-static unsigned char ics307_S_to_OD[] = {
- 10, 2, 8, 4, 5, 7, 3, 6
-};
-
-/* Calculate frequency being generated by ICS307-02 clock chip based upon
- * the control bytes being programmed into it. */
-/* XXX: This function should probably go into a common library */
-static unsigned long
-ics307_clk_freq (unsigned char cw0, unsigned char cw1, unsigned char cw2)
-{
- const unsigned long InputFrequency = CONFIG_ICS307_REFCLK_HZ;
- unsigned long VDW = ((cw1 << 1) & 0x1FE) + ((cw2 >> 7) & 1);
- unsigned long RDW = cw2 & 0x7F;
- unsigned long OD = ics307_S_to_OD[cw0 & 0x7];
- unsigned long freq;
-
- /* CLK1Frequency = InputFrequency * 2 * (VDW + 8) / ((RDW + 2) * OD) */
-
- /* cw0: C1 C0 TTL F1 F0 S2 S1 S0
-* cw1: V8 V7 V6 V5 V4 V3 V2 V1
-* cw2: V0 R6 R5 R4 R3 R2 R1 R0
-*
-* R6:R0 = Reference Divider Word (RDW)
-* V8:V0 = VCO Divider Word (VDW)
-* S2:S0 = Output Divider Select (OD)
-* F1:F0 = Function of CLK2 Output
-* TTL = duty cycle
-* C1:C0 = internal load capacitance for cyrstal
-*/
-
- /* Adding 1 to get a "nicely" rounded number, but this needs
-* more tweaking to get a "properly" rounded number. */
-
- freq = 1 + (InputFrequency * 2 * (VDW + 8) / ((RDW + 2) * OD));
-
- debug("ICS307: CW[0-2]: %02X %02X %02X => %u Hz\n", cw0, cw1, cw2,
- freq);
- return freq;
-}
-
-unsigned long get_board_sys_clk(ulong dummy)
-{
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- return ics307_clk_freq (
- in_8(pixis_base + PIXIS_VSYSCLK0),
- in_8(pixis_base + PIXIS_VSYSCLK1),
- in_8(pixis_base + PIXIS_VSYSCLK2)
- );
-}
-
-unsigned long get_board_ddr_clk(ulong dummy)
-{
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- return ics307_clk_freq (
- in_8(pixis_base + PIXIS_VDDRCLK0),
- in_8(pixis_base + PIXIS_VDDRCLK1),
- in_8(pixis_base + PIXIS_VDDRCLK2)
- );
-}
-#else
-unsigned long get_board_sys_clk(ulong dummy)
-{
- u8 i;
- ulong val = 0;
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- i = in_8(pixis_base + PIXIS_SPD);
- i &= 0x07;
-
- switch (i) {
- case 0:
- val = ;
- break;
- case 1:
- val = 4000;
- break;
- case 2:
- val = 5000;
- break;
- case 3:
- val = ;
- break;
- case 4:
- val = 8333;
- break;
- case 5:
- val = 1;
- break;
- case 6:
- val = 1;
- break;
- case 7:
- val = 1;
- break;
- }
-
- return val;
-}
-
-unsigned long get_board_ddr_clk(ulong dummy)
-{
- u8 i;
- ulong val = 0;
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- i = in_8(pixis_base + PIXIS_SPD);
- i &= 0x38;
- i >>= 3;
-
- switch (i) {
- case 0:
- val = ;
- break;
- case 1:
- val = 4000;
- break;
- case 2:
- val = 5000;
-
[U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
We have several boards that use the same ICS307 CLK chip to drive the
System clock and DDR clock. Move the code into a common location so we
share it.
Convert the P2020DS board as the first to use the new common ICS307
code.
Signed-off-by: Kumar Gala
---
board/freescale/common/Makefile |1 +
board/freescale/common/ics307_clk.c | 101 +++
board/freescale/common/ics307_clk.h | 30 +++
board/freescale/p2020ds/p2020ds.c | 149 ---
include/configs/P2020DS.h | 16 +---
5 files changed, 137 insertions(+), 160 deletions(-)
create mode 100644 board/freescale/common/ics307_clk.c
create mode 100644 board/freescale/common/ics307_clk.h
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index df289aa..d18445b 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_MPC8541CDS)+= cds_pci_ft.o
COBJS-$(CONFIG_MPC8548CDS) += cds_pci_ft.o
COBJS-$(CONFIG_MPC8555CDS) += cds_pci_ft.o
+COBJS-$(CONFIG_P2020DS)+= ics307_clk.o
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS-y))
diff --git a/board/freescale/common/ics307_clk.c
b/board/freescale/common/ics307_clk.c
new file mode 100644
index 000..1090848
--- /dev/null
+++ b/board/freescale/common/ics307_clk.c
@@ -0,0 +1,101 @@
+/*
+ * Copyright 2010 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
+#include
+
+#include "ics307_clk.h"
+
+#ifdef CONFIG_FSL_NGPIXIS
+#include "ngpixis.h"
+#define PIXIS_VSYSCLK0 offsetof(struct ngpixis, sclk[0])
+#define PIXIS_VSYSCLK1 offsetof(struct ngpixis, sclk[1])
+#define PIXIS_VSYSCLK2 offsetof(struct ngpixis, sclk[2])
+#define PIXIS_VDDRCLK0 offsetof(struct ngpixis, dclk[0])
+#define PIXIS_VDDRCLK1 offsetof(struct ngpixis, dclk[1])
+#define PIXIS_VDDRCLK2 offsetof(struct ngpixis, dclk[2])
+#endif
+
+/* decode S[0-2] to Output Divider (OD) */
+static unsigned char ics307_s_to_od[] = {
+ 10, 2, 8, 4, 5, 7, 3, 6
+};
+
+/*
+ * Calculate frequency being generated by ICS307-02 clock chip based upon
+ * the control bytes being programmed into it.
+ */
+static unsigned long
+ics307_clk_freq(unsigned char cw0, unsigned char cw1, unsigned char cw2)
+{
+ const unsigned long input_freq = CONFIG_ICS307_REFCLK_HZ;
+ unsigned long VDW = ((cw1 << 1) & 0x1FE) + ((cw2 >> 7) & 1);
+ unsigned long RDW = cw2 & 0x7F;
+ unsigned long OD = ics307_s_to_od[cw0 & 0x7];
+ unsigned long freq;
+
+ /*
+* CLK1 Freq = Input Frequency * 2 * (VDW + 8) / ((RDW + 2) * OD)
+*
+* cw0: C1 C0 TTL F1 F0 S2 S1 S0
+* cw1: V8 V7 V6 V5 V4 V3 V2 V1
+* cw2: V0 R6 R5 R4 R3 R2 R1 R0
+*
+* R6:R0 = Reference Divider Word (RDW)
+* V8:V0 = VCO Divider Word (VDW)
+* S2:S0 = Output Divider Select (OD)
+* F1:F0 = Function of CLK2 Output
+* TTL = duty cycle
+* C1:C0 = internal load capacitance for cyrstal
+*
+* Adding 1 to get a "nicely" rounded number, but this needs
+* more tweaking to get a "properly" rounded number.
+*/
+
+ freq = 1 + (input_freq * 2 * (VDW + 8) / ((RDW + 2) * OD));
+
+ debug("ICS307: CW[0-2]: %02X %02X %02X => %lu Hz\n", cw0, cw1, cw2,
+ freq);
+ return freq;
+}
+
+unsigned long get_board_sys_clk(void)
+{
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
+
+ return ics307_clk_freq (
+ in_8(pixis_base + PIXIS_VSYSCLK0),
+ in_8(pixis_base + PIXIS_VSYSCLK1),
+ in_8(pixis_base + PIXIS_VSYSCLK2)
+ );
+}
+
+unsigned long get_board_ddr_clk(void)
+{
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
+
+ return ics307_clk_freq (
+ in_8(pixis_base + PIXIS_VDDRCLK0),
+ in_8(pixis_base + PIXIS_VDDRCLK1),
+ in_8(pixis_base + PIXIS_VDDRCLK2)
+ );
+}
diff --git a/board/freescale/common/ics307_clk.h
b/board/freescale/common/ics307_
[U-Boot] [PATCH] ppc/85xx: Convert MPC8536DS to using board common ICS307 code
Signed-off-by: Kumar Gala
---
board/freescale/common/Makefile |1 +
board/freescale/mpc8536ds/mpc8536ds.c | 148 -
include/configs/MPC8536DS.h | 14 +--
3 files changed, 6 insertions(+), 157 deletions(-)
diff --git a/board/freescale/common/Makefile b/board/freescale/common/Makefile
index 3498638..bd6a09d 100644
--- a/board/freescale/common/Makefile
+++ b/board/freescale/common/Makefile
@@ -42,6 +42,7 @@ COBJS-$(CONFIG_MPC8541CDS)+= cds_pci_ft.o
COBJS-$(CONFIG_MPC8548CDS) += cds_pci_ft.o
COBJS-$(CONFIG_MPC8555CDS) += cds_pci_ft.o
+COBJS-$(CONFIG_MPC8536DS) += ics307_clk.o
COBJS-$(CONFIG_MPC8572DS) += ics307_clk.o
COBJS-$(CONFIG_P2020DS)+= ics307_clk.o
diff --git a/board/freescale/mpc8536ds/mpc8536ds.c
b/board/freescale/mpc8536ds/mpc8536ds.c
index 1968106..50ca3ca 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -350,154 +350,6 @@ int board_early_init_r(void)
return 0;
}
-#ifdef CONFIG_GET_CLK_FROM_ICS307
-/* decode S[0-2] to Output Divider (OD) */
-static unsigned char
-ics307_S_to_OD[] = {
- 10, 2, 8, 4, 5, 7, 3, 6
-};
-
-/* Calculate frequency being generated by ICS307-02 clock chip based upon
- * the control bytes being programmed into it. */
-/* XXX: This function should probably go into a common library */
-static unsigned long
-ics307_clk_freq (unsigned char cw0, unsigned char cw1, unsigned char cw2)
-{
- const unsigned long long InputFrequency = CONFIG_ICS307_REFCLK_HZ;
- unsigned long VDW = ((cw1 << 1) & 0x1FE) + ((cw2 >> 7) & 1);
- unsigned long RDW = cw2 & 0x7F;
- unsigned long OD = ics307_S_to_OD[cw0 & 0x7];
- unsigned long freq;
-
- /* CLK1Frequency = InputFrequency * 2 * (VDW + 8) / ((RDW + 2) * OD) */
-
- /* cw0: C1 C0 TTL F1 F0 S2 S1 S0
-* cw1: V8 V7 V6 V5 V4 V3 V2 V1
-* cw2: V0 R6 R5 R4 R3 R2 R1 R0
-*
-* R6:R0 = Reference Divider Word (RDW)
-* V8:V0 = VCO Divider Word (VDW)
-* S2:S0 = Output Divider Select (OD)
-* F1:F0 = Function of CLK2 Output
-* TTL = duty cycle
-* C1:C0 = internal load capacitance for cyrstal
-*/
-
- /* Adding 1 to get a "nicely" rounded number, but this needs
-* more tweaking to get a "properly" rounded number. */
-
- freq = 1 + (InputFrequency * 2 * (VDW + 8) / ((RDW + 2) * OD));
-
- debug("ICS307: CW[0-2]: %02X %02X %02X => %u Hz\n", cw0, cw1, cw2,
- freq);
- return freq;
-}
-
-unsigned long
-get_board_sys_clk(ulong dummy)
-{
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- return ics307_clk_freq (
- in_8(pixis_base + PIXIS_VSYSCLK0),
- in_8(pixis_base + PIXIS_VSYSCLK1),
- in_8(pixis_base + PIXIS_VSYSCLK2)
- );
-}
-
-unsigned long
-get_board_ddr_clk(ulong dummy)
-{
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- return ics307_clk_freq (
- in_8(pixis_base + PIXIS_VDDRCLK0),
- in_8(pixis_base + PIXIS_VDDRCLK1),
- in_8(pixis_base + PIXIS_VDDRCLK2)
- );
-}
-#else
-unsigned long
-get_board_sys_clk(ulong dummy)
-{
- u8 i;
- ulong val = 0;
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- i = in_8(pixis_base + PIXIS_SPD);
- i &= 0x07;
-
- switch (i) {
- case 0:
- val = ;
- break;
- case 1:
- val = 4000;
- break;
- case 2:
- val = 5000;
- break;
- case 3:
- val = ;
- break;
- case 4:
- val = 8333;
- break;
- case 5:
- val = 1;
- break;
- case 6:
- val = 1;
- break;
- case 7:
- val = 1;
- break;
- }
-
- return val;
-}
-
-unsigned long
-get_board_ddr_clk(ulong dummy)
-{
- u8 i;
- ulong val = 0;
- u8 *pixis_base = (u8 *)PIXIS_BASE;
-
- i = in_8(pixis_base + PIXIS_SPD);
- i &= 0x38;
- i >>= 3;
-
- switch (i) {
- case 0:
- val = ;
- break;
- case 1:
- val = 4000;
- break;
- case 2:
- val = 5000;
- break;
- case 3:
- val = ;
- break;
- case 4:
- val = 8333;
- break;
- case 5:
- val = 1;
- break;
- case 6:
- val = 1;
- break;
- case 7:
- val = 1;
- break;
- }
- return val;
-}
-#endif
-
int board_eth_init(bd_t *bis)
{
#ifdef CONFIG_TSEC_ENET
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index da4313a..c52b605 10064
Re: [U-Boot] [PATCH v2] fsl/85xx: add clkdvdr and pmuxcr2 to global utilities structure definition
On May 20, 2010, at 12:45 PM, Timur Tabi wrote: > Add the 'clkdvdr' and 'pmuxcr2' registers to the 85xx definition of > struct ccsr_gur. > > Signed-off-by: Timur Tabi > --- > > This patch replaces "fsl/85xx: add clkdvdr to global utilities structure > definition". > Thanks to Sergei Shtylyov. > > arch/powerpc/include/asm/immap_85xx.h |9 ++--- > 1 files changed, 6 insertions(+), 3 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] fsl: rename 'dma' to 'brdcfg1' in the ngPIXIS structure
On May 20, 2010, at 11:16 AM, Timur Tabi wrote: > The ngPIXIS is a board-specific FPGA, but the definition of the registers > is mostly consistent. On boards where it matter, register 9 is called > 'brdcfg1' instead of 'dma', so rename the variable in the ngpixis_t > definition. > > Signed-off-by: Timur Tabi > --- > board/freescale/common/ngpixis.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
[U-Boot] Rusya Kargolarınızın Kapasites i ne olursa olsun.Biz Adresinizden Alıp Müşter inizin Adresine Kadar Teslim Garantisi ile Taşıyoruz .
MPS Express - RUSYA gönderilerini kabul etmeye devam edeceğini açıkladı Rusya Merkezli MPS Express & Logistics firması müşterilerine Rusya Gümrüğündeki uygulamalar sebebiyle sorun yaşayan özel\şahış veya kurumlar için gümrüklü yada gümrüksüz tüm Rusya Kargolarını paketlerini almaya devam ederek bir ilke imza atmaya devam ediyor.. Aşağıda MPS EXPRESS firmasının müşterilerine göndermiş olduğu bilgilendirme yazısını yayınlıyoruz. Degerli Müsterimiz, Rusya Federasyonu tarafindan bir süredir uygulanmakta olan gümrük prosedürleri nedeniyle, alicisi özel sahis olan gönderiler Rusya gümrüklerinde bekletilmekte ve gönderildigi ülkelere iade edilmektedir. Bu uygulama, doküman gönderileri haricindeki alicisi özel sahis olan tüm numune / paket gönderilerini kapsamaktadir. MPS Sadece Rusya da kayitli, ithalat izni bulunan Rus firmalari, gerekli prosedürleri yerine İSTER GETİRSİN İSTER GETİRMESİN Tüm gönderilerini gümrükten çekebiliyor ve Türkiyeden teslim aliyor. Rusya Gümrügündeki bu uygulamadan müsterilerimizin etkilenmemesi için sadece alicisi özel sahis olan numune / paket Rusya gönderilerini şirket olarak kabul edebiliyoruz. Tüm evrak/doküman ve Rus firmalarina yapacaginiz numune / paket ihracat ve ağır kargolarınıza hizmetimiz ayni sekilde devam etmektedir. Gönderilerinizde bizi tercih ettiginiz icin tesekkür eder, iyi isbirligimizin artarak devamini dileriz. Saygilarimizla, MPS EXPRESS & LOGİSTİC'S TÜRKİYE 90 212 444 0 108 Not .:Fiyat Sorgulamak ve talepleriniz için Aşaği mail adreslerinden talepte bulunmanız önemle rica olunur. Rusya Hava Kargo ve Karayolu Parsiyel İçin .:Hasan ÜNALDI hasan.una...@inter-mex.com Avrupa ve Ortadoğu Kargolarınız için.:Nermin DURMAZ nermin.dur...@inter-mex.com İhracat Kargolarınız için.:İbrahim ÜNALDI ibrahim.una...@inter-mex.com __ ESET NOD32 Antivirus Ak�ll� G�venlik taraf�ndan sa�lanan bilgiler, vir�s imza veritaban� s�r�m�: 5093 (20100506) __ �leti ESET NOD32 Antivirus Ak�ll� G�venlik taraf�ndan denetlendi. http://www.nod32.com.tr ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
On May 20, 2010, at 5:01 PM, Timur Tabi wrote:
> diff --git a/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
> b/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
> index 85995ca..fc79fe1 100644
> --- a/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
> +++ b/arch/powerpc/cpu/mpc8xxx/pci_cfg.c
> @@ -186,6 +186,32 @@ static struct pci_info pci_config_info[] =
>(1 << 0x16) | (1 << 0x17) | (1 << 0x18) | (1 << 0x1c),
> },
> };
> +#elif defined(CONFIG_P1022)
> +static struct pci_info pci_config_info[] =
> +{
> + [LAW_TRGT_IF_PCIE_1] = {
> + .agent = (1 << 0) | (1 << 1),
> + .cfg = (1 << 6) | (1 << 7) | (1 << 9) | (1 << 0xa) |
> + (1 << 0xb) | (1 << 0xd) | (1 << 0xe) |
> + (1 << 0xf) | (1 << 0x15) | (1 << 0x16) |
> + (1 << 0x17) | (1 << 0x18) | (1 << 0x19) |
> + (1 << 0x1a) | (1 << 0x1b) | (1 << 0x1c) |
> + (1 << 0x1d) | (1 << 0x1e) | (1 << 0x1f),
> + },
> + [LAW_TRGT_IF_PCIE_2] = {
> + .agent = (1 << 0) | (1 << 2),
> + .cfg = (1 << 0) | (1 << 1) | (1 << 6) | (1 << 7) |
> + (1 << 9) | (1 << 0xa) | (1 << 0xb) | (1 << 0xd) |
> + (1 << 0x15) | (1 << 0x16) | (1 << 0x17) |
> + (1 << 0x18) | (1 << 0x1c),
> + },
> + [LAW_TRGT_IF_PCIE_3] = {
> + .agent = (1 << 0) | (1 << 3),
> + .cfg = (1 << 6) | (1 << 7) | (1 << 9) | (1 << 0xd) |
> + (1 << 0x15) | (1 << 0x16) | (1 << 0x17) | (1 << 0x18) |
> + (1 << 0x19) | (1 << 0x1a) | (1 << 0x1b),
> + },
> +};
> #elif defined(CONFIG_P2010) || defined(CONFIG_P2020)
> static struct pci_info pci_config_info[] =
> {
This is the old style that we want to move away from. I posted patches for the
P2020 DS.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tools: set multiple variable with fw_setenv utility
Add a sort of batch mode to fw_setenv, allowing to set
multiple variables in one shot, without updating the flash after
each set as now. It is added the possibility to pass
a config file with a list of pairs to be set,
separated by a TAB character.
Signed-off-by: Stefano Babic
---
tools/env/fw_env.c | 216 +++
tools/env/fw_env.h |7 ++
tools/env/fw_env_main.c | 32 +++-
3 files changed, 218 insertions(+), 37 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index a46205d..506a806 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -45,9 +45,6 @@
#include "fw_env.h"
-#defineCMD_GETENV "fw_printenv"
-#defineCMD_SETENV "fw_setenv"
-
#define min(x, y) ({ \
typeof(x) _min1 = (x); \
typeof(y) _min2 = (y); \
@@ -328,29 +325,15 @@ int fw_printenv (int argc, char *argv[])
}
/*
- * Deletes or sets environment variables. Returns -1 and sets errno error
codes:
- * 0 - OK
- * EINVAL - need at least 1 argument
- * EROFS - certain variables ("ethaddr", "serial#") cannot be
- * modified or deleted
- *
+ * Set/Clear a single variable in the environment.
+ * This is called in sequence to update the environment
+ * in RAM without updating the copy in flash after each set
*/
-int fw_setenv (int argc, char *argv[])
+int fw_set_single_var(char *name, char *value)
{
- int i, len;
+ int len;
char *env, *nxt;
char *oldval = NULL;
- char *name;
-
- if (argc < 2) {
- errno = EINVAL;
- return -1;
- }
-
- if (env_init ())
- return -1;
-
- name = argv[1];
/*
* search if variable with this name already exists
@@ -358,7 +341,7 @@ int fw_setenv (int argc, char *argv[])
for (nxt = env = environment.data; *env; env = nxt + 1) {
for (nxt = env; *nxt; ++nxt) {
if (nxt >= &environment.data[ENV_SIZE]) {
- fprintf (stderr, "## Error: "
+ fprintf(stderr, "## Error: "
"environment not terminated\n");
errno = EINVAL;
return -1;
@@ -396,8 +379,8 @@ int fw_setenv (int argc, char *argv[])
}
/* Delete only ? */
- if (argc < 3)
- goto WRITE_FLASH;
+ if (!value || !strlen(value))
+ return 0;
/*
* Append new definition at the end
@@ -411,41 +394,204 @@ int fw_setenv (int argc, char *argv[])
*/
len = strlen (name) + 2;
/* add '=' for first arg, ' ' for all others */
- for (i = 2; i < argc; ++i) {
- len += strlen (argv[i]) + 1;
- }
+ len += strlen(value) + 1;
+
if (len > (&environment.data[ENV_SIZE] - env)) {
fprintf (stderr,
"Error: environment overflow, \"%s\" deleted\n",
name);
return -1;
}
+
while ((*env = *name++) != '\0')
env++;
+ *env = '=';
+ while ((*++env = *value++) != '\0')
+ ;
+
+ /* end is marked with double '\0' */
+ *++env = '\0';
+
+ return 0;
+}
+
+/*
+ * Deletes or sets environment variables. Returns -1 and sets errno error
codes:
+ * 0 - OK
+ * EINVAL - need at least 1 argument
+ * EROFS - certain variables ("ethaddr", "serial#") cannot be
+ * modified or deleted
+ *
+ */
+int fw_setenv(int argc, char *argv[])
+{
+ int i, len;
+ char *env;
+ char *name;
+ char *value = NULL;
+ char *tmpval = NULL;
+
+ if (argc < 2) {
+ errno = EINVAL;
+ return -1;
+ }
+
+ if (env_init())
+ return -1;
+
+ name = argv[1];
+
+ /*
+* Overflow when:
+* "name" + "=" + "val" +"\0\0" > CONFIG_ENV_SIZE - (env-environment)
+*/
+ len = strlen(name) + 2;
+ /* add '=' for first arg, ' ' for all others */
+ for (i = 2; i < argc; ++i)
+ len += strlen(argv[i]) + 1;
+
+ if (len > (&environment.data[ENV_SIZE] - env)) {
+ fprintf(stderr,
+ "Error: environment overflow, \"%s\" deleted\n",
+ name);
+ return -1;
+ }
+
+ /* Allocate enough place to the data string */
for (i = 2; i < argc; ++i) {
char *val = argv[i];
+ if (!value) {
+ value = (char *)malloc(len - strlen(name));
+ memset(value, 0, len - strlen(name));
+ tmpval = value;
+ }
+ if (i != 2)
+ *tmpval++ = ' ';
+ while (*val != '\0')
+ *t
Re: [U-Boot] [PATCH] Tools: set multiple variable with fw_setenv utility
Dear Stefano Babic,
In message <1274439131-22807-1-git-send-email-sba...@denx.de> you wrote:
> Add a sort of batch mode to fw_setenv, allowing to set
> multiple variables in one shot, without updating the flash after
> each set as now. It is added the possibility to pass
Thanks; that's a welcome improvement!
> a config file with a list of pairs to be set,
> separated by a TAB character.
I think we should be less restrictive here. Please split at the first
white space, and allow for multiple white spaces.
> + /* Allocate enough place to the data string */
> for (i = 2; i < argc; ++i) {
> char *val = argv[i];
> + if (!value) {
> + value = (char *)malloc(len - strlen(name));
> + memset(value, 0, len - strlen(name));
Kaboom! when malloc() fails.
> + tmpval = value;
> + }
> + if (i != 2)
> + *tmpval++ = ' ';
> + while (*val != '\0')
> + *tmpval++ = *val++;
> + }
> +
> + fw_set_single_var(name, value);
Silent corruption of environment when malloc() failed.
> + /*
> + * Update CRC
> + */
> + *environment.crc = crc32(0, (uint8_t *) environment.data, ENV_SIZE);
> +
> + /* write environment back to flash */
> + if (flash_io(O_RDWR)) {
> + fprintf(stderr, "Error: can't write fw_env to flash\n");
> + return -1;
...
> /*
>* Update CRC
>*/
> - *environment.crc = crc32 (0, (uint8_t *) environment.data, ENV_SIZE);
> + *environment.crc = crc32(0, (uint8_t *) environment.data, ENV_SIZE);
>
> /* write environment back to flash */
> - if (flash_io (O_RDWR)) {
> + if (flash_io(O_RDWR)) {
> fprintf (stderr, "Error: can't write fw_env to flash\n");
> return -1;
We probably should not repeat this code, but factor it out.
> +/*
> + * Parse script to generate list of variables to set
> + * The script file has a very simple format, as follows:
> + *
> + * Each line has a couple with name, value:
> + * variable_namevariable_value
Please make this:
namevalue
> + * Both variable_name and variable_value are interpreted as strings.
> + * Any character after and before ending \r\n is interpreted
> + * as variable's value (no comment allowed on these lines !)
> + *
> + * Comments are allowed if the first character in the line is #
> + *
> + * Returns -1 and sets errno error codes:
> + * 0 - OK
> + * -1 - Error
> + */
> +int fw_parse_script(char *fname, fw_env_list *list, int count)
> +{
> + FILE *fp;
> + int i = 0;
> + char dump[128];
Ouch! That's short! Why do we need such an arbitrary limit?
> + fp = fopen(fname, "r");
> + if (fp == NULL)
> + return -1;
How about a useful error message?
> + while (fgets(dump, sizeof(dump), fp)) {
> + /* Skip incomplete conversions and comment strings */
> + if (dump[0] == '#')
> + continue;
What are incomplete conversions, and where do they get skipped? And
what happens with the rest of the input?
> + list[i].name[0] = '\0';
> + list[i].value[0] = '\0';
> +
> + val = strtok(dump, "\r\n");
> + if (!val)
> + continue;
> +
> + name = strtok(dump, "\t");
> + if (!name)
> + continue;
> +
> + strncpy(list[i].name, name, sizeof(list[i].name) - 1);
Error message for too long names?
> + val = strtok(NULL, "\t");
> + if (val)
> + strncpy(list[i].value, val, sizeof(list[i].value) - 1);
Error message for too long values?
Hm... Isn't strtok() a bit of overkill here, when all we want to do is
split at the first white space?
> +typedef struct {
> + char name[255];
> + char value[255];
> +} fw_env_list;
Again we have arbitrary limits. And even different ones from the one
above (128).
> +static struct option long_options[] = {
> + {"script", required_argument, NULL, 's'},
> + {NULL, 0, NULL, 0}
> +};
The command should also accept '-' as file name, and then read from
stdin.
> + if (!script_file) {
> + if (fw_setenv(argc, argv) != 0)
> + return EXIT_FAILURE;
> + } else {
> + list = (fw_env_list *)malloc(MAX_SET_VARS *
> + sizeof(fw_env_list));
> + count = fw_parse_script(script_file,
> + list, MAX_SET_VARS);
Kaboom! when malloc() failed.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"In matrimony, to hesitate is sometimes to be saved."
[U-Boot] NAND write issue is DM355
Hi all, I am porting u-boot to TI DM355 based board. When I write to nand using nand write command upto offset of 0x6 it is working fine. but If I write above 0x7 it is writing to 0x0 address. Can some one give me suggestion how to correct this issue. NAND size 64M -- Best Regards, Mohamed Thalib H ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Add is_serdes_configured() support for P2020SERDES
On 5/21/2010 5:17 PM, Kumar Gala wrote:
>
>Add the ability to determine if a given IP block connected on SERDES is
>configured. This is useful for things like PCIe and SRIO since they are
>only ever connected on SERDES.
>
>Signed-off-by: Kumar Gala mailto:ga...@kernel.crashing.org>>
I'm not sure why this code has to be re-done rather than using the patch
I submitted?
{snip}
>+int is_serdes_configured(enum srds_prtcl device) {
>+ int i;
>+ ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
>+ u32 pordevsr = in_be32(&gur->pordevsr);
Wouldn't it be better to only read it once on fsl_serdes_init(), after
all it will not be changed after reset.
>+ u32 srds1_cfg = (pordevsr & MPC85xx_PORDEVSR_IO_SEL) >>
>+ MPC85xx_PORDEVSR_IO_SEL_SHIFT;
>+
>+ debug("%s: dev = %d\n", __FUNCTION__, device);
>+ debug("PORDEVSR[IO_SEL] = %x\n", srds1_cfg);
>+
>+ if (srds1_cfg > ARRAY_SIZE(serdes1_cfg_tbl)) {
>+ printf("Invalid PORDEVSR[IO_SEL] = %d\n", srds1_cfg);
>+ return 0;
>+ }
>+
>+ for (i = 0; i < SRDS1_MAX_LANES; i++) {
>+ if (serdes1_cfg_tbl[srds1_cfg][i] == device)
>+ return 1;
Given the fact that the is_serdes_configured() will be called multiple
times, it will be better to process the table in fsl_serdes_init() and
save time for every is_serdes_configured() judgment like what I did.
- Leo
>+ }
>+
>+ return 0;
>+}
>+
>+void fsl_serdes_init(void)
>+{
>+}
>--
>1.6.0.6
>
>___
>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] Improve DaVinci SPI speed
Hello Sekhar,
I resubmitted the patch a few days ago (13th of May) with the changes you
requested. Please ack it, so it can be applied.
Thanks
--
Delio
On 18/05/2010, at 14:25, Nori, Sekhar wrote:
> On Thu, May 13, 2010 at 18:27:51, Delio Brignoli wrote:
>> Reduce the number of reads per byte transferred on the BUF register from 2
>> to 1 and
>> take advantage of the TX buffer in the SPI module.
>
> The patch looks good to me.
>
> Can you please publish some sort of numbers in the
> patch description indicating the performance improvement
> achieved?
>
> A minor nit below:
>
>>
>> Signed-off-by: Delio Brignoli
>> ---
>> drivers/spi/davinci_spi.c | 67 +++-
>> 1 files changed, 35 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
>> index 60ba007..b4a74de 100644
>> --- a/drivers/spi/davinci_spi.c
>> +++ b/drivers/spi/davinci_spi.c
>> @@ -131,6 +131,7 @@ int spi_xfer(struct spi_slave *slave, unsigned int
>> bitlen,
>> {
>
> [...]
>
>> + /* write to DAT1 is required to keep the serial
>> transfer going */
>> + /* we just terminate when we reach the end */
>> + if((o_cnt == (len -1)) && (flags & SPI_XFER_END)) {
>
> Please include a space before the '-'
>
> Thanks,
> Sekhar
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] 85xx: Add is_serdes_configured() support for P2020SERDES
On May 21, 2010, at 6:26 AM, Li Yang-R58472 wrote:
>> Subject: [U-Boot] [PATCH] 85xx: Add is_serdes_configured() support for
>> P2020SERDES
>>
>> Add the ability to determine if a given IP block connected on SERDES is
>> configured. This is useful for things like PCIe and SRIO since they are
>> only ever connected on SERDES.
>>
>> Signed-off-by: Kumar Gala
>
> I'm not sure why this code has to be re-done rather than using the patch I
> submitted?
There was some minor unification with the P4080 SERDES code.
> {snip}
>
>> +int is_serdes_configured(enum srds_prtcl device) {
>> +int i;
>> +ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
>> +u32 pordevsr = in_be32(&gur->pordevsr);
>
> Wouldn't it be better to only read it once on fsl_serdes_init(), after all it
> will not be changed after reset.
This depend on the use of global static variables in u-boot. Not sure the
current state of that being acceptable.
>
>> +u32 srds1_cfg = (pordevsr & MPC85xx_PORDEVSR_IO_SEL) >>
>> +MPC85xx_PORDEVSR_IO_SEL_SHIFT;
>> +
>> +debug("%s: dev = %d\n", __FUNCTION__, device);
>> +debug("PORDEVSR[IO_SEL] = %x\n", srds1_cfg);
>> +
>> +if (srds1_cfg > ARRAY_SIZE(serdes1_cfg_tbl)) {
>> +printf("Invalid PORDEVSR[IO_SEL] = %d\n", srds1_cfg);
>> +return 0;
>> +}
>> +
>> +for (i = 0; i < SRDS1_MAX_LANES; i++) {
>> +if (serdes1_cfg_tbl[srds1_cfg][i] == device)
>> +return 1;
>
> Given the fact that the is_serdes_configured() will be called multiple times,
> it will be better to process the table in fsl_serdes_init() and save time for
> every is_serdes_configured() judgment like what I did.
>
> - Leo
>
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +void fsl_serdes_init(void)
>> +{
>> +}
>> --
>> 1.6.0.6
>>
>> ___
>> 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] use of global static variables?
With the relocation changes are global statics variables ok if we know code is called after relocation? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Improve DaVinci SPI speed
Dear Delio Brignoli,
In message <25096244-c685-4d68-bbf9-6df2f154a...@audioscience.com> you wrote:
> Reduce the number of reads per byte transferred on the BUF register from 2 to
> 1 and
> take advantage of the TX buffer in the SPI module.
...
> + /* if data is available */
> + if ((i_cnt < len) && (buf_reg_val & SPIBUF_RXEMPTY_MASK) == 0) {
> + /* if there is no read buffer simply ignore the read
> character */
> + if(rxp) {
> + *rxp = buf_reg_val & 0xFF;
> + rxp++;
> + }
Please change into:
if (rxp)
*rxp++ = buf_reg_val & 0xFF;
> + if ((o_cnt < len) && ((buf_reg_val & SPIBUF_TXFULL_MASK) == 0))
> {
> + /* write the data */
> + data1_reg_val &= ~0x;
> + if(txp) {
> + data1_reg_val |= *txp;
> + txp++;
> + }
Same here:
if (txp)
data1_reg_val |= *txp++;
Please fix all other occurrences of "if(" into "if (" as well.
> + /* write to DAT1 is required to keep the serial
> transfer going */
> + /* we just terminate when we reach the end */
Incorrect multiline comment style.
> + writel(data1_reg_val &
> + ~(1 << SPIDAT1_CSHOLD_SHIFT),
> &ds->regs->dat1);
Line too long.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The software required `Windows 95 or better', so I installed Linux.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DaVinci: Improve DaVinci SPI speed.
On Thu, May 13, 2010 at 8:57 AM, Delio Brignoli wrote: > Reduce the number of reads per byte transferred on the BUF register from 2 to > 1 and > take advantage of the TX buffer in the SPI module. On LogicPD OMAP-L138 EVM, > SPI read throughput goes up from ~0.8Mbyte/s to ~1.3Mbyte/s. Tested with a > 2Mbyte image file. > > Signed-off-by: Delio Brignoli Applies cleanly on u-boot master branch -- 2f05e39 of git://git.denx.de/u-boot.git Applies cleanly and compiles with da850evm_config on u-boot-omap-l1 master branch -- 5f16b85 of 2f05e39 . Also running the resulting u-boot.bin did show a noticeable improvement in kernel load time. Tested-by: Ben Gardiner -- Ben Gardiner Nanometrics Inc. +1 (613) 592-6776 x239 http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] DaVinci: Improve DaVinci SPI speed.
On Fri, May 21, 2010 at 9:15 AM, Ben Gardiner wrote: > Applies cleanly and compiles with da850evm_config on u-boot-omap-l1 > master branch -- 5f16b85 of 2f05e39 . Also running the resulting Sorry, that should be 5f16b85 of git://arago-project.org/git/people/sekhar/u-boot-omapl1.git . -- Ben Gardiner Nanometrics Inc. +1 (613) 592-6776 x239 http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: > fsl_ddr_sdram() does NOT the same as get_ram_size(). It does not > perform any actual testing, and will not detect errors in the SPD > information or in the code processing it. Ok, I'll add it. >> This code is identical to the code in the p2020ds.c, so I'm just >> mirroring it. The only difference is the names of the slots in the >> printf. I would prefer to keep this new code as close as possible to >> our existing code. I suspect that we'll be unifying the PCI code in >> the future, and keeping it similar will make it easier. > > Thanks for pointing this out. so we have even more occurrences of this > block of code - time has come to factor this out into a common > function that is used for this board and for p2020ds as well. Kumar just posted some patches for p2020ds that changes this, so I'll incorporate those. >>> This CONFIG_GET_CLK_FROM_ICS307 is documented? >> >> We've been using it for years. Now you complain? It's the same code >> in almost all of our recent boards. > > Please document it. Looks like Kumar posted patches for this, too, so I'll add those as well. > I complain about things when I see them. > > Do you really expect me to review all patches submitted on this list > in scrupulous detail? No, apparently just mine. > It would be nice if you also fixed all the other dozen places where > such code has crept in. Can I do one thing at a time? I agree that a lot of those could be optimized, and if you look at the git log for our stuff, you'll see we've been doing that a lot in the past year. But in general, fixes like these usually work better if the board support is already present in your repository. >>> PCIE1 => pci1 => pcie1_hose >>> PCIE2 => pci0 => pcie2_hose >>> PCIE3 => pci2 => pcie3_hose >>> >>> Weird, weird... >> >> I asked Kumar about it, but he didn't really have much to say, so I left it. > > You mean neither of you knows if this is correct or wrong ??? I guess I should clarify. Kumar said it was based on the order of the addresses of the PCI devices within CCSR space, but he didn't offer any insight as to whether it should be fixed or how. +++ b/board/freescale/p1022ds/p1022ds_diu.c @@ -0,0 +1,151 @@ >>> >>> This should probably go to drivers/video/ ? >> >> It's p1022-specific, so I don't see why. > > No, it's not. It is largely the same as mpc8610hpcd_diu.c; common > video driver code belongs into drivers/video/ Ok, will you allow me to merge those two functions into a single driver at a later time, when I have the opportunity to examine the code and test it on both boards? +#ifndef __ASSEMBLY__ +extern unsigned long calculate_board_sys_clk(void); +extern unsigned long calculate_board_ddr_clk(void); +#endif >>> >>> Please move to appropriate header file. >> >> OMG, every single one of our header files does this We've been >> doing this for years! >> >> I really do believe you're picking on me now. > > I'm not. I'm just reviewing a patch. > > It would be great if you cleaned up the other places as well. Well, this particular change would probably need to be made later, because I would probably need to change all the board header files at once. It's not trivial. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of global static variables?
Dear Kumar Gala, In message you wrote: > With the relocation changes are global statics variables ok if we > know code is called after relocation? They have always been ok (as far as global variables can be ok) if you were aware of their restrictions before relocation. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of global static variables?
Hi Kumar, On Fri, 2010-05-21 at 07:52 -0500, Kumar Gala wrote: > With the relocation changes are global statics variables ok if we know code > is called after relocation? Yes, they should work as expected after relocation. Prior to relocation you should be able to read the values of the global statics if they are initialized to a non-zero value, but not modify them. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Dear Timur Tabi, In message <4bf68e6a.4070...@freescale.com> you wrote: > > > Do you really expect me to review all patches submitted on this list > > in scrupulous detail? > > No, apparently just mine. Unless you pay me for this (or FSL) you should not even rely on this. > > It would be nice if you also fixed all the other dozen places where > > such code has crept in. > > Can I do one thing at a time? I agree that a lot of those could be > optimized, and if you look at the git log for our stuff, you'll see we've > been doing that a lot in the past year. But in general, fixes like these > usually work better if the board support is already present in your > repository. Well, there are things and things. When we discover that crap has piled up here and there, it's a good idea to perform a clean up. When the first one adds some feature or new architecture or similar, it is pretty normal that he cannot yet always decide correctly what needs to go where, or which parts are specific to CPU or board and which are common. But when more boards get added, this usually becomes clear pretty quickly. It has always been more efficient to prevent code that is known to need such cleanup to prevent from going into mainline in the first place, than to allow it to go in and hope that somebody, sometime will find time and resources and zest for a clean-up. Is it easier for you to convince your manager that you need N more hours to get that code accepted for mainline, or to get allownce for N hours to perform some cleanup in U-Boot that is not related to your current project? [I have somemore tasks at hand if the latter should be the case :-) ] > >>> PCIE1 => pci1 => pcie1_hose > >>> PCIE2 => pci0 => pcie2_hose > >>> PCIE3 => pci2 => pcie3_hose > >>> > >>> Weird, weird... > >> > >> I asked Kumar about it, but he didn't really have much to say, so I left > >> it. > > > > You mean neither of you knows if this is correct or wrong ??? > > I guess I should clarify. Kumar said it was based on the order of the > addresses of the PCI devices within CCSR space, but he didn't offer any > insight as to whether it should be fixed or how. So please check this again. It looks broken to me. > > No, it's not. It is largely the same as mpc8610hpcd_diu.c; common > > video driver code belongs into drivers/video/ > > Ok, will you allow me to merge those two functions into a single driver at a > later time, when I have the opportunity to examine the code and test it on > both boards? Please let's do it now, instead of adding code that is known to need fixing. See above for my reasoning. > +#ifndef __ASSEMBLY__ > +extern unsigned long calculate_board_sys_clk(void); > +extern unsigned long calculate_board_ddr_clk(void); > +#endif > >>> > >>> Please move to appropriate header file. ... > Well, this particular change would probably need to be made later, because I > would probably need to change all the board header files at once. It's not > trivial. What exactly is not trivial in moving some prototype declarations to another header file? Please elucidate. The most difficult part is probably determining where they actually belong to. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de To program is to be. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] use of global static variables?
Dear Peter Tyser,
In message <1274450989.18152.273.ca...@petert> you wrote:
>
> > With the relocation changes are global statics variables ok if we know code
> > is called after relocation?
>
> Yes, they should work as expected after relocation.
>
> Prior to relocation you should be able to read the values of the global
> statics if they are initialized to a non-zero value, but not modify
> them.
Correct. And in some places we enable these even for zero valued
variables by using the old trick of writing
int foo __attribute__ ((section(".data"))) = 0;
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The speed of time is one second per second.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: > Unless you pay me for this (or FSL) you should not even rely on this. Heh. > Well, there are things and things. > > When we discover that crap has piled up here and there, it's a good > idea to perform a clean up. I agree 100%. > When the first one adds some feature or new architecture or similar, > it is pretty normal that he cannot yet always decide correctly what > needs to go where, or which parts are specific to CPU or board and > which are common. But when more boards get added, this usually becomes > clear pretty quickly. Ok. > It has always been more efficient to prevent code that is known to > need such cleanup to prevent from going into mainline in the first > place, than to allow it to go in and hope that somebody, sometime will > find time and resources and zest for a clean-up. I'm not sure I agree with that completely. In many cases, it's more efficient to work on tasks in bite-size chunks. > Is it easier for you to convince your manager that you need N more > hours to get that code accepted for mainline, or to get allownce for > N hours to perform some cleanup in U-Boot that is not related to your > current project? Definitely the latter. Cleaning up U-Boot (and Linux) code so that it's overall easier to maintain and more efficient is one of the primary tasks of my department. > [I have somemore tasks at hand if the latter should be the case :-) ] Please, send me a list. We have an internal bug tracking system, and I would be more than happy to log all the items that concern you (as long as they affect Freescale PowerPC products in some way). >> I guess I should clarify. Kumar said it was based on the order of the >> addresses of the PCI devices within CCSR space, but he didn't offer any >> insight as to whether it should be fixed or how. > > So please check this again. It looks broken to me. Ok. >> Ok, will you allow me to merge those two functions into a single driver at a >> later time, when I have the opportunity to examine the code and test it on >> both boards? > > Please let's do it now, instead of adding code that is known to need > fixing. See above for my reasoning. And see my above response for why I'd prefer not to solve this now. I'll try to fix it anyway, though. >> +#ifndef __ASSEMBLY__ >> +extern unsigned long calculate_board_sys_clk(void); >> +extern unsigned long calculate_board_ddr_clk(void); >> +#endif > > Please move to appropriate header file. > ... >> Well, this particular change would probably need to be made later, because I >> would probably need to change all the board header files at once. It's not >> trivial. > > What exactly is not trivial in moving some prototype declarations to > another header file? Please elucidate. The most difficult part is > probably determining where they actually belong to. Well, I'll take a closer look, but my concern is that there is no good header file to move these into that wouldn't require modifying dozens of files. Since I'm trying to add support for one particular board, I don't want to modify every other board in the same patch set. I'll try to fix it anyway, though. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Nios2-dev] [PATCH 1/6 v4] nios2: add gpio support
On 30/04/10 04:34, Thomas Chou wrote: > This patch adds driver for a trivial gpio core, which is described > in http://nioswiki.com/GPIO. It is used for gpio led and nand flash > interface in u-boot. > > When CONFIG_SYS_GPIO_BASE is not defined, board may provide > its own driver. > > Signed-off-by: Thomas Chou Tested with LED on Altera 2C35 development board. Tested-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Nios2-dev] [PATCH 2/6 v2] misc: add gpio based status led driver
On 30/04/10 04:34, Thomas Chou wrote: > This patch adds a status led driver followed the GPIO access > conventions of Linux. The led mask is used to specify the gpio pin. > > Signed-off-by: Thomas Chou Tested on Altera 2C35 development board. Tested-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Nios2-dev] [PATCH 3/6 v3] nios2: add gpio support to nios2-generic board
On 30/04/10 04:34, Thomas Chou wrote: > This patch adds gpio support of Altera PIO component to the > nios2-generic board. Though it drives only gpio_led at the > moment, it supports bidirectional port to control bit-banging > I2C, NAND flash busy status or button switches, etc. > > Signed-off-by: Thomas Chou Tested with LED on Altera 2C35 development board. Tested-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Nios2-dev] [PATCH 6/6 v3] nios2: add spi flash support to nios2-generic board
On 30/04/10 04:34, Thomas Chou wrote: > This patch enables the altera_spi and spi_flash drivers for the > nios2-generic board. It allows access to the EPCS/SPI flash on > the Altera EP1C20 board. > > Signed-off-by: Thomas Chou Tested with EPCS64N flash chip on Altera 2C35 development board. Tested-by: Ian Abbott -- -=( Ian Abbott @ MEV Ltd.E-mail: )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Nios2-dev] [PATCH 4/6 v10] spi: add altera spi controller support
On 30/04/10 04:34, Thomas Chou wrote:
> This patch adds the driver of altera spi controller, which is
> used as epcs/spi flash controller. It also works with mmc_spi
> driver.
>
> This driver support more than one spi bus, with base list declared
> #define CONFIG_SYS_ALTERA_SPI_LIST { BASE_0,BASE_1,... }
>
> Signed-off-by: Thomas Chou
Tested with EPCS64N flash chip on Altera 2C35 development board.
Tested-by: Ian Abbott
--
-=( Ian Abbott @ MEV Ltd.E-mail: )=-
-=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] S spoštovanjem,
Garancije za posojila ponudbe z obrestno mero v višini 2,5% mesečno. Ali imate slabo kreditno ali ste potrebujejo denar za plačilo računov? hočem raba to medij, da vas obvestim, da sem postal zanesljiv upravičenca pomoči, kot bom vesel, da vam ponudimo posojilo z obrestno mero 2,5% stopnja. Storitve, ki vključujejo; .. Refinancirati .. Inventor posojila .. Auto posojila .. Konsolidaciji dolgov .. Posojilni posli .. Osebna posojila prosimo, izpolnite obrazec spodaj, da bomo lahko zagon obdelave. NAME == SEX == AGE == DRŽAVA == NASLOV == Sredstva, potrebna == TRAJANJE == MOBILE TEL NO == PROSTOR Izbiranje številčno oznako == Čakanje na vaš injekcijski prijavni obrazec. S spoštovanjem, G. withon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] x86 Custodianship
Dear Graeme Russ, In message <4bf52993.80...@gmail.com> you wrote: > > I've been a bit busy at home with bub #2 to chase this up, but have you > decided whether or not to create an x86 repository? If so, I would be happy > to take up custodianship of it and 'fly the flag' for U-Boot on the x86 > platform. > > I sent you my public RSA key earlier - let me know if you want me to resend No need to. The x86 repo is ready for you. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "Go to Heaven for the climate, Hell for the company."- Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tools: set multiple variable with fw_setenv utility
Wolfgang Denk wrote:
>> a config file with a list of pairs to be set,
>> separated by a TAB character.
>
> I think we should be less restrictive here. Please split at the first
> white space, and allow for multiple white spaces.
There is a reason why I set to this format. There should be a case where
a variable is set with a leading (or more as one) white space. For
example, I have seen something related to board names, and adding some
spaces makes a sort of formatting without changing the code.
Because the TAB character is not allowed inside a variable, this assures
that everything except TAB is taken as part of the variables's value.
>> +/* Allocate enough place to the data string */
>> for (i = 2; i < argc; ++i) {
>> char *val = argv[i];
>> +if (!value) {
>> +value = (char *)malloc(len - strlen(name));
>> +memset(value, 0, len - strlen(name));
>
> Kaboom! when malloc() fails.
This is an error, thanks. And I see I have not checked the return value
of malloc at all in my patch. I will fix it globally.
>> /* write environment back to flash */
>> -if (flash_io (O_RDWR)) {
>> +if (flash_io(O_RDWR)) {
>> fprintf (stderr, "Error: can't write fw_env to flash\n");
>> return -1;
>
> We probably should not repeat this code, but factor it out.
Good idea, sure !
>
>> +/*
>> + * Parse script to generate list of variables to set
>> + * The script file has a very simple format, as follows:
>> + *
>> + * Each line has a couple with name, value:
>> + * variable_namevariable_value
>
> Please make this:
>
> namevalue
See my comment above. With my proposal, something as
board_namemy product made by my company
works flawlessy. We can add some delimiters (as ', "), but we could have
such delimiters inside the value itself and we have then to use escapes.
Because is not allowed as character inside a variable (or I have
not yet seen this case...), it makes thing easier.
>> +int i = 0;
>> +char dump[128];
>
> Ouch! That's short! Why do we need such an arbitrary limit?
We do not need a small value, but I have to set a value for fgets. A
bigger value should be enough, reporting an error if the line is too long.
>
>> +fp = fopen(fname, "r");
>> +if (fp == NULL)
>> +return -1;
>
> How about a useful error message?
Surely.
>> +strncpy(list[i].name, name, sizeof(list[i].name) - 1);
>
> Error message for too long names?
Yes !
> Hm... Isn't strtok() a bit of overkill here, when all we want to do is
> split at the first white space?
Well, I have not thought it is a problem. Of course the simple way could
be to check the whole bytes inside the string, but why do you think I
should not use strtok ?
>
>> +typedef struct {
>> +char name[255];
>> +char value[255];
>> +} fw_env_list;
>
> Again we have arbitrary limits. And even different ones from the one
> above (128).
Another possibility is to dinamically allocate memory for name/value on
demand. Theoretically a value could be a very long string and the only
limit I see in u-boot is the environment size.
>
>
>> +static struct option long_options[] = {
>> +{"script", required_argument, NULL, 's'},
>> +{NULL, 0, NULL, 0}
>> +};
>
> The command should also accept '-' as file name, and then read from
> stdin.
Ok, understood. So we can allow something like "fw_setenv -s - <
variables_file".
Regards,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the FreescaleP1022DS reference board
Liu Dave-R63238 wrote: > Did you grab the patch from our latest BSP tree? No, I've been using the ltib patches. I guess I should use the repository on git.ap instead. > It seems like your patch doesn't base on latest upstream tree, IIRC, the > PCI stuff > in mpc8xxx/pci_cfg.c is ready in upstream tree. Ah, I was using the P2020 as a basis, not the 8536. And I see Kumar just posted patches for the P2020. > Did you have a test the patch on V2 board? The V2 board has big change > from V1 > board. Anyway I would like we have sufficient test on V2 board before it > is merged to > main tree. When I power on the board, it says this: Board: P1022DS Sys ID: 0x19, Sys Ver: 0x02, FPGA Ver: 0x04, vBank: 0 How can I tell if I have a rev2 board? There's a sticker that says, "sch-26191 rev b" -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
On Fri, May 21, 2010 at 4:18 AM, Kumar Gala wrote:
> +#ifdef CONFIG_FSL_NGPIXIS
> +#include "ngpixis.h"
> +#define PIXIS_VSYSCLK0 offsetof(struct ngpixis, sclk[0])
> +#define PIXIS_VSYSCLK1 offsetof(struct ngpixis, sclk[1])
> +#define PIXIS_VSYSCLK2 offsetof(struct ngpixis, sclk[2])
> +#define PIXIS_VDDRCLK0 offsetof(struct ngpixis, dclk[0])
> +#define PIXIS_VDDRCLK1 offsetof(struct ngpixis, dclk[1])
> +#define PIXIS_VDDRCLK2 offsetof(struct ngpixis, dclk[2])
> +#endif
Yuck. I specifically created the ngpixis_t structure because Wolfgang
objected to the use of macros for offsets.
But I understand why you did it. It's the easiest way to maintain
compatibility between pixis and ngpixis.
> +/* decode S[0-2] to Output Divider (OD) */
> +static unsigned char ics307_s_to_od[] = {
> + 10, 2, 8, 4, 5, 7, 3, 6
> +};
Can you make this a u8 instead?
> +static unsigned long
> +ics307_clk_freq(unsigned char cw0, unsigned char cw1, unsigned char cw2)
u8's here, also. You might then be able to make this one line.
> +{
> + const unsigned long input_freq = CONFIG_ICS307_REFCLK_HZ;
> + unsigned long VDW = ((cw1 << 1) & 0x1FE) + ((cw2 >> 7) & 1);
> + unsigned long RDW = cw2 & 0x7F;
> + unsigned long OD = ics307_s_to_od[cw0 & 0x7];
> + unsigned long freq;
Wolfgang just asked me not to use camel caps.
> +#ifndef __ASSEMBLY__
> +extern unsigned long get_board_sys_clk(void);
> +extern unsigned long get_board_ddr_clk(void);
> +#endif
I don't think we need the "#ifndef __ASSEMBLY__" here.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tools: set multiple variable with fw_setenv utility
Dear Stefano Babic,
In message <4bf6a381.7020...@denx.de> you wrote:
> Wolfgang Denk wrote:
>
> >> a config file with a list of pairs to be set,
> >> separated by a TAB character.
> >
> > I think we should be less restrictive here. Please split at the first
> > white space, and allow for multiple white spaces.
>
> There is a reason why I set to this format. There should be a case where
> a variable is set with a leading (or more as one) white space. For
> example, I have seen something related to board names, and adding some
> spaces makes a sort of formatting without changing the code.
Adding spaces to the variable value? This makes little sense to me.
It's just a waste of storage space and boot time.
If you feel your environment is so complicated to read that you want
such "formatting", then rather structure your envrionment (see
proposals on the list), and/or help improving the printenv
capabilities to add sorting etc.
> Because the TAB character is not allowed inside a variable, this assures
> that everything except TAB is taken as part of the variables's value.
TAB can be embedded in a variable value (if you manage to enter it).
> See my comment above. With my proposal, something as
>
> board_namemy product made by my company
> works flawlessy. We can add some delimiters (as ', "), but we could have
> such delimiters inside the value itself and we have then to use escapes.
> Because is not allowed as character inside a variable (or I have
> not yet seen this case...), it makes thing easier.
Who says that TAB would not be allowed? Of course it is. There is
virtually no restriction on the content of the value of a variable.
The only character that cannot be part of the value is '\0'.
[Of course it is not a wise decision to add non-printing or control
characters, but you can do this, if you like.]
> >> + char dump[128];
> >
> > Ouch! That's short! Why do we need such an arbitrary limit?
>
> We do not need a small value, but I have to set a value for fgets. A
> bigger value should be enough, reporting an error if the line is too long.
But your code is not set up to handle the remainder of too long lines.
It would be read as the next line and cause confusion.
> >> +typedef struct {
> >> + char name[255];
> >> + char value[255];
> >> +} fw_env_list;
> >
> > Again we have arbitrary limits. And even different ones from the one
> > above (128).
>
> Another possibility is to dinamically allocate memory for name/value on
> demand. Theoretically a value could be a very long string and the only
> limit I see in u-boot is the environment size.
Why do you have to run this in two spearate passes at all - first
scan, then process.
Why cannot you process each variable when you read it? The we would
not need any array or list at all.
> > The command should also accept '-' as file name, and then read from
> > stdin.
>
> Ok, understood. So we can allow something like "fw_setenv -s - <
> variables_file".
Right.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I must follow the people. Am I not their leader? - Benjamin Disraeli
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: add support for the Freescale P1022DS reference board
Wolfgang Denk wrote: >> > +#ifndef __ASSEMBLY__ >> > +extern unsigned long calculate_board_sys_clk(void); >> > +extern unsigned long calculate_board_ddr_clk(void); >> > +#endif > > >>> > > >>> Please move to appropriate header file. > ... >> > Well, this particular change would probably need to be made later, because >> > I >> > would probably need to change all the board header files at once. It's not >> > trivial. > What exactly is not trivial in moving some prototype declarations to > another header file? Please elucidate. The most difficult part is > probably determining where they actually belong to. Well, I'm having a hard time finding a good header file. For the P1022DS, I just need to have this macros known to speed.c, so I could add these lines to the top of /arch/powerpc/cpu/mpc85xx/speed.c: #include #include #include #include /* Clock frequency */ unsigned long calculate_board_sys_clk(void); unsigned long calculate_board_ddr_clk(void); DECLARE_GLOBAL_DATA_PTR; But I suspect this will not be sufficient for all of the other 85xx boards. Another option is arch/powerpc/include/asm/config.h, but that header file doesn't have any function prototypes today. There's also include/common.h, near this block: #if defined(CONFIG_MPC85xx) typedef MPC85xx_SYS_INFO sys_info_t; voidget_sys_info ( sys_info_t * ); ulong get_ddr_freq (ulong); #endif #if defined(CONFIG_MPC86xx) typedef MPC86xx_SYS_INFO sys_info_t; void get_sys_info ( sys_info_t * ); #endif Suggestions? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Capability to select from more than one kernel to boot ?
Hi list I like to make Linux kernel "updates" robust to user/power failurer, during the porcess. Is there a well accepted way to do this for u-boot? using some form of file system (ubifs, jffs2, etc ?) with u-boot where kernel is stored etc etc.. Any pointers much appreciated. ayewin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tools: set multiple variable with fw_setenv utility
Wolfgang Denk wrote: > Adding spaces to the variable value? This makes little sense to me. > It's just a waste of storage space and boot time. Well, I can agree with you, however I have already seen this case... > If you feel your environment is so complicated to read that you want > such "formatting", then rather structure your envrionment (see > proposals on the list), and/or help improving the printenv > capabilities to add sorting etc. Ok, understood. I will change to support something like variablevalue > Who says that TAB would not be allowed? ..probably is more stranger as to have spaces > Of course it is. There is > virtually no restriction on the content of the value of a variable. > The only character that cannot be part of the value is '\0'. > > [Of course it is not a wise decision to add non-printing or control > characters, but you can do this, if you like.] As I saw some leading whitespaces in a variable, I cannot remember a case where I saw a TAB in a variable. But as it is not forbidden, probably there is still this case ! > + char dump[128]; >>> Ouch! That's short! Why do we need such an arbitrary limit? >> We do not need a small value, but I have to set a value for fgets. A >> bigger value should be enough, reporting an error if the line is too long. > > But your code is not set up to handle the remainder of too long lines. > It would be read as the next line and cause confusion. Ah, ok, I get now the point. > Why do you have to run this in two spearate passes at all - first > scan, then process. > > Why cannot you process each variable when you read it? The we would > not need any array or list at all. There is a reason, please tell me how good it is ;-) I thought the code could be used not only as it is, but integrated in an application linking the required object (only one, fw_env.o). An application could internally generate a list of pairs variable/values and needs a function to set them in the u-boot environment. This is the reason of the int fw_setenv_multiple(fw_env_list *list, int count) function. No need to use an external file, no need to call fw_setenv as external process. An application could link fw_env.o and call fw_setenv_multiple(). I agree with you that I can do everything in a single pass if we do not provide such kind of external interface. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
On most Freescale 85xx boards, the CONFIG_SYS_CLK_FREQ and CONFIG_DDR_CLK_FREQ macros are defined like this: This means that in order to use these macros, the callers must have prototypes for the corresponding functions. On 85xx, only speed.c uses these macros, so let's define the prototypes there. This eliminates the need to define the prototypes in the board config files. Signed-off-by: Timur Tabi --- I'm posting the patch for review, and if everyone likes it, inclusion in the 85xx repo. Comments welcome. arch/powerpc/cpu/mpc85xx/speed.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c index 8132115..724ce9d 100644 --- a/arch/powerpc/cpu/mpc85xx/speed.c +++ b/arch/powerpc/cpu/mpc85xx/speed.c @@ -31,6 +31,10 @@ #include #include +/* Board-specific clock frequency functions. */ +unsigned long calculate_board_sys_clk(void); +unsigned long calculate_board_ddr_clk(void); + DECLARE_GLOBAL_DATA_PTR; /* --- */ -- 1.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
On 05/21/2010 01:07 PM, Timur Tabi wrote: > On most Freescale 85xx boards, the CONFIG_SYS_CLK_FREQ and CONFIG_DDR_CLK_FREQ > macros are defined like this: Like what? > This means that in order to use these macros, the callers must have prototypes > for the corresponding functions. On 85xx, only speed.c uses these macros, so > let's define the prototypes there. This eliminates the need to define the > prototypes in the board config files. It also eliminates the utility of the prototype in making sure usage matches the definition, and requires that the user of the macros provide implementation prerequisites. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
Scott Wood wrote: > On 05/21/2010 01:07 PM, Timur Tabi wrote: >> On most Freescale 85xx boards, the CONFIG_SYS_CLK_FREQ and >> CONFIG_DDR_CLK_FREQ >> macros are defined like this: > > Like what? Doh. Git commit delete those lines because they began with a "#". This was supposed to be there: #define CONFIG_SYS_CLK_FREQ calculate_board_sys_clk() #define CONFIG_DDR_CLK_FREQ calculate_board_ddr_clk() >> This means that in order to use these macros, the callers must have >> prototypes >> for the corresponding functions. On 85xx, only speed.c uses these macros, so >> let's define the prototypes there. This eliminates the need to define the >> prototypes in the board config files. > > It also eliminates the utility of the prototype in making sure usage > matches the definition, and requires that the user of the macros provide > implementation prerequisites. Hmm... Looks like calculate_board_sys_clk() is defined only on the p2020 currently. Everyone else uses get_board_sys_clk(). So perhaps we need to fix p2020ds to use get_board_sys_clk() instead of calculate_board_sys_clk(). But that's a different problem. Well, I'm open to suggestions. Wolfgang asked me to find a solution to this: #ifndef __ASSEMBLY__ unsigned long calculate_board_sys_clk(void); unsigned long calculate_board_ddr_clk(void); #endif #define CONFIG_SYS_CLK_FREQ calculate_board_sys_clk() #define CONFIG_DDR_CLK_FREQ calculate_board_ddr_clk() He doesn't want the prototypes in the board header file. > > -Scott -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
On 05/21/2010 01:18 PM, Timur Tabi wrote: > Scott Wood wrote: >> On 05/21/2010 01:07 PM, Timur Tabi wrote: >>> On most Freescale 85xx boards, the CONFIG_SYS_CLK_FREQ and >>> CONFIG_DDR_CLK_FREQ >>> macros are defined like this: >> >> Like what? > > Doh. Git commit delete those lines because they began with a "#". Hmm... is there any way to override that and insert such a line into a git commit? > Well, I'm open to suggestions. Wolfgang asked me to find a solution to this: > > #ifndef __ASSEMBLY__ > unsigned long calculate_board_sys_clk(void); > unsigned long calculate_board_ddr_clk(void); > #endif > #define CONFIG_SYS_CLK_FREQ calculate_board_sys_clk() > #define CONFIG_DDR_CLK_FREQ calculate_board_ddr_clk() > > He doesn't want the prototypes in the board header file. I think the board header file (or some header factored out from a set of similar boards, which the board header includes) is exactly where it belongs, given that it's implemented in a board C file, and the C call is not a public API. Some boards just hard code it as a constant. Others might want to call some other function, maybe with arguments (in fact, I see a dummy argument of zero passed in many if not all existing calls to these functions -- why?). Duplicating large chunks of code is bad, but extremism in avoiding anything that even looks similar to something else, and breaking the logical isolation of said things in the process, is bad as well. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
Scott Wood wrote: >> Doh. Git commit delete those lines because they began with a "#". > > Hmm... is there any way to override that and insert such a line into a > git commit? I was going to just insert a blank space or some other character before the #. > I think the board header file (or some header factored out from a set of > similar boards, which the board header includes) is exactly where it > belongs, given that it's implemented in a board C file, and the C call > is not a public API. Well, you'll have to convince Wolfgang of that, not me. He won't accept my P1022DS board patch until I fix this "problem". > Some boards just hard code it as a constant. > Others might want to call some other function, maybe with arguments (in > fact, I see a dummy argument of zero passed in many if not all existing > calls to these functions -- why?). Probably some legacy stuff. Once this issue is resolved, I'll probably post a patch that unifies the functions in some way. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
Timur Tabi wrote: > Well, you'll have to convince Wolfgang of that, not me. He won't accept my > P1022DS board patch until I fix this "problem". Actually, if you look at Kumar's ICS307 patch, you'll see he fixes this problem for any board that uses the ICS307: > -#ifndef __ASSEMBLY__ > -extern unsigned long calculate_board_sys_clk(unsigned long dummy); > -extern unsigned long calculate_board_ddr_clk(unsigned long dummy); > -/* extern unsigned long get_board_sys_clk(unsigned long dummy); */ > -/* extern unsigned long get_board_ddr_clk(unsigned long dummy); */ > -#endif > -#define CONFIG_SYS_CLK_FREQ calculate_board_sys_clk(0) /* sysclk for > MPC85xx */ > -#define CONFIG_DDR_CLK_FREQ calculate_board_ddr_clk(0) /* ddrclk for > MPC85xx */ > +#define CONFIG_SYS_CLK_FREQ get_board_sys_clk() /* sysclk for MPC85xx */ > +#define CONFIG_DDR_CLK_FREQ get_board_ddr_clk() /* ddrclk for MPC85xx */ > #define CONFIG_ICS307_REFCLK_HZ 3000 /* ICS307 clock chip ref freq > */ > -#define CONFIG_GET_CLK_FROM_ICS307 /* decode sysclk and ddrclk freq > - from ICS307 instead of switches */ -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
On Fri, May 21, 2010 at 4:18 AM, Kumar Gala wrote: > +COBJS-$(CONFIG_P2020DS) += ics307_clk.o How about changing this to: COBJS-$(CONFIG_ICS307_REFCLK_HZ) += ics307_clk.o -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
On 05/21/2010 01:36 PM, Timur Tabi wrote: > Scott Wood wrote: > >>> Doh. Git commit delete those lines because they began with a "#". >> >> Hmm... is there any way to override that and insert such a line into a >> git commit? > > I was going to just insert a blank space or some other character before the #. > >> I think the board header file (or some header factored out from a set of >> similar boards, which the board header includes) is exactly where it >> belongs, given that it's implemented in a board C file, and the C call >> is not a public API. > > Well, you'll have to convince Wolfgang of that, not me. He won't accept my > P1022DS board patch until I fix this "problem". I think the "some header factored out from a set of similar boards" (or possibly similar board support idioms) approach would meet his request, though doing that at too fine-grained a level could lead to an unreadable tangle of header files and/or ifdefs. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc85xx: add function prototypes for sys and ddr clocks to speed.c
On Fri, 2010-05-21 at 13:34 -0500, Scott Wood wrote: > On 05/21/2010 01:18 PM, Timur Tabi wrote: > > Scott Wood wrote: > >> On 05/21/2010 01:07 PM, Timur Tabi wrote: > >>> On most Freescale 85xx boards, the CONFIG_SYS_CLK_FREQ and > >>> CONFIG_DDR_CLK_FREQ > >>> macros are defined like this: > >> > >> Like what? > > > > Doh. Git commit delete those lines because they began with a "#". > > Hmm... is there any way to override that and insert such a line into a > git commit? 'git commit --cleanup=verbatim' should do it. I think "--cleanup=whitespace" should also work. Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
On Fri, May 21, 2010 at 4:18 AM, Kumar Gala wrote: > + * Adding 1 to get a "nicely" rounded number, but this needs > + * more tweaking to get a "properly" rounded number. > + */ > + > + freq = 1 + (input_freq * 2 * (VDW + 8) / ((RDW + 2) * OD)); Is this rounding algorithm the reason why I get output like this: Clock Configuration: CPU0:799.992 MHz, CPU1:799.992 MHz, CCB:399.996 MHz, DDR:299.997 MHz (599.994 MT/s data rate) (Asynchronous), LBC:25 MHz If so, maybe we should fix it? -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tools: set multiple variable with fw_setenv utility
Dear Stefano, In message <4bf6b724.6090...@denx.de> you wrote: > > > Adding spaces to the variable value? This makes little sense to me. > > It's just a waste of storage space and boot time. > > Well, I can agree with you, however I have already seen this case... I believe you. I have seen stranger things before ;-) > > Why cannot you process each variable when you read it? The we would > > not need any array or list at all. > > There is a reason, please tell me how good it is ;-) > > I thought the code could be used not only as it is, but integrated in an > application linking the required object (only one, fw_env.o). > An application could internally generate a list of pairs variable/values > and needs a function to set them in the u-boot environment. This is the > reason of the int fw_setenv_multiple(fw_env_list *list, int count) > function. No need to use an external file, no need to call fw_setenv as > external process. An application could link fw_env.o and call > fw_setenv_multiple(). > > I agree with you that I can do everything in a single pass if we do not > provide such kind of external interface. Even then you probably can. Actually it may be easier for the aplication, too, when you provide something similar to classic file I/O interface - fw_env_open() would initialize the in-memory copy of the environment data, fw_env_write() could be called repeatedly to set or delete variables, one at a time, and fw_env_close() would finally compute the CRC and write the data out to persistent storage. I guess in most cases such an interface is easier for the appli- cation, too, because it can handle variables as they appear, and it does not need to provide yet another array (with all the size limitations) for intermediate storage. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "One planet is all you get." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
On Fri, May 21, 2010 at 1:59 PM, Timur Tabi wrote:
> Is this rounding algorithm the reason why I get output like this:
>
> Clock Configuration:
> CPU0:799.992 MHz, CPU1:799.992 MHz,
> CCB:399.996 MHz,
> DDR:299.997 MHz (599.994 MT/s data rate) (Asynchronous), LBC:25
> MHz
>
> If so, maybe we should fix it?
To answer my own question: yes.
So here's a better version of that function that rounds to the nearest
MHz and is of a proper coding style:
static const unsigned long ics307_clk_freq(unsigned char cw0, unsigned char cw1,
unsigned char cw2)
{
static const u8 s2od[] = {
10, 2, 8, 4, 5, 7, 3, 6
};
unsigned long vdw = (cw1 << 1) | (cw2 >> 7);
unsigned long rdw = cw2 & 0x7f;
unsigned long od = s2od[cw0 & 0x7];
unsigned long freq;
freq = 2 * CONFIG_ICS307_REFCLK_HZ * (vdw + 8) / ((rdw + 2) * od);
/* Round freq to the nearest MHz */
freq += 50;
freq /= 100;
freq *= 100;
debug("ICS307: CW[0-2]: %02X %02X %02X => %lu Hz\n", cw0, cw1, cw2,
freq);
return freq;
}
And the result:
Clock Configuration:
CPU0:800 MHz, CPU1:800 MHz,
CCB:400 MHz,
DDR:300 MHz (600 MT/s data rate) (Asynchronous), LBC:25 MHz
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Dear Timur Tabi, In message you wrote: > > So here's a better version of that function that rounds to the nearest > MHz and is of a proper coding style: Why do we need that? > And the result: > > Clock Configuration: >CPU0:800 MHz, CPU1:800 MHz, >CCB:400 MHz, >DDR:300 MHz (600 MT/s data rate) (Asynchronous), LBC:25 MHz The result looks ugly (why do we have double spaces after the numbers?, why do the numbers not align vertically?). This makes me wonder why you use a "%-4s" format in arch/powerpc/cpu/mpc8?xx/cpu.c - may I recommend changing this into "%s" (if you don't care about vertical alignment), or something like "%4s" else? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is surely a great calamity for a human being to have no ob- sessions.- Robert Bly ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Wolfgang Denk wrote:
>> So here's a better version of that function that rounds to the nearest
>> MHz and is of a proper coding style:
>
> Why do we need that?
Um, because you complained about it?
>> > +static unsigned long ics307_clk_freq(unsigned char cw0, unsigned char cw1,
>> > + unsigned char cw2)
>> > +{
>> > + const unsigned long InputFrequency = CONFIG_ICS307_REFCLK_HZ;
>> > + unsigned long VDW = ((cw1 << 1) & 0x1FE) + ((cw2 >> 7) & 1);
>> > + unsigned long RDW = cw2 & 0x7F;
>> > + unsigned long OD = ics307_S_to_OD[cw0 & 0x7];
>> > + unsigned long freq;
> Please do not use any CamelCase or UPPER CASE identifiers.
^^
Also, because this is silly:
Clock Configuration:
CPU0:799.992 MHz, CPU1:799.992 MHz,
CCB:399.996 MHz,
DDR:299.997 MHz (599.994 MT/s data rate) (Asynchronous), LBC:25 MHz
Why display 799.992 MHZ when 800 MHz makes more sense?
>> Clock Configuration:
>>CPU0:800 MHz, CPU1:800 MHz,
>>CCB:400 MHz,
>>DDR:300 MHz (600 MT/s data rate) (Asynchronous), LBC:25 MHz
>
> The result looks ugly (why do we have double spaces after the
> numbers?, why do the numbers not align vertically?).
> This makes me wonder why you use a "%-4s" format in
> arch/powerpc/cpu/mpc8?xx/cpu.c - may I recommend changing this into
> "%s" (if you don't care about vertical alignment), or something like
> "%4s" else?
I'm okay with that.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix "par[t]ition" typo.
Signed-off-by: Wolfgang Denk
---
common/cmd_flash.c|6 +++---
common/cmd_nand.c |2 +-
doc/README.JFFS2_NAND |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/common/cmd_flash.c b/common/cmd_flash.c
index 3773412..6361c4e 100644
--- a/common/cmd_flash.c
+++ b/common/cmd_flash.c
@@ -34,7 +34,7 @@
#if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
#include
-/* parition handling routines */
+/* partition handling routines */
int mtdparts_init(void);
int mtd_id_parse(const char *id, const char **ret_id, u8 *dev_type, u8
*dev_num);
int find_dev_and_part(const char *id, struct mtd_device **dev,
@@ -368,7 +368,7 @@ int do_flerase (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
addr_first = part->offset + info->start[0];
addr_last = addr_first + part->size - 1;
- printf ("Erase Flash Parition %s, "
+ printf ("Erase Flash Partition %s, "
"bank %ld, 0x%08lx - 0x%08lx ",
argv[1], bank, addr_first,
addr_last);
@@ -576,7 +576,7 @@ int do_protect (cmd_tbl_t *cmdtp, int flag, int argc, char
*argv[])
addr_first = part->offset + info->start[0];
addr_last = addr_first + part->size - 1;
- printf ("%sProtect Flash Parition %s, "
+ printf ("%sProtect Flash Partition %s, "
"bank %ld, 0x%08lx - 0x%08lx\n",
p ? "" : "Un", argv[1],
bank, addr_first, addr_last);
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 9b0c930..f611fd7 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -19,7 +19,7 @@
#if defined(CONFIG_CMD_MTDPARTS)
-/* parition handling routines */
+/* partition handling routines */
int mtdparts_init(void);
int id_parse(const char *id, const char **ret_id, u8 *dev_type, u8 *dev_num);
int find_dev_and_part(const char *id, struct mtd_device **dev,
diff --git a/doc/README.JFFS2_NAND b/doc/README.JFFS2_NAND
index 2b3326b..5018ae8 100644
--- a/doc/README.JFFS2_NAND
+++ b/doc/README.JFFS2_NAND
@@ -5,7 +5,7 @@ To ebable, use the following #define in the board configuration
file:
#define CONFIG_JFFS2_NAND 1
Configuration of partitions is similar to how this is done in U-Boot
-for JFFS2 on top NOR flash. If a single parition is used, it can be
+for JFFS2 on top NOR flash. If a single partition is used, it can be
configured using the following #defines in the configuration file:
#define CONFIG_JFFS2_NAND_DEV 0/* nand device jffs2
lives on */
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Dear Timur Tabi, In message <4bf6e5df.5020...@freescale.com> you wrote: > > >> So here's a better version of that function that rounds to the nearest > >> MHz and is of a proper coding style: > > > > Why do we need that? > > Um, because you complained about it? I mean, why do we need that function? strmhz() already includes rounding. Are you really rounding, or cutting off precsion? > Also, because this is silly: > > Clock Configuration: >CPU0:799.992 MHz, CPU1:799.992 MHz, >CCB:399.996 MHz, >DDR:299.997 MHz (599.994 MT/s data rate) (Asynchronous), LBC:25 MHz > > Why display 799.992 MHZ when 800 MHz makes more sense? Hm... does it really make more sense? Or is it just less precise, or do you hush up an error? 799.992 MHz seems to be 24 * 33,333,000 Hz. Are you sure this is the exact quartz frequency on your board? If yes, then the number printed should probably remain 799.992 MHz. Or is it 33,333,333 Hz? Or 33,000,000 ? > >> Clock Configuration: > >>CPU0:800 MHz, CPU1:800 MHz, > >>CCB:400 MHz, > >>DDR:300 MHz (600 MT/s data rate) (Asynchronous), LBC:25 MHz > > > > The result looks ugly (why do we have double spaces after the > > numbers?, why do the numbers not align vertically?). > > > This makes me wonder why you use a "%-4s" format in > > arch/powerpc/cpu/mpc8?xx/cpu.c - may I recommend changing this into > > "%s" (if you don't care about vertical alignment), or something like > > "%4s" else? > > I'm okay with that. Fine. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You can fool some of the people all of the time, and You can fool all of the people some of the time, but You can't fool mom. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull Request for imx
Dear Stefano Babic, In message <4bf394ae.10...@denx.de> you wrote: > Wolfgang, > > could you pull u-boot-imx in the time Tom is not available ? Tom has > already merged most of the patches in u-boot-arm, I resend you the > pull-request for completeness: > > The following changes since commit ab92d0fd9abd0d4726878a80c6baf3a0f94770b8: > Wolfgang Denk (1): > Merge branch 'master' of git://git.denx.de/u-boot-mpc83xx > > are available in the git repository at: > > git://git.denx.de/u-boot-imx master > > Anatolij Gustschin (1): > tx25: fix crash while booting Linux > > Fabio Estevam (1): > MX51: Fix MX51 CPU detect message > > Magnus Lilja (1): > i.MX31: Activate NAND support for i.MX31 Litekit board. > > Stefano Babic (8): > MX51evk: Removed warnings > MX: Added Freescale Power Management Driver > MX: RTC13783 uses general function to access PMIC > MX31: Add support for PMIC to the QONG module > SPI: added support for MX51 to mxc_spi > MX: Added definition file for MC13892 > Add SPI support to mx51evk board > MX31: Added support for the Casio COM57H5M10XRC to QONG > > arch/arm/cpu/arm_cortexa8/mx51/soc.c |2 +- > board/davedenx/qong/qong.c | 20 +++ > board/freescale/mx51evk/mx51evk.c| 143 +- > board/karo/tx25/tx25.c |3 + > drivers/misc/Makefile|1 + > drivers/misc/fsl_pmic.c | 200 + > drivers/rtc/mc13783-rtc.c| 72 +++- > drivers/spi/mxc_spi.c| 231 > +++--- > drivers/video/mx3fb.c| 47 +--- > include/configs/imx31_litekit.h | 19 +++- > include/configs/mx31ads.h|8 +- > include/configs/mx31pdk.h|9 +- > include/configs/mx51evk.h| 15 +++ > include/configs/qong.h | 16 +++- > include/fsl_pmic.h | 128 +++ > include/mc13892.h| 160 +++ > 16 files changed, 967 insertions(+), 107 deletions(-) > create mode 100644 drivers/misc/fsl_pmic.c > create mode 100644 include/fsl_pmic.h > create mode 100644 include/mc13892.h Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Writing a book is like washing an elephant: there's no good place to begin or end, and it's hard to keep track of what you've already covered. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Capability to select from more than one kernel to boot ?
On Fri, 21 May 2010 17:35:58 +0100 Ayewin Oung wrote: > Hi list > > I like to make Linux kernel "updates" robust to user/power failurer, during > the porcess. > > Is there a well accepted way to do this for u-boot? using some form of file > system (ubifs, jffs2, etc ?) with u-boot where kernel is stored etc etc.. > > Any pointers much appreciated. this is covered in the FAQ: http://www.denx.de/wiki/view/DULG/HowCanIImplementAutomaticSoftwareUpdates Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Fixed two typos in arch/powerpc/cpu/mpc83xx/start.S.
On Tue, 18 May 2010 10:37:05 +0200 Horst Kronstorfer wrote: > > Signed-off-by: Horst Kronstorfer > --- applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi/master
Dear Stefan Roese, In message <201005191058.49502...@denx.de> you wrote: > The following changes since commit a2a0a7171303de5d8ce099344efde2e29ee36eb0: > > Makefile: fix out-of-tree building of "u-boot.img" target (2010-05-16 > 02:18:38 +0200) > > are available in the git repository at: > git://www.denx.de/git/u-boot-ubi.git master > > Stefan Roese (2): > UBI: Ensure that "background thread" operations are really executed > UBI: Fix problem in UBI/Linux "compatibility layer" > > drivers/mtd/ubi/wl.c |9 +++-- > include/ubi_uboot.h |2 +- > 2 files changed, 8 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A committee is a life form with six or more legs and no brain. -- Lazarus Long, "Time Enough For Love" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks in cpu_init.c
On Wed, 19 May 2010 17:06:46 -0500 Kim Phillips wrote: > commit c7190f028fa950d4d36b6d0b4bb3fc72602ec54c "mpc83xx: > retain POR values of non-configured ACR, SPCR, SCCR, and LCRR > bitfields" incorrectly shifted _ (e.g. > ACR_PIPE_DEP) values that were preshifted by their > definition in mpc83xx.h. > > this patch removes the unnecessary shifting for the newly > utilized mask values in cpu_init.c, and prevents seemingly > unrelated symptoms such as an mpc8379erdb board from > locking up whilst performing a networking operation, > e.g. a tftp. > > Signed-off-by: Kim Phillips > --- applied. Thanks, Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Wolfgang Denk wrote: > 799.992 MHz seems to be 24 * 33,333,000 Hz. Are you sure this is the > exact quartz frequency on your board? If yes, then the number printed > should probably remain 799.992 MHz. Or is it 33,333,333 Hz? Or > 33,000,000 ? Ok, I see your point. Technically, I am returning a less precise number. However, the current code adds a 1 to the result, which is definitely wrong. On my board, for example, it returns 9001, which is not correct. So the existing "rounding" algorithm is broken. However, I believe that displaying 799.999 MHz instead of 800 MHz is silly. The problem is that strmhz() rounds to the nearest KHz. I wonder if that's really useful. Perhaps we should make it act more like print_size(), where it prints KHz, MHz, or GHz as appropriate, and rounds to the nearest 10th, instead of 1000th. -- Timur Tabi Linux kernel developer at Freescale ___ 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-mpc83xx.git
Wolfgang, please pull one cpu init fix, and a typo fix*: The following changes since commit 2f05e394fccf62a4693c6b8323de725f90d1f003: fsl_diu_fb.c: fix build warnings (2010-05-17 23:34:18 +0200) are available in the git repository at: git://git.denx.de/u-boot-mpc83xx.git master Horst Kronstorfer (1): Fixed two typos in arch/powerpc/cpu/mpc83xx/start.S. Kim Phillips (1): mpc83xx: don't shift pre-shifted ACR, SPCR, SCCR bitfield masks in cpu_init.c arch/powerpc/cpu/mpc83xx/cpu_init.c | 36 +- arch/powerpc/cpu/mpc83xx/start.S|4 +- 2 files changed, 20 insertions(+), 20 deletions(-) Thanks, Kim * if you prefer these go into mpc83xx' next branch, we can do that, too. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-marvell.git
Dear Prafulla Wadaskar, In message you wrote: > Hi Tom > > Pls pull > > The following changes since commit 0cf7d2440e1aa91ca65f1fc08ba309184d376da6: > Stefano Babic (1): > Add SPI support to mx51evk board > > are available in the git repository at: > > u-boot-marvell.git master branch > > Mahavir Jain (1): > bugfix: Guruplug: Use standard miiphy > > board/Marvell/guruplug/guruplug.c |9 + > 1 files changed, 1 insertions(+), 8 deletions(-) I'm jumping in here as Tom is currently unavailable. I cherry-picked this commit; I did not pull as this would also bing in an update to arch/arm/include/asm/mach-types.h for which I haven't seen a pull request yet. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Q: Why do mountain climbers rope themselves together? A: To prevent the sensible ones from going home. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] fsl/85xx: add clkdvdr and pmuxcr2 to global utilities structure definition
Dear Timur Tabi, In message <1274377539-14922-1-git-send-email-ti...@freescale.com> you wrote: > Add the 'clkdvdr' and 'pmuxcr2' registers to the 85xx definition of > struct ccsr_gur. Please keep the subject line short enought to fit as title of the commit message. Also, it makes little sense to more or less duplicate the same text in the body of the commit message. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Cogito cogito ergo cogito sum - "I think that I think, therefore I think that I am." - Ambrose Bierce, "The Devil's Dictionary" ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Dear Timur Tabi, In message <4bf6ecd0.4060...@freescale.com> you wrote: > > However, the current code adds a 1 to the result, which is definitely wrong. > On my board, for example, it returns 9001, which is not correct. So > the existing "rounding" algorithm is broken. Agreed. > However, I believe that displaying 799.999 MHz instead of 800 MHz is silly. > The problem is that strmhz() rounds to the nearest KHz. I wonder if that's > really useful. Perhaps we should make it act more like print_size(), where Well, the function is "strMHZ", and it prints a frequency in MHz with exactly 3 digits precision - so rounding to the nearest kHz is exactly the right thing to do. > it prints KHz, MHz, or GHz as appropriate, and rounds to the nearest 10th, > instead of 1000th. That would IMHO be less useful, and require changes to MANY boards (essentially all of them) as the output format needs to be adjusted. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "The first rule of magic is simple. Don't waste your time waving your hands and hoping when a rock or a club will do." - McCloctnik the Lucid ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:io.h: define __io() macro if not defined erlier
Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=,
In message <1274259427-29386-1-git-send-email-biessm...@corscience.de> you
wrote:
> This patch adds __io() macro to enable {in|out}[bwl] macros in
> arch/arm/asm/io.h
>
> Commit a45dde2293c816138e53c26eca6fd0322583f9a6 uses {in|out}[bwl]
> macros in
> DM9000x and breaks compilation for arm devices.
>
> Signed-off-by: Andreas Bießmann
> ---
> arch/arm/include/asm/io.h |7 +++
> 1 files changed, 7 insertions(+), 0 deletions(-)
Hm... with this patch applied I see a lot of other warnings:
Configuring for netstar board...
In file included from timer.c:41:
/work/wd/tmp-arm/include2/asm/io.h:209:1: warning: "outb" redefined
In file included from timer.c:40:
/home/wd/git/u-boot/work/include/configs/omap1510.h:784:1: warning: this is the
location of the previous definition
In file included from timer.c:41:
/work/wd/tmp-arm/include2/asm/io.h:210:1: warning: "outw" redefined
In file included from timer.c:40:
/home/wd/git/u-boot/work/include/configs/omap1510.h:785:1: warning: this is the
location of the previous definition
In file included from timer.c:41:
/work/wd/tmp-arm/include2/asm/io.h:211:1: warning: "outl" redefined
In file included from timer.c:40:
/home/wd/git/u-boot/work/include/configs/omap1510.h:786:1: warning: this is the
location of the previous definition
In file included from timer.c:41:
/work/wd/tmp-arm/include2/asm/io.h:213:1: warning: "inb" redefined
In file included from timer.c:40:
/home/wd/git/u-boot/work/include/configs/omap1510.h:788:1: warning: this is the
location of the previous definition
In file included from timer.c:41:
/work/wd/tmp-arm/include2/asm/io.h:214:1: warning: "inw" redefined
In file included from timer.c:40:
/home/wd/git/u-boot/work/include/configs/omap1510.h:789:1: warning: this is the
location of the previous definition
In file included from timer.c:41:
/work/wd/tmp-arm/include2/asm/io.h:215:1: warning: "inl" redefined
In file included from timer.c:40:
/home/wd/git/u-boot/work/include/configs/omap1510.h:790:1: warning: this is the
location of the previous definition
In file included from display_options.c:27:
/work/wd/tmp-arm/include2/asm/io.h:209:1: warning: "outb" redefined
In file included from /home/wd/git/u-boot/work/include/configs/netstar.h:28,
from /work/wd/tmp-arm/include/config.h:4,
from display_options.c:24:
/home/wd/git/u-boot/work/include/configs/omap1510.h:784:1: warning: this is the
location of the previous definition
In file included from display_options.c:27:
/work/wd/tmp-arm/include2/asm/io.h:210:1: warning: "outw" redefined
In file included from /home/wd/git/u-boot/work/include/configs/netstar.h:28,
from /work/wd/tmp-arm/include/config.h:4,
from display_options.c:24:
/home/wd/git/u-boot/work/include/configs/omap1510.h:785:1: warning: this is the
location of the previous definition
In file included from display_options.c:27:
/work/wd/tmp-arm/include2/asm/io.h:211:1: warning: "outl" redefined
In file included from /home/wd/git/u-boot/work/include/configs/netstar.h:28,
from /work/wd/tmp-arm/include/config.h:4,
from display_options.c:24:
/home/wd/git/u-boot/work/include/configs/omap1510.h:786:1: warning: this is the
location of the previous definition
In file included from display_options.c:27:
/work/wd/tmp-arm/include2/asm/io.h:213:1: warning: "inb" redefined
In file included from /home/wd/git/u-boot/work/include/configs/netstar.h:28,
from /work/wd/tmp-arm/include/config.h:4,
from display_options.c:24:
/home/wd/git/u-boot/work/include/configs/omap1510.h:788:1: warning: this is the
location of the previous definition
In file included from display_options.c:27:
/work/wd/tmp-arm/include2/asm/io.h:214:1: warning: "inw" redefined
In file included from /home/wd/git/u-boot/work/include/configs/netstar.h:28,
from /work/wd/tmp-arm/include/config.h:4,
from display_options.c:24:
/home/wd/git/u-boot/work/include/configs/omap1510.h:789:1: warning: this is the
location of the previous definition
In file included from display_options.c:27:
/work/wd/tmp-arm/include2/asm/io.h:215:1: warning: "inl" redefined
In file included from /home/wd/git/u-boot/work/include/configs/netstar.h:28,
from /work/wd/tmp-arm/include/config.h:4,
from display_options.c:24:
/home/wd/git/u-boot/work/include/configs/omap1510.h:790:1: warning: this is the
location of the previous definition
In file included from cfi_flash.c:39:
/work/wd/tmp-arm/include2/asm/io.h:209:1: warning: "outb" redefined
In file included from /home/wd/git/u-boot/work/include/configs/netstar.h:28,
from /work/wd/tmp-arm/include/config.h:4,
from /home/wd/git/u-boot/work/include/common.h:37,
from cfi_flash.c:37:
/home/wd/git/u-boot/work/include/configs/omap1510.h:784:1: warning: this is the
location of the previo
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Wolfgang Denk wrote: > Well, the function is "strMHZ", and it prints a frequency in MHz with > exactly 3 digits precision - so rounding to the nearest kHz is > exactly the right thing to do. Actually, it's not really three significant digits. "799.992" is six significant digits. If you you wanted three, it would have to be "800". See http://en.wikipedia.org/wiki/Significant_figures I guess it's a question of taste, but I don't see how printing "799.992 MHz" is better than "800 MHz". >> it prints KHz, MHz, or GHz as appropriate, and rounds to the nearest 10th, >> instead of 1000th. > > That would IMHO be less useful, and require changes to MANY boards > (essentially all of them) as the output format needs to be adjusted. How about adding a function to strmhz.c that acts like print_size(), and then the caller can choose which one he wants? We could call it print_hz or print_freq. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: */timer.c: fix spelling and vertical alignment
Signed-off-by: Wolfgang Denk
---
arch/arm/cpu/arm1136/mx31/timer.c|2 +-
arch/arm/cpu/arm1136/omap24xx/timer.c| 22 +++---
arch/arm/cpu/arm920t/a320/timer.c|2 +-
arch/arm/cpu/arm926ejs/omap/timer.c |4 ++--
arch/arm/cpu/arm926ejs/versatile/timer.c |4 ++--
arch/arm/cpu/arm_cortexa8/mx51/timer.c |2 +-
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/cpu/arm1136/mx31/timer.c
b/arch/arm/cpu/arm1136/mx31/timer.c
index 7972ba0..b8848c4 100644
--- a/arch/arm/cpu/arm1136/mx31/timer.c
+++ b/arch/arm/cpu/arm1136/mx31/timer.c
@@ -151,7 +151,7 @@ void set_timer (ulong t)
timestamp = time_to_tick(t);
}
-/* delay x useconds AND perserve advance timstamp value */
+/* delay x useconds AND preserve advance timestamp value */
void __udelay (unsigned long usec)
{
unsigned long long tmp;
diff --git a/arch/arm/cpu/arm1136/omap24xx/timer.c
b/arch/arm/cpu/arm1136/omap24xx/timer.c
index 6754749..68fe1b2 100644
--- a/arch/arm/cpu/arm1136/omap24xx/timer.c
+++ b/arch/arm/cpu/arm1136/omap24xx/timer.c
@@ -73,25 +73,25 @@ void set_timer (ulong t)
timestamp = t;
}
-/* delay x useconds AND perserve advance timstamp value */
+/* delay x useconds AND preserve advance timestamp value */
void __udelay (unsigned long usec)
{
ulong tmo, tmp;
- if (usec >= 1000) { /* if "big" number, spread
normalization to seconds */
- tmo = usec / 1000; /* start to normalize for usec
to ticks per sec */
- tmo *= CONFIG_SYS_HZ; /* find number of
"ticks" to wait to achieve target */
- tmo /= 1000;/* finish normalize. */
- } else {/* else small number,
don't kill it prior to HZ multiply */
+ if (usec >= 1000) { /* if "big" number, spread
normalization to seconds */
+ tmo = usec / 1000; /* start to normalize for usec to ticks
per sec */
+ tmo *= CONFIG_SYS_HZ; /* find number of "ticks" to wait to
achieve target */
+ tmo /= 1000;/* finish normalize. */
+ } else {/* else small number, don't kill it
prior to HZ multiply */
tmo = usec * CONFIG_SYS_HZ;
tmo /= (1000*1000);
}
tmp = get_timer (0);/* get current timestamp */
- if ( (tmo + tmp + 1) < tmp )/* if setting this forward will roll time
stamp */
+ if ( (tmo + tmp + 1) < tmp )/* if setting this forward will roll
time stamp */
reset_timer_masked (); /* reset "advancing" timestamp to 0,
set lastinc value */
else
- tmo += tmp; /* else, set advancing
stamp wake up time */
+ tmo += tmp; /* else, set advancing stamp wake up
time */
while (get_timer_masked () < tmo)/* loop till event */
/*NOP*/;
}
@@ -100,16 +100,16 @@ void reset_timer_masked (void)
{
/* reset time */
lastinc = READ_TIMER; /* capture current incrementer value
time */
- timestamp = 0; /* start "advancing" time stamp
from 0 */
+ timestamp = 0; /* start "advancing" time stamp from 0
*/
}
ulong get_timer_masked (void)
{
ulong now = READ_TIMER; /* current tick value */
- if (now >= lastinc) /* normal mode (non roll) */
+ if (now >= lastinc) /* normal mode (non roll) */
timestamp += (now - lastinc); /* move stamp fordward with
absoulte diff ticks */
- else/* we have rollover of
incrementer */
+ else/* we have rollover of incrementer */
timestamp += (0x - lastinc) + now;
lastinc = now;
return timestamp;
diff --git a/arch/arm/cpu/arm920t/a320/timer.c
b/arch/arm/cpu/arm920t/a320/timer.c
index bb65593..d69dbff 100644
--- a/arch/arm/cpu/arm920t/a320/timer.c
+++ b/arch/arm/cpu/arm920t/a320/timer.c
@@ -155,7 +155,7 @@ void set_timer(ulong t)
timestamp = t;
}
-/* delay x useconds AND perserve advance timstamp value */
+/* delay x useconds AND preserve advance timestamp value */
void udelay(unsigned long usec)
{
long tmo = usec * (TIMER_CLOCK / 1000) / 1000;
diff --git a/arch/arm/cpu/arm926ejs/omap/timer.c
b/arch/arm/cpu/arm926ejs/omap/timer.c
index 2ac38c4..7d4b6e6 100644
--- a/arch/arm/cpu/arm926ejs/omap/timer.c
+++ b/arch/arm/cpu/arm926ejs/omap/timer.c
@@ -79,14 +79,14 @@ void set_timer (ulong t)
timestamp = t;
}
-/* delay x useconds AND perserve advance timstamp value */
+/* delay x useconds AND preserve advance timestamp value */
void __udelay (unsigned long usec)
{
ulong tmo, tmp;
if(usec >= 1000){
[U-Boot] [PATCH] a320evb: fix udelay / __udelay confusion
Fix the following compiler problems:
arch/arm/cpu/arm920t/a320/liba320.a(timer.o): In function `udelay':
/home/wd/git/u-boot/work/arch/arm/cpu/arm920t/a320/timer.c:160: multiple
definition of `udelay'
lib/libgeneric.a(time.o):/home/wd/git/u-boot/work/lib/time.c:34: first defined
here
lib/libgeneric.a(time.o): In function `udelay':
time.c:(.text+0x1c): undefined reference to `__udelay'
Signed-off-by: Wolfgang Denk
---
arch/arm/cpu/arm920t/a320/timer.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/arm920t/a320/timer.c
b/arch/arm/cpu/arm920t/a320/timer.c
index d69dbff..d2e316f 100644
--- a/arch/arm/cpu/arm920t/a320/timer.c
+++ b/arch/arm/cpu/arm920t/a320/timer.c
@@ -156,7 +156,7 @@ void set_timer(ulong t)
}
/* delay x useconds AND preserve advance timestamp value */
-void udelay(unsigned long usec)
+void __udelay(unsigned long usec)
{
long tmo = usec * (TIMER_CLOCK / 1000) / 1000;
unsigned long now, last = readl(&tmr->timer3_counter);
--
1.6.6.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] config.mk: use different host compiler for OS X 10.6
Compiling tools subdirectory on Mac OS X 10.6 (Snow Leopard) complains about wrong syntax in system includes. In file included from /usr/include/stdio.h:444, from /Users/andreas/Documents/source/u-boot/include/compiler.h:26, from /Users/andreas/Documents/source/u-boot/lib/crc32.c:15: /usr/include/secure/_stdio.h:46: error: syntax error in macro parameter list This can be fixed by reverting the workaround for prior OS X releases in config.mk conditionally for OS X 10.6 (and maybe above, but this is not covered by this patch). Signed-off-by: Andreas Bießmann --- config.mk | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/config.mk b/config.mk index 73b5195..be8e895 100644 --- a/config.mk +++ b/config.mk @@ -64,9 +64,19 @@ HOSTSTRIP= strip # ifeq ($(HOSTOS),darwin) +# get major and minor product version (e.g. 10.6 for Snow Leopard) +DARWIN_VERSION = $(shell sw_vers -productVersion | cut -f 1,2 -d '.') + +# Snow Leopards build environmenthas no longer restrictions as described above +# TODO find a solution to match versions greater than 10.6 +ifeq ($(DARWIN_VERSION),10.6) +HOSTCC = gcc +else HOSTCC = cc HOSTCFLAGS += -traditional-cpp HOSTLDFLAGS+= -multiply_defined suppress +endif + else HOSTCC = gcc endif -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
On May 21, 2010, at 10:57 AM, Timur Tabi wrote:
> On Fri, May 21, 2010 at 4:18 AM, Kumar Gala wrote:
>
>> +#ifdef CONFIG_FSL_NGPIXIS
>> +#include "ngpixis.h"
>> +#define PIXIS_VSYSCLK0 offsetof(struct ngpixis, sclk[0])
>> +#define PIXIS_VSYSCLK1 offsetof(struct ngpixis, sclk[1])
>> +#define PIXIS_VSYSCLK2 offsetof(struct ngpixis, sclk[2])
>> +#define PIXIS_VDDRCLK0 offsetof(struct ngpixis, dclk[0])
>> +#define PIXIS_VDDRCLK1 offsetof(struct ngpixis, dclk[1])
>> +#define PIXIS_VDDRCLK2 offsetof(struct ngpixis, dclk[2])
>> +#endif
>
> Yuck. I specifically created the ngpixis_t structure because Wolfgang
> objected to the use of macros for offsets.
>
> But I understand why you did it. It's the easiest way to maintain
> compatibility between pixis and ngpixis.
>
>> +/* decode S[0-2] to Output Divider (OD) */
>> +static unsigned char ics307_s_to_od[] = {
>> + 10, 2, 8, 4, 5, 7, 3, 6
>> +};
>
> Can you make this a u8 instead?
>
>> +static unsigned long
>> +ics307_clk_freq(unsigned char cw0, unsigned char cw1, unsigned char cw2)
>
> u8's here, also. You might then be able to make this one line.
will make this change.
>> +{
>> + const unsigned long input_freq = CONFIG_ICS307_REFCLK_HZ;
>> + unsigned long VDW = ((cw1 << 1) & 0x1FE) + ((cw2 >> 7) & 1);
>> + unsigned long RDW = cw2 & 0x7F;
>> + unsigned long OD = ics307_s_to_od[cw0 & 0x7];
>> + unsigned long freq;
>
> Wolfgang just asked me not to use camel caps.
where are there camel caps?
>
>> +#ifndef __ASSEMBLY__
>> +extern unsigned long get_board_sys_clk(void);
>> +extern unsigned long get_board_ddr_clk(void);
>> +#endif
>
> I don't think we need the "#ifndef __ASSEMBLY__" here.
We do.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
On May 21, 2010, at 10:57 AM, Timur Tabi wrote: > On Fri, May 21, 2010 at 4:18 AM, Kumar Gala wrote: > >> +#ifdef CONFIG_FSL_NGPIXIS >> +#include "ngpixis.h" >> +#define PIXIS_VSYSCLK0 offsetof(struct ngpixis, sclk[0]) >> +#define PIXIS_VSYSCLK1 offsetof(struct ngpixis, sclk[1]) >> +#define PIXIS_VSYSCLK2 offsetof(struct ngpixis, sclk[2]) >> +#define PIXIS_VDDRCLK0 offsetof(struct ngpixis, dclk[0]) >> +#define PIXIS_VDDRCLK1 offsetof(struct ngpixis, dclk[1]) >> +#define PIXIS_VDDRCLK2 offsetof(struct ngpixis, dclk[2]) >> +#endif > > Yuck. I specifically created the ngpixis_t structure because Wolfgang > objected to the use of macros for offsets. > > But I understand why you did it. It's the easiest way to maintain > compatibility between pixis and ngpixis. Wolfgang, is this an issue? The other option is have 3 different structs: On p2020: #define PIXIS_VSYSCLK0 offsetof(struct ngpixis, sclk[0]) on 8572: #define PIXIS_VSYSCLK00x1C on 8536: #define PIXIS_VSYSCLK00x1A - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Dear Kumar Gala,
In message you wrote:
>
> >> +{
> >> + const unsigned long input_freq = CONFIG_ICS307_REFCLK_HZ;
> >> + unsigned long VDW = ((cw1 << 1) & 0x1FE) + ((cw2 >> 7) & 1);
> >> + unsigned long RDW = cw2 & 0x7F;
> >> + unsigned long OD = ics307_s_to_od[cw0 & 0x7];
> >> + unsigned long freq;
> >
> > Wolfgang just asked me not to use camel caps.
>
> where are there camel caps?
There aren't. But we do not allow for ALLCAPS identifiers either
(these are reserved for macro names).
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Behind every great man, there is a woman -- urging him on.
-- Harry Mudd, "I, Mudd", stardate 4513.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Move ICS CLK chip frequenty calculation code into a common board library
Dear Kumar Gala,
In message <7e86bc8f-7e3f-49b1-b1c5-b21991303...@kernel.crashing.org> you wrote:
>
> wrote:
> >
> >> +#ifdef CONFIG_FSL_NGPIXIS
> >> +#include "ngpixis.h"
> >> +#define PIXIS_VSYSCLK0 offsetof(struct ngpixis, sclk[0])
> >> +#define PIXIS_VSYSCLK1 offsetof(struct ngpixis, sclk[1])
> >> +#define PIXIS_VSYSCLK2 offsetof(struct ngpixis, sclk[2])
> >> +#define PIXIS_VDDRCLK0 offsetof(struct ngpixis, dclk[0])
> >> +#define PIXIS_VDDRCLK1 offsetof(struct ngpixis, dclk[1])
> >> +#define PIXIS_VDDRCLK2 offsetof(struct ngpixis, dclk[2])
> >> +#endif
> >
> > Yuck. I specifically created the ngpixis_t structure because Wolfgang
> > objected to the use of macros for offsets.
> >
> > But I understand why you did it. It's the easiest way to maintain
> > compatibility between pixis and ngpixis.
>
> Wolfgang, is this an issue?
This, in itself, it not an issue.
The issue comes when you wrote code like this:
+ return ics307_clk_freq (
+ in_8(pixis_base + PIXIS_VSYSCLK0),
+ in_8(pixis_base + PIXIS_VSYSCLK1),
+ in_8(pixis_base + PIXIS_VSYSCLK2)
+ );
+}
+
+unsigned long get_board_ddr_clk(void)
+{
+ u8 *pixis_base = (u8 *)PIXIS_BASE;
+
+ return ics307_clk_freq (
+ in_8(pixis_base + PIXIS_VDDRCLK0),
+ in_8(pixis_base + PIXIS_VDDRCLK1),
+ in_8(pixis_base + PIXIS_VDDRCLK2)
+ );
This clearly gets a NAK because you should use a struct, and not base
address + offset notation.
> The other option is have 3 different structs:
>
> On p2020: #define PIXIS_VSYSCLK0 offsetof(struct ngpixis, > sclk[0])
> on 8572: #define PIXIS_VSYSCLK0 0x1C
> on 8536: #define PIXIS_VSYSCLK0 0x1A
I see #defines here, no structs.
I'm not sure if you need different structs (haven't looked into
these), or if clever notation of the struct is sufficient.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A committee is a life form with six or more legs and no brain.
-- Lazarus Long, "Time Enough For Love"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] x86 Custodianship
Hi Wolfgang, On 22/05/10 01:11, Wolfgang Denk wrote: > Dear Graeme Russ, [snip] > No need to. The x86 repo is ready for you. > Thanks Wolfgang One quick question - Since I am currently the only x86 developer, how do you want to handle the SOB + Ack'd for x86 patches? I feel that to date be applying my patches you have implied your own Ack'd By. Should I wait for you (or somebody else) to Ack them before I apply them to the x86 repo? I am more than happy (and would prefer) my patches to remain out of the x86 repo until formally Ack'd Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] config.mk: use different host compiler for OS X 10.6
On Friday 21 May 2010 17:33:14 Andreas Bießmann wrote: > ifeq ($(HOSTOS),darwin) > +# get major and minor product version (e.g. 10.6 for Snow Leopard) > +DARWIN_VERSION = $(shell sw_vers -productVersion | cut -f 1,2 -d '.') > + > +# Snow Leopards build environmenthas no longer restrictions as described > above +# TODO find a solution to match versions greater than 10.6 > +ifeq ($(DARWIN_VERSION),10.6) > +HOSTCC = gcc > +else > HOSTCC = cc > HOSTCFLAGS += -traditional-cpp > HOSTLDFLAGS += -multiply_defined suppress > +endif presumably this is going to remain true with 10.7+, so it'd probably make more sense to invert the check ... have the old code run with <=10.5 -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request u-boot-marvell.git
> -Original Message- > From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Saturday, May 22, 2010 2:02 AM > To: Prafulla Wadaskar > Cc: Tom Rix; u-boot@lists.denx.de > Subject: Re: [U-Boot] Pull request u-boot-marvell.git > > Dear Prafulla Wadaskar, > > In message > com> you wrote: > > Hi Tom > > > > Pls pull > > > > The following changes since commit > 0cf7d2440e1aa91ca65f1fc08ba309184d376da6: > > Stefano Babic (1): > > Add SPI support to mx51evk board > > > > are available in the git repository at: > > > > u-boot-marvell.git master branch > > > > Mahavir Jain (1): > > bugfix: Guruplug: Use standard miiphy > > > > board/Marvell/guruplug/guruplug.c |9 + > > 1 files changed, 1 insertions(+), 8 deletions(-) > > I'm jumping in here as Tom is currently unavailable. > > I cherry-picked this commit; I did not pull as this would also bing in > an update to arch/arm/include/asm/mach-types.h for which I haven't > seen a pull request yet. Thanks Wolfgang For picking this patch. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
