Re: [U-Boot] [PATCH V2 1/1] imximage.cfg: run files through C preprocessor
Hi Troy, On Thu, 17 Jan 2013 18:49:59 -0700, Troy Kisky troy.ki...@boundarydevices.com wrote: The '#' used as comments in the files cause the preprocessor trouble, so change to /* */. This seems incomplete -- there's also a change to .gitignore regarding *.cfgtmp. For the sake of completeness, can you add a note in the commit message about it? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/15] km82xx, km83xx: move ethernet_present() from common to cpu specific
On 01/18/2013 01:23 AM, Kim Phillips wrote:
On Thu, 17 Jan 2013 13:47:50 +0100
Holger Brunck holger.bru...@keymile.com wrote:
+int piggy_present(void)
+{
+struct km_bec_fpga *base =
+(struct km_bec_fpga *)CONFIG_SYS_KMBEC_FPGA_BASE;
+
+return in_8(base-bprth) PIGGY_PRESENT;
+}
this change produces two new sparse warnings:
km83xx.c:137:22: warning: incorrect type in argument 1 (different address
spaces)
km83xx.c:137:22:expected unsigned char const volatile [noderef]
asn:2*addr
km83xx.c:137:22:got unsigned char *noident
km83xx.c:132:5: warning: symbol 'piggy_present' was not declared. Should it
be static?
so make the function static, and add __iomem annotation to the
assignment of 'base'.
ok will do. Just out of curiosity which compiler throws these warnings? I use
powerpc-gcc (GCC) 4.7.2 and don't see them.
Anyway I send a v2 for this patch.
Regards
Holger
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/5] Initial IPv6 support
Hi Chris, On Fri, 18 Jan 2013 14:35:27 +1300, Chris Packham judge.pack...@gmail.com wrote: From: Chris Packham chris.pack...@alliedtelesis.co.nz This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses. As a general comment, I heartily welcome IPv6 support (even though I suspect there is quite a lot to be done on it, if only configuration), but I wonder how this fits in with the general line of not adding dead code in U-Boot. Will we make an exception for IPv6 and accept this RFC once it is officially submitted? Or do we collect small, reviewable RFCs for various IPv6 aspects but apply them in one go? Or do we create a branch or tree where IPv6 will get integrated step by step until solid enough for mainline inclusion? Or was this decided already and I missed it? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Flash Not Erased Problem with M29W128GL
Hi Angelo, Still having problem. Can I have your flash_cfi.c code file? Thanks Regards, Ramesj -Original Message- From: Angelo Dureghello [mailto:sysa...@gmail.com] Sent: Wednesday, January 16, 2013 3:56 PM To: u-boot@lists.denx.de Cc: Ramesh K Khokhani Subject: Re: [U-Boot] Flash Not Erased Problem with M29W128GL Dear Ramesh, i am running last u-boot (pulled yesterday) on a coldfire m5307 and a SST 16bit flash, erasing works fine. From your debug trace seems the correct erasing command (0x30) is sent. But the function you mentioned detect that flash is not erased. Are you using a 16bit port for data connection to the flash ? First check i would do is an erase test. Try to erase some sectors with erase command, something like # erase 4 4 Then dump the memory, (to be sure also with BDM eventually), to see if it has really been erased. Also, these are some settings i am using in my config, maybe they can be useful: /* * Start addresses for the final memory configuration * (Set up by the startup code) * Please note that CONFIG_SYS_SDRAM_BASE _must_ start at 0 */ #define CONFIG_SYS_SDRAM_BASE 0x #define CONFIG_SYS_SDRAM_SIZE 16 /* in MB */ #define CONFIG_SYS_FLASH_BASE 0xffc0 #define CONFIG_SYS_TEXT_BASE0xffc0 #define CONFIG_SYS_MAX_FLASH_BANKS 1 #define CONFIG_SYS_MAX_FLASH_SECT 1024 #define CONFIG_SYS_FLASH_ERASE_TOUT 1000 /* * CFI FLASH driver setup */ #define CONFIG_SYS_FLASH_CFI #define CONFIG_FLASH_CFI_DRIVER #define CONFIG_SYS_FLASH_USE_BUFFER_WRITE ... Let us know if you find something. Regards, Angelo ~~Disclaimer~~~ Information contained and transmitted by this e-mail is confidential and proprietary to iGATE and its affiliates and is intended for use only by the recipient. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, copying or use of this e-mail is strictly prohibited and you are requested to delete this e-mail immediately and notify the originator or mailad...@igate.com mailto:mailad...@igate.com. iGATE does not enter into any agreement with any party by e-mail. Any views expressed by an individual do not necessarily reflect the view of iGATE. iGATE is not responsible for the consequences of any actions taken on the basis of information provided, through this email. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. While iGATE has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should carry out your own virus checks before opening an attachment. To know more about iGATE please visit www.igate.com http://www.igate.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Graphics Library?
Alexander Holler wrote: And I think too that all this can be handled by adding a kernel (e.g. with integrated minimal initramfs) to u-boot. At least that is how I have handled such in the past. I agree that graphics (apart from a logo) should be handled outside U-boot proper - my own rationale for this being how essential is this for the primary operation of a bootloader, which is to set the system up for execution of the main payload as quickly as possible ? The bootloader can still manage to provide quick feedback on which kind of boot it is performing, normal or upgrade, for instance by loading a different logo for each case; any message such as please wait for upgrade start can always be designed into the upgrade case logo on a comfy workstation -- preferably with Gimp or Inkscape. :) Regards, Alexander Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v2] powerpc/p5040: enable NAND/SD/SPI boot support
Also update README.pblimage for p5040. Signed-off-by: Shaohui Xie shaohui@freescale.com --- changes for v2: 1. merge NAND/SD/SPI to one patch; 2. update README.pblimage for p5040; boards.cfg |3 +++ doc/README.pblimage |6 +++--- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/boards.cfg b/boards.cfg index e4b0d44..710942f 100644 --- a/boards.cfg +++ b/boards.cfg @@ -855,6 +855,9 @@ P5020DS_SECURE_BOOT powerpc mpc85xx corenet_ds freesca P5020DS_SPIFLASHpowerpc mpc85xx corenet_ds freescale - P5020DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 P5020DS_SRIO_PCIE_BOOT powerpc mpc85xx corenet_ds freescale - P5020DS:SRIO_PCIE_BOOT_SLAVE,SYS_TEXT_BASE=0xFFF8 P5040DS powerpc mpc85xx corenet_ds freescale +P5040DS_NANDpowerpc mpc85xx corenet_ds freescale - P5040DS:RAMBOOT_PBL,NAND,SYS_TEXT_BASE=0xFFF8 +P5040DS_SDCARD powerpc mpc85xx corenet_ds freescale - P5040DS:RAMBOOT_PBL,SDCARD,SYS_TEXT_BASE=0xFFF8 +P5040DS_SPIFLASHpowerpc mpc85xx corenet_ds freescale - P5040DS:RAMBOOT_PBL,SPIFLASH,SYS_TEXT_BASE=0xFFF8 BSC9131RDB_SPIFLASH powerpc mpc85xx bsc9131rdb freescale - BSC9131RDB:BSC9131RDB,SPIFLASH stxgp3 powerpc mpc85xx stxgp3 stx stxssa powerpc mpc85xx stxssa stx - stxssa diff --git a/doc/README.pblimage b/doc/README.pblimage index 2b9bb5c..bbf7658 100644 --- a/doc/README.pblimage +++ b/doc/README.pblimage @@ -14,17 +14,17 @@ Building PBL Boot Image and boot steps 1. Building PBL Boot Image. The default Image is u-boot.pbl. - For eSPI boot(available on P3041/P4080/P5020): + For eSPI boot(available on P3041/P4080/P5020/P5040): To build the eSPI boot image: make board_name_SPIFLASH_config make u-boot.pbl - For SD boot(available on P3041/P4080/P5020): + For SD boot(available on P3041/P4080/P5020/P5040): To build the SD boot image: make board_name_SDCARD_config make u-boot.pbl - For Nand boot(available on P3041/P5020): + For Nand boot(available on P3041/P5020/P5040): To build the NAND boot image: make board_name_NAND_config make u-boot.pbl -- 1.6.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/15] powerpc/83xx/km: add MV88E6122 switch support for kmvect1
On 01/18/2013 01:44 AM, Kim Phillips wrote:
On Thu, 17 Jan 2013 13:47:51 +0100
Holger Brunck holger.bru...@keymile.com wrote:
+#if defined(CONFIG_KMVECT1)
+#include mv88e6352.h
+/* Marvell MV88E6122 switch configuration */
+struct mv88e_sw_reg extsw_conf[] = {
+/* port 1, FRONT_MDI, autoneg */
+{ PORT(1), PORT_PHY, NO_SPEED_FOR },
+{ PORT(1), PORT_CTRL, FORWARDING | EGRS_FLD_ALL },
+{ PHY(1), PHY_1000_CTRL, NO_ADV },
+{ PHY(1), PHY_SPEC_CTRL, AUTO_MDIX_EN },
+{ PHY(1), PHY_CTRL, PHY_100_MBPS | AUTONEG_EN | AUTONEG_RST |
+FULL_DUPLEX },
+/* port 2, unused */
+{ PORT(2), PORT_CTRL, PORT_DIS },
+{ PHY(2), PHY_CTRL, PHY_PWR_DOWN },
+{ PHY(2), PHY_SPEC_CTRL, SPEC_PWR_DOWN },
+/* port 3, BP_MII (CPU), PHY mode, 100BASE */
+{ PORT(3), PORT_CTRL, FORWARDING | EGRS_FLD_ALL },
+/* port 4, ESTAR to slot 11, SerDes, 1000BASE-X */
+{ PORT(4), PORT_STATUS, NO_PHY_DETECT },
+{ PORT(4), PORT_PHY, SPEED_1000_FOR },
+{ PORT(4), PORT_CTRL, FORWARDING | EGRS_FLD_ALL },
+/* port 5, ESTAR to slot 13, SerDes, 1000BASE-X */
+{ PORT(5), PORT_STATUS, NO_PHY_DETECT },
+{ PORT(5), PORT_PHY, SPEED_1000_FOR },
+{ PORT(5), PORT_CTRL, FORWARDING | EGRS_FLD_ALL },
+/*
+ * Errata Fix: 1.9V Output from Internal 1.8V Regulator,
+ * acc . MV-S300889-00D.pdf , clause 4.5
+ */
+{ PORT(5), 0x1A, 0xADB1 },
+/* port 6, unused, this port has no phy */
+{ PORT(6), PORT_CTRL, PORT_DIS },
+};
+#endif
this chunk introduces a new sparse warning:
km83xx.c:217:21: warning: symbol 'extsw_conf' was not declared. Should it be
static?
Ok. I'll fix this in v2.
int last_stage_init(void)
{
+#if defined(CONFIG_KMVECT1)
+struct km_bec_fpga *base =
+(struct km_bec_fpga *)CONFIG_SYS_KMBEC_FPGA_BASE;
+u8 tmp_reg;
+
+/* Release mv88e6122 from reset */
+tmp_reg = in_8(base-res1[0]) | 0x10; /* DIRECT3 register */
+out_8(base-res1[0], tmp_reg);/* GP28 as output */
+tmp_reg = in_8(base-gprt3) | 0x10; /* GP28 to high */
+out_8(base-gprt3, tmp_reg);
+
+/* configure MV88E6122 switch */
+char *name = UEC2;
+
+if (miiphy_set_current_dev(name))
+return 0;
+
+mv88e_sw_program(name, CONFIG_KM_MVEXTSW_ADDR, extsw_conf,
+ARRAY_SIZE(extsw_conf));
+
+mv88e_sw_reset(name, CONFIG_KM_MVEXTSW_ADDR);
+
+if (piggy_present()) {
+uchar enetaddr[6];
+if (eth_getenv_enetaddr(ethaddr, enetaddr)) {
+/* increment last 3 bytes */
+u32 val = (enetaddr[3] 16) + (enetaddr[4] 8)
++ enetaddr[5];
+val++;
+enetaddr[3] = (val 16) 0xFF;
+enetaddr[4] = (val 8) 0xFF;
+enetaddr[5] = (val 0) 0xFF;
+if (!eth_setenv_enetaddr(eth1addr, enetaddr)) {
+setenv(ethact, UEC2);
+setenv(netdev, eth1);
+puts(using PIGGY for network boot\n);
+} else
+puts(using frontport for network boot\n);
+}
+} else
+puts(using frontport for network boot\n);
+#endif
+
AFAIK, assigning the switch MAC address to the front port's MAC
address plus one isn't acceptable practice for u-boot board code.
Get eth1addr in the same manner ethaddr is obtained/assigned.
Because you may get a MAC adress which is already given to someone else? In our
case this can't happen. We reserve for one instance of this board exactly two
MAC adresses. The first one is read out at startup from the inventory in
keymile/common/ivm.c. The second one is calculated like above. But it is a
unique MAC adress, because exactly this MAC adress is reserved for this board.
But maybe we should move the code to the location where we set ethaddr, even if
the calculation would be the same?
+#if !defined(CONFIG_MPC8309)
#define CONFIG_UEC_ETH1 /* GETH1 */
#define UEC_VERBOSE_DEBUG 1
+#endif
#ifdef CONFIG_UEC_ETH1
-#if defined(CONFIG_MPC8309)
-#define CONFIG_SYS_UEC1_UCC_NUM 2 /* UCC3 */
-#define CONFIG_SYS_UEC1_RX_CLK QE_CLK_NONE /* not used in RMII
Mode */
-#define CONFIG_SYS_UEC1_TX_CLK QE_CLK12
-#else
#define CONFIG_SYS_UEC1_UCC_NUM 3 /* UCC4 */
#define CONFIG_SYS_UEC1_RX_CLK QE_CLK_NONE /* not used in RMII
Mode */
#define CONFIG_SYS_UEC1_TX_CLK QE_CLK17
-#endif
#define CONFIG_SYS_UEC1_ETH_TYPEFAST_ETH
#define CONFIG_SYS_UEC1_PHY_ADDR0
#define CONFIG_SYS_UEC1_INTERFACE_TYPE PHY_INTERFACE_MODE_RMII
how are these changes related?
kmvect1 is a MPC8309 board and the only board in our board serie with this
processor. Without the switch we used more or less the config
Re: [U-Boot] U-Boot Graphics Library?
On 16/01/2013 22:46, Simon Glass wrote: Hi Wolfgang, Hi Simon, This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or? The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop. Well, if a separate OS image can be overwritten, U-Boot image can be overwritten too, and then the board does not boot at all. I provided for a customer a solution with a separate OS and a small rootfs as initramfs, and even if it is theoretically possible to destroy this image, it has the same probability that U-Boot has to disappear. It still seems to me a good solution, with the drawback to use much more resorces (Flash) that a U-Boot solution can use. Anyway, with the current size of NAND flash, even this drawback is not very important in many projects. Maybe more as a GUI-guided recovery, the customer needs a way to rescue the system when everything goes wrong. Providing a booting SD or USB card, that can complete restore the system, seems to be a good way, or at least it was in my case. Implementing it in U-Boot seems to me overkilling, but is only my 2 cents ;-). Best 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/5] Initial IPv6 support
On 01/18/2013 09:20 PM, Albert ARIBAUD wrote: Hi Chris, On Fri, 18 Jan 2013 14:35:27 +1300, Chris Packham judge.pack...@gmail.com wrote: From: Chris Packham chris.pack...@alliedtelesis.co.nz This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses. As a general comment, I heartily welcome IPv6 support (even though I suspect there is quite a lot to be done on it, if only configuration), but I wonder how this fits in with the general line of not adding dead code in U-Boot. Will we make an exception for IPv6 and accept this RFC once it is officially submitted? Or do we collect small, reviewable RFCs for various IPv6 aspects but apply them in one go? Or do we create a branch or tree where IPv6 will get integrated step by step until solid enough for mainline inclusion? Or was this decided already and I missed it? Amicalement, Good question. Basically we have some out of tree code that implements a basic IPv6 stack. I'm drip feeding the code in pieces to avoid just dumping it on people and because the current code wouldn't meet u-boot's standards. Putting my IPv6 promoter hat on I hope that it won't stay dead for long :) Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me. Regards, Chris -- [1] git://github.com/cpackham/u-boot.git ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: resync with Linux-3.7.1
Dear Scott,
could you please test the following patch
on top of this big patch to see if ecc.strength
problem goes away? I can integrate it into big
one then.
From dffea1f073c546ab88f37f219f66d9d1478d4cf1 Mon Sep 17 00:00:00 2001
From: Sergey Lapin sla...@ossfans.org
Date: Thu, 17 Jan 2013 18:29:21 +0400
Subject: [PATCH] SQUASHME: mtd: nand: Add ecc.strength support to drivers
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
drivers/mtd/nand/atmel_nand.c|1 +
drivers/mtd/nand/bfin_nand.c |2 ++
drivers/mtd/nand/davinci_nand.c |1 +
drivers/mtd/nand/diskonchip.c|1 +
drivers/mtd/nand/fsl_elbc_nand.c |6 ++
drivers/mtd/nand/fsl_ifc_nand.c |1 +
drivers/mtd/nand/fsmc_nand.c |2 ++
drivers/mtd/nand/jz4740_nand.c |5 +
drivers/mtd/nand/mxc_nand.c |7 +++
drivers/mtd/nand/mxs_nand.c |1 +
drivers/mtd/nand/nand_base.c |1 +
drivers/mtd/nand/ndfc.c |1 +
drivers/mtd/nand/nomadik.c |1 +
drivers/mtd/nand/omap_gpmc.c |1 +
drivers/mtd/nand/s3c2410_nand.c |1 +
drivers/mtd/nand/s3c64xx.c |1 +
drivers/mtd/nand/tegra_nand.c|1 +
17 files changed, 34 insertions(+)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index b09e7b7..9cdf35b 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -709,6 +709,7 @@ static int atmel_pmecc_nand_init_params(struct nand_chip
*nand,
nand-ecc.read_page = atmel_nand_pmecc_read_page;
nand-ecc.write_page = atmel_nand_pmecc_write_page;
+ nand-ecc.strength = 1;
atmel_pmecc_core_init(mtd);
diff --git a/drivers/mtd/nand/bfin_nand.c b/drivers/mtd/nand/bfin_nand.c
index c7ddbb2..7e755e8 100644
--- a/drivers/mtd/nand/bfin_nand.c
+++ b/drivers/mtd/nand/bfin_nand.c
@@ -374,9 +374,11 @@ int board_nand_init(struct nand_chip *chip)
if (!NAND_IS_512()) {
chip-ecc.bytes = 3;
chip-ecc.size = 256;
+ chip-ecc.strength = 1;
} else {
chip-ecc.bytes = 6;
chip-ecc.size = 512;
+ chip-ecc.strength = 2;
}
chip-ecc.mode = NAND_ECC_HW;
chip-ecc.calculate = bfin_nfc_calculate_ecc;
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 04b24f3..9777878 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -613,6 +613,7 @@ void davinci_nand_init(struct nand_chip *nand)
nand-ecc.mode = NAND_ECC_HW;
nand-ecc.size = 512;
nand-ecc.bytes = 3;
+ nand-ecc.strength = 4;
nand-ecc.calculate = nand_davinci_calculate_ecc;
nand-ecc.correct = nand_davinci_correct_data;
nand-ecc.hwctl = nand_davinci_enable_hwecc;
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 104d97f..4cd741e 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -1658,6 +1658,7 @@ static int __init doc_probe(unsigned long physadr)
nand-ecc.mode = NAND_ECC_HW_SYNDROME;
nand-ecc.size = 512;
nand-ecc.bytes = 6;
+ nand-ecc.strength = 2;
nand-bbt_options = NAND_BBT_USE_FLASH;
doc-physadr= physadr;
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 65edbf5..c3f350d 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -781,6 +781,12 @@ static int fsl_elbc_chip_init(int devnum, u8 *addr)
nand-ecc.size = 512;
nand-ecc.bytes = 3;
nand-ecc.steps = 1;
+ chip-ecc.strength = 1;
+ /*
+* FIXME: can hardware ecc correct 4 bitflips if page size is
+* 2k? Then does hardware report number of corrections for this
+* case? If so, ecc_stats reporting needs to be fixed as well.
+*/
} else {
/* otherwise fall back to default software ECC */
nand-ecc.mode = NAND_ECC_SOFT;
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 5d47b40..823a2eb 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -871,6 +871,7 @@ int board_nand_init(struct nand_chip *nand)
/* Hardware generates ECC per 512 Bytes */
nand-ecc.size = 512;
nand-ecc.bytes = 8;
+ nand-ecc.strength = 1;
switch (csor CSOR_NAND_PGS_MASK) {
case CSOR_NAND_PGS_512:
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 48ca543..fab2aeb 100644
--- a/drivers/mtd/nand/fsmc_nand.c
+++ b/drivers/mtd/nand/fsmc_nand.c
@@ -453,6 +453,7 @@ int fsmc_nand_init(struct nand_chip *nand)
switch (fsmc_version) {
case FSMC_VER8:
Re: [U-Boot] Slow tftp boot with Ubuntu 12.04 tftp server
Try setting the max. blocksize explicit, e.g. I'm using -B 1460 here. It depends on the used tftp-server. Hi Alexander Thanks for your reply. Please will you confirm the exact syntax? I tried: # tftp -B 1460 0x8200 tci6614-evm.dtb tftpboot - boot image via network using TFTP protocol Usage: tftpboot [loadAddress] [[hostIPaddr:]bootfilename] I also tried: setenv tftpblocksize 1460 but that made no difference. What is the correct way of specifying the block size please? David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/5] Initial IPv6 support
On Fri, Jan 18, 2013 at 10:39:29PM +1300, Chris Packham wrote: Putting my IPv6 promoter hat on I hope that it won't stay dead for long :) From my side, IPv6 is long awaited feature by me and various people, so it won't stay dead. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/5] Initial IPv6 support
Dear Chris, In message 1358472932-32083-1-git-send-email-judge.pack...@gmail.com you wrote: This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses. I have a patch for testing these basic things which I haven't included in this series yet. Is there a unittest facility for u-boot I should be using? We use the DUTS ([1], [2]) for all kind of test cases (but note that I don't claim it's easy to get started with it). [1] http://www.denx.de/wiki/DUTS/DUTSDocs [2] http://git.denx.de/?p=duts.git A few open questions 1) Presumably the majority of the actual V6 code would be included by a config option (CONFIG_IPV6). How far should I take that? Should the vsprintf code be conditional? Yes, please. 2) Our current out of tree code parallels net.c and net.h. Should I continue this for the final version or integrate it into net.[ch]. This depends - if such integration can be done nicely, i. e. without too many new #ifdef's, then yes, please. 3) rxhand_f currently takes an IPaddr_t. I haven't looked at the usage of this yet but to support V6 this may need to be a new union or a void *. What exactly is the question here? 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 Microsoft Multimedia: You have nice graphics, sound and animations when the system crashes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/5] Initial IPv6 support
Dear Albert ARIBAUD, In message 20130118092041.0c827374@lilith you wrote: This series so far covers the introduction of a IP6addr_t and printing/parsing of addresses. As a general comment, I heartily welcome IPv6 support (even though I Me too! :-) but I wonder how this fits in with the general line of not adding dead code in U-Boot. Will we make an exception for IPv6 and accept this RFC once it is officially submitted? Or do we collect small, reviewable RFCs for various IPv6 aspects but apply them in one go? Or do we create a branch or tree where IPv6 will get integrated step by step until solid enough for mainline inclusion? Or was this decided already and I missed it? My understanding was that this patch set was for reviewing purposes only (hence RFC). Your dead code hint is absolutely correct: for integration into mainline we need users of the code, i. e. for example DHCP and TFTP support... 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 C++ was an interesting and valuable experiment, but we've learned its lessons and it's time to move on. - Peter Curran in dcqm4z@isgtec.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/82xx/km: removed unneeded ifdef
All boards from this serie uses i2c. So we can drop these unneeded defines. Signed-off-by: Holger Brunck holger.bru...@keymile.com --- board/keymile/km82xx/km82xx.c |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/board/keymile/km82xx/km82xx.c b/board/keymile/km82xx/km82xx.c index 8cf3035..ddf4795 100644 --- a/board/keymile/km82xx/km82xx.c +++ b/board/keymile/km82xx/km82xx.c @@ -31,10 +31,7 @@ #include libfdt.h #endif -#if defined(CONFIG_HARD_I2C) || defined(CONFIG_SOFT_I2C) #include i2c.h -#endif - #include ../common/common.h /* -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] powerpc/82xx/km: make handle_mgcoge3un_reset static
Signed-off-by: Holger Brunck holger.bru...@keymile.com
---
board/keymile/km82xx/km82xx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/keymile/km82xx/km82xx.c b/board/keymile/km82xx/km82xx.c
index 67b69f6..8cf3035 100644
--- a/board/keymile/km82xx/km82xx.c
+++ b/board/keymile/km82xx/km82xx.c
@@ -370,7 +370,7 @@ static void set_pin(int state, unsigned long mask);
* will toggle once what forces the mgocge3un part to restart
* immediately.
*/
-void handle_mgcoge3un_reset(void)
+static void handle_mgcoge3un_reset(void)
{
char *bobcatreset = getenv(bobcatreset);
if (bobcatreset) {
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Slow tftp boot with Ubuntu 12.04 tftp server
Try setting the max. blocksize explicit, e.g. I'm using -B 1460 here. It depends on the used tftp-server. I have tried setting u-boot env variable tftpblocksize to 1460 and option --blocksize 1460 on the server, but there's no improvement. Also tried 512 but same result. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/5] Initial IPv6 support
Dear Chris, In message 50f91851.5050...@gmail.com you wrote: Good question. Basically we have some out of tree code that implements a basic IPv6 stack. I'm drip feeding the code in pieces to avoid just dumping it on people and because the current code wouldn't meet u-boot's standards. Can you please go into abit more detail which exact services this implements, and how? Last time I checked (about 2 years ago) there was no officially agreed-on standard for example how network booting should be done in IPv6. There used to be a document how TFTP could handle IPv6 addresses at http://datatracker.ietf.org/idtracker/draft-evans-tftp-address-options/comment/50586/ but this apears to be gone now. The proposal was rejected by then, and the comments (I do recommend the transition to a better transport protocol.) sounded as if the IETF would like to abandon TFTp under IPv6. I found links for DHCPv6, for example http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-opt-netboot-00 but no read standard for a bootstrap protocol. Some documents indicated it might be based on iSCSI - but that would be quite complex; see http://tools.ietf.org/html/rfc4173 http://tools.ietf.org/agenda/72/slides/dhc-12.pdf So what exactly are you targeting for? Putting my IPv6 promoter hat on I hope that it won't stay dead for long :) Thanks, appreciated! Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me. I see no problem with handling this as a branch (for example in the u-boot-net or u-boot-testing repositories). This should probably be decided by Joe Hershberger, though. 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's like deja vu all over again. - Yogi Berra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting different kernel from U-Boot based on time stamp
I am using U-Boot and two kernel Image(uImage). I want to add some code in U-Boot which will select kernel based of time stamp. I am using MIPS architecture. this two kernels are in different MTD partition. For example:- |If kernel-1 is new, U-Boot will boot Kernel-1. and leave kernel-2 as it is. If kernel-2 is new, U-Boot will boot kernel-2. and leave kernel-2 as it is. | Questions:- |Is it possible to do so? How can I add such functionality in U-boot? Where to chage the code for the same? | -- Thanks Regards, Hemal Patel System Level Solutions (I) Pvt. Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: resync with Linux-3.7.1
Hi, Sergey
On 1/18/2013 5:45 PM, Sergey Lapin wrote:
Dear Scott,
could you please test the following patch
on top of this big patch to see if ecc.strength
problem goes away? I can integrate it into big
one then.
From dffea1f073c546ab88f37f219f66d9d1478d4cf1 Mon Sep 17 00:00:00 2001
From: Sergey Lapin sla...@ossfans.org
Date: Thu, 17 Jan 2013 18:29:21 +0400
Subject: [PATCH] SQUASHME: mtd: nand: Add ecc.strength support to drivers
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
drivers/mtd/nand/atmel_nand.c|1 +
drivers/mtd/nand/bfin_nand.c |2 ++
drivers/mtd/nand/davinci_nand.c |1 +
drivers/mtd/nand/diskonchip.c|1 +
drivers/mtd/nand/fsl_elbc_nand.c |6 ++
drivers/mtd/nand/fsl_ifc_nand.c |1 +
drivers/mtd/nand/fsmc_nand.c |2 ++
drivers/mtd/nand/jz4740_nand.c |5 +
drivers/mtd/nand/mxc_nand.c |7 +++
drivers/mtd/nand/mxs_nand.c |1 +
drivers/mtd/nand/nand_base.c |1 +
drivers/mtd/nand/ndfc.c |1 +
drivers/mtd/nand/nomadik.c |1 +
drivers/mtd/nand/omap_gpmc.c |1 +
drivers/mtd/nand/s3c2410_nand.c |1 +
drivers/mtd/nand/s3c64xx.c |1 +
drivers/mtd/nand/tegra_nand.c|1 +
17 files changed, 34 insertions(+)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index b09e7b7..9cdf35b 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -709,6 +709,7 @@ static int atmel_pmecc_nand_init_params(struct nand_chip
*nand,
nand-ecc.read_page = atmel_nand_pmecc_read_page;
nand-ecc.write_page = atmel_nand_pmecc_write_page;
+ nand-ecc.strength = 1;
For atmel nand, it should be:
+ nand-ecc.strength = cap;
Best Regards,
Josh Wu
atmel_pmecc_core_init(mtd);
diff --git a/drivers/mtd/nand/bfin_nand.c b/drivers/mtd/nand/bfin_nand.c
index c7ddbb2..7e755e8 100644
--- a/drivers/mtd/nand/bfin_nand.c
+++ b/drivers/mtd/nand/bfin_nand.c
@@ -374,9 +374,11 @@ int board_nand_init(struct nand_chip *chip)
if (!NAND_IS_512()) {
chip-ecc.bytes = 3;
chip-ecc.size = 256;
+ chip-ecc.strength = 1;
} else {
chip-ecc.bytes = 6;
chip-ecc.size = 512;
+ chip-ecc.strength = 2;
}
chip-ecc.mode = NAND_ECC_HW;
chip-ecc.calculate = bfin_nfc_calculate_ecc;
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 04b24f3..9777878 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -613,6 +613,7 @@ void davinci_nand_init(struct nand_chip *nand)
nand-ecc.mode = NAND_ECC_HW;
nand-ecc.size = 512;
nand-ecc.bytes = 3;
+ nand-ecc.strength = 4;
nand-ecc.calculate = nand_davinci_calculate_ecc;
nand-ecc.correct = nand_davinci_correct_data;
nand-ecc.hwctl = nand_davinci_enable_hwecc;
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 104d97f..4cd741e 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -1658,6 +1658,7 @@ static int __init doc_probe(unsigned long physadr)
nand-ecc.mode = NAND_ECC_HW_SYNDROME;
nand-ecc.size = 512;
nand-ecc.bytes = 6;
+ nand-ecc.strength = 2;
nand-bbt_options= NAND_BBT_USE_FLASH;
doc-physadr = physadr;
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 65edbf5..c3f350d 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -781,6 +781,12 @@ static int fsl_elbc_chip_init(int devnum, u8 *addr)
nand-ecc.size = 512;
nand-ecc.bytes = 3;
nand-ecc.steps = 1;
+ chip-ecc.strength = 1;
+ /*
+* FIXME: can hardware ecc correct 4 bitflips if page size is
+* 2k? Then does hardware report number of corrections for this
+* case? If so, ecc_stats reporting needs to be fixed as well.
+*/
} else {
/* otherwise fall back to default software ECC */
nand-ecc.mode = NAND_ECC_SOFT;
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 5d47b40..823a2eb 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -871,6 +871,7 @@ int board_nand_init(struct nand_chip *nand)
/* Hardware generates ECC per 512 Bytes */
nand-ecc.size = 512;
nand-ecc.bytes = 8;
+ nand-ecc.strength = 1;
switch (csor CSOR_NAND_PGS_MASK) {
case CSOR_NAND_PGS_512:
diff --git a/drivers/mtd/nand/fsmc_nand.c b/drivers/mtd/nand/fsmc_nand.c
index 48ca543..fab2aeb 100644
--- a/drivers/mtd/nand/fsmc_nand.c
Re: [U-Boot] Slow tftp boot with Ubuntu 12.04 tftp server
Am 18.01.2013 11:16, schrieb David Aldrich: Try setting the max. blocksize explicit, e.g. I'm using -B 1460 here. It depends on the used tftp-server. Hi Alexander Thanks for your reply. Please will you confirm the exact syntax? I tried: # tftp -B 1460 0x8200 tci6614-evm.dtb tftpboot - boot image via network using TFTP protocol Usage: tftpboot [loadAddress] [[hostIPaddr:]bootfilename] I also tried: setenv tftpblocksize 1460 but that made no difference. What is the correct way of specifying the block size please? That -B n is an option for the server, which is in my case (not Ubuntu) called in.tftpd and comes from the package tftpd-hpa (a Linux port of the OpenBSD TFTP server). So you have to change that on your Ubuntu box. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: resync with Linux-3.7.1
Hi, Josh diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index b09e7b7..9cdf35b 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -709,6 +709,7 @@ static int atmel_pmecc_nand_init_params(struct nand_chip *nand, nand-ecc.read_page = atmel_nand_pmecc_read_page; nand-ecc.write_page = atmel_nand_pmecc_write_page; +nand-ecc.strength = 1; For atmel nand, it should be: + nand-ecc.strength = cap; Best Regards, Josh Wu Thanks, changed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: resync with Linux-3.7.1
Dear Scott,
could you please test the following patch
on top of this big patch to see if ecc.strength
problem goes away? I can integrate it into big
one then.
From dffea1f073c546ab88f37f219f66d9d1478d4cf1 Mon Sep 17 00:00:00 2001
From: Sergey Lapin sla...@ossfans.org
Date: Thu, 17 Jan 2013 18:29:21 +0400
Subject: [PATCH] SQUASHME: mtd: nand: Add ecc.strength support to drivers
Updated the patch according to Josh's request:
From 4d857af69f4383bef246ad0231fc82ce30a1276c Mon Sep 17 00:00:00 2001
From: Sergey Lapin sla...@ossfans.org
Date: Thu, 17 Jan 2013 18:29:21 +0400
Subject: [PATCH] SQUASHME: mtd: nand: Add ecc.strength support to drivers
Signed-off-by: Sergey Lapin sla...@ossfans.org
---
drivers/mtd/nand/atmel_nand.c|1 +
drivers/mtd/nand/bfin_nand.c |2 ++
drivers/mtd/nand/davinci_nand.c |1 +
drivers/mtd/nand/diskonchip.c|1 +
drivers/mtd/nand/fsl_elbc_nand.c |6 ++
drivers/mtd/nand/fsl_ifc_nand.c |1 +
drivers/mtd/nand/fsmc_nand.c |2 ++
drivers/mtd/nand/jz4740_nand.c |5 +
drivers/mtd/nand/mxc_nand.c |7 +++
drivers/mtd/nand/mxs_nand.c |1 +
drivers/mtd/nand/nand_base.c |1 +
drivers/mtd/nand/ndfc.c |1 +
drivers/mtd/nand/nomadik.c |1 +
drivers/mtd/nand/omap_gpmc.c |1 +
drivers/mtd/nand/s3c2410_nand.c |1 +
drivers/mtd/nand/s3c64xx.c |1 +
drivers/mtd/nand/tegra_nand.c|1 +
17 files changed, 34 insertions(+)
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index b09e7b7..3bfbaf8 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -709,6 +709,7 @@ static int atmel_pmecc_nand_init_params(struct nand_chip
*nand,
nand-ecc.read_page = atmel_nand_pmecc_read_page;
nand-ecc.write_page = atmel_nand_pmecc_write_page;
+ nand-ecc.strength = cap;
atmel_pmecc_core_init(mtd);
diff --git a/drivers/mtd/nand/bfin_nand.c b/drivers/mtd/nand/bfin_nand.c
index c7ddbb2..7e755e8 100644
--- a/drivers/mtd/nand/bfin_nand.c
+++ b/drivers/mtd/nand/bfin_nand.c
@@ -374,9 +374,11 @@ int board_nand_init(struct nand_chip *chip)
if (!NAND_IS_512()) {
chip-ecc.bytes = 3;
chip-ecc.size = 256;
+ chip-ecc.strength = 1;
} else {
chip-ecc.bytes = 6;
chip-ecc.size = 512;
+ chip-ecc.strength = 2;
}
chip-ecc.mode = NAND_ECC_HW;
chip-ecc.calculate = bfin_nfc_calculate_ecc;
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 04b24f3..9777878 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -613,6 +613,7 @@ void davinci_nand_init(struct nand_chip *nand)
nand-ecc.mode = NAND_ECC_HW;
nand-ecc.size = 512;
nand-ecc.bytes = 3;
+ nand-ecc.strength = 4;
nand-ecc.calculate = nand_davinci_calculate_ecc;
nand-ecc.correct = nand_davinci_correct_data;
nand-ecc.hwctl = nand_davinci_enable_hwecc;
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 104d97f..4cd741e 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -1658,6 +1658,7 @@ static int __init doc_probe(unsigned long physadr)
nand-ecc.mode = NAND_ECC_HW_SYNDROME;
nand-ecc.size = 512;
nand-ecc.bytes = 6;
+ nand-ecc.strength = 2;
nand-bbt_options = NAND_BBT_USE_FLASH;
doc-physadr= physadr;
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
index 65edbf5..c3f350d 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -781,6 +781,12 @@ static int fsl_elbc_chip_init(int devnum, u8 *addr)
nand-ecc.size = 512;
nand-ecc.bytes = 3;
nand-ecc.steps = 1;
+ chip-ecc.strength = 1;
+ /*
+* FIXME: can hardware ecc correct 4 bitflips if page size is
+* 2k? Then does hardware report number of corrections for this
+* case? If so, ecc_stats reporting needs to be fixed as well.
+*/
} else {
/* otherwise fall back to default software ECC */
nand-ecc.mode = NAND_ECC_SOFT;
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c
index 5d47b40..823a2eb 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -871,6 +871,7 @@ int board_nand_init(struct nand_chip *nand)
/* Hardware generates ECC per 512 Bytes */
nand-ecc.size = 512;
nand-ecc.bytes = 8;
+ nand-ecc.strength = 1;
switch (csor CSOR_NAND_PGS_MASK) {
case CSOR_NAND_PGS_512:
diff --git
Re: [U-Boot] [PATCH 1/5] treewide: include libfdt_env.h before fdt.h
Hi Kim, On 01/16/2013 06:59 PM, Kim Phillips wrote: and, if including libfdt.h which includes libfdt_env.h in the correct order, don't include fdt.h before libfdt.h. this is needed to get the fdt type definitions set from the project environment before fdt.h uses them. Signed-off-by: Kim Phillips kim.phill...@freescale.com Cc: Jerry Van Baren gvb.ub...@gmail.com Thanks, that was very helpful. I applied the series to my personal tree, will push when the dust settles. I created a patch that uses just libfdt.h as the interface #include, will publish when the dust settles on the dtc (device tree) list discussion. Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] arm: Add CONFIG_DELAY_ENVIRONMENT to delay environment loading
Am Donnerstag, den 01.11.2012, 16:42 -0700 schrieb Simon Glass:
This option delays loading of the environment until later, so that only the
default environment will be available to U-Boot.
This can address the security risk of untrusted data being used during boot.
When CONFIG_DELAY_ENVIRONMENT is defined, it is convenient to have a
run-time way of enabling loadinlg of the environment. Add this to the
fdt as /config/delay-environment.
It's really unfortunate to only realize this after the final release of
v2013.01 as I haven't tested the -rc3, but this breaks environment for
almost all Tegra boards. I haven't checked all of them, but the ones I
looked at have CONFIG_OF_CONTROL defined, but no load-environment node
in the FDT.
So they're all going straight into secure boot mode, because of the
bogus standard value of not allowing env to load, which is probably not
what most people want.
Regards,
Lucas
---
[...]
/*
-
+ * Tell if it's OK to load the environment early in boot.
+ *
+ * If CONFIG_OF_CONFIG is defined, we'll check with the FDT to see
+ * if this is OK (defaulting to saying it's not OK).
+ *
+ * NOTE: Loading the environment early can be a bad idea if security is
+ * important, since no verification is done on the environment.
+ *
+ * @return 0 if environment should not be loaded, !=0 if it is ok to load
+ */
+static int should_load_env(void)
+{
+#ifdef CONFIG_OF_CONTROL
+ return fdtdec_get_config_int(gd-fdt_blob, load-environment, 0);
+#elif defined CONFIG_DELAY_ENVIRONMENT
+ return 0;
+#else
+ return 1;
+#endif
+}
+
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] treewide: include libfdt_env.h before fdt.h
On 01/17/2013 06:50 PM, David Gibson wrote: On Thu, Jan 17, 2013 at 01:32:45PM -0500, Jerry Van Baren wrote: Hi Scott, Kim, David, [snip] libfdt_env.h is where Kim typedef'ed fdt16_t, fdt32_t, fdt64_t I suspect the original intent was to have libfdt.h be the file that people #included. For whatever reason, most includes are (picking on fdt_ro.c arbitrarily): 51 #include libfdt_env.h 53 #include fdt.h 54 #include libfdt.h Since libfdt.h #includes fdt.h and libfdt_env.h, lines 51 and 53 (above) are redundant. It sorts out OK in dtc because libfdt_env.h includes stdint.h and defines fdt*_t, but it messes me up in u-boot where (currently) libfdt_env.h does *not* include stdint.h... Ok, so, the uboot libfdt_env.h should be fixed to define uintXX_t and fdtXX_t (either by including stdint or my other means). The purpose of libfdt_env.h is to define the things that libfdt requires, and those types are (now) such a requirement. I like the move, but have not done it (yet). I made a trial patch (see below) that uses libfdt.h as the interface and cleans out the (now redundant) other *fdt*.h includes. If this is in the right direction, I'll move the fdtXX_t typedefs and formally submit it. The test suite has one failure, but it fails with or without my changes. $ make check | grep FAIL fdtget-runtest.sh 77 121 66 111 97 114 100 78 97 109 101 0 77 121 66 111 97 114 100 70 97 109 105 108 121 78 97 109 101 0 label01.dts.fdtget.test.dtb / compatible: FAIL Results differ from expected *FAIL: 1 ** TEST SUMMARY * Total testcases: 1443 *PASS: 1442 *FAIL: 1 * Bad configuration: 0 * Strange test result: 0 ** gvb From 1fb0193670e012072d4a9e5ac480e3201aaf30fd Mon Sep 17 00:00:00 2001 From: Gerald Van Baren g...@unssw.com Date: Thu, 17 Jan 2013 21:14:01 -0500 Subject: [PATCH] Use the libfdt.h include as the interface definition libfdt.h is the libfdt interface definition. It includes fdt.h and libfdt_env.h, so there is no reason to include those in the general code. Signed-off-by: Gerald Van Baren vanba...@cideas.com --- dtc.h|3 +-- fdtdump.c|3 +-- libfdt/fdt.c |3 --- libfdt/fdt_empty_tree.c |3 --- libfdt/fdt_ro.c |3 --- libfdt/fdt_rw.c |3 --- libfdt/fdt_strerror.c|3 --- libfdt/fdt_sw.c |3 --- libfdt/fdt_wip.c |3 --- libfdt/libfdt_internal.h |1 - 10 files changed, 2 insertions(+), 26 deletions(-) diff --git a/dtc.h b/dtc.h index 3e42a07..a032645 100644 --- a/dtc.h +++ b/dtc.h @@ -32,8 +32,7 @@ #include errno.h #include unistd.h -#include libfdt_env.h -#include fdt.h +#include libfdt.h #include util.h diff --git a/fdtdump.c b/fdtdump.c index b2c5b37..3919490 100644 --- a/fdtdump.c +++ b/fdtdump.c @@ -8,8 +8,7 @@ #include string.h #include ctype.h -#include libfdt_env.h -#include fdt.h +#include libfdt.h #include util.h diff --git a/libfdt/fdt.c b/libfdt/fdt.c index 57faba3..19b9043 100644 --- a/libfdt/fdt.c +++ b/libfdt/fdt.c @@ -48,11 +48,8 @@ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -#include libfdt_env.h -#include fdt.h #include libfdt.h - #include libfdt_internal.h int fdt_check_header(const void *fdt) diff --git a/libfdt/fdt_empty_tree.c b/libfdt/fdt_empty_tree.c index f72d13b..30c5525 100644 --- a/libfdt/fdt_empty_tree.c +++ b/libfdt/fdt_empty_tree.c @@ -48,11 +48,8 @@ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -#include libfdt_env.h -#include fdt.h #include libfdt.h - #include libfdt_internal.h int fdt_create_empty_tree(void *buf, int bufsize) diff --git a/libfdt/fdt_ro.c b/libfdt/fdt_ro.c index 42da2bd..53c61ed 100644 --- a/libfdt/fdt_ro.c +++ b/libfdt/fdt_ro.c @@ -48,11 +48,8 @@ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -#include libfdt_env.h -#include fdt.h #include libfdt.h - #include libfdt_internal.h static int _fdt_nodename_eq(const void *fdt, int offset, diff --git a/libfdt/fdt_rw.c b/libfdt/fdt_rw.c index fdba618..b6a8815 100644 --- a/libfdt/fdt_rw.c +++ b/libfdt/fdt_rw.c @@ -48,11 +48,8 @@ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -#include libfdt_env.h -#include fdt.h #include libfdt.h - #include libfdt_internal.h static int _fdt_blocks_misordered(const void *fdt, diff --git a/libfdt/fdt_strerror.c b/libfdt/fdt_strerror.c index e6c3cee..c55793c 100644 --- a/libfdt/fdt_strerror.c +++ b/libfdt/fdt_strerror.c @@ -48,11 +48,8 @@ * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */
Re: [U-Boot] U-Boot Graphics Library?
Hi, On Fri, Jan 18, 2013 at 1:18 AM, Stefano Babic sba...@denx.de wrote: On 16/01/2013 22:46, Simon Glass wrote: Hi Wolfgang, Hi Simon, This sounds like a nice feature. Initially. Then I start wondering if this really belongs into a boot loader. Instead of doing fancy graphics stuff, we should IMO rather focus on booting the OS of your choice really fast, and let this do the fancy GUIs. Or? The problem is that a major purpose of the GUIs is to allow installing an OS from a USB stick/SD card, since the OS may have become corrupted and unbootable. We have looked at keeping around a separate OS image for this (e.g. in an available disk partition), but so far that hasn't proved practical since that itself can be fairly easily overwritten and we then have a doorstop. Well, if a separate OS image can be overwritten, U-Boot image can be overwritten too, and then the board does not boot at all. If U-Boot is kept in read-only memory (only written during manufacture) then it cannot be overwritten. This is the approach we are taking at present. However the size of this memory is very limited (4MB) and not enough for a kernel/graphics. So far we are not using NAND flash for this since we cannot write-protect it. If we could expand that memory somewhat then I agree we could use a read-only OS image for this and I would not have started this discussion. I provided for a customer a solution with a separate OS and a small rootfs as initramfs, and even if it is theoretically possible to destroy this image, it has the same probability that U-Boot has to disappear. It still seems to me a good solution, with the drawback to use much more resorces (Flash) that a U-Boot solution can use. Anyway, with the current size of NAND flash, even this drawback is not very important in many projects. Maybe more as a GUI-guided recovery, the customer needs a way to rescue the system when everything goes wrong. Providing a booting SD or USB card, that can complete restore the system, seems to be a good way, or at least it was in my case. Yes, this is what we do, but we unfortunately do need a GUI for this - language selection and instructions on what to do. Implementing it in U-Boot seems to me overkilling, but is only my 2 cents ;-). Yes it is quite a lot of effort. Partly it is due to the security requirements - we have read-only firmware and (upgradable) read-write firmware in case there is a bug we need to patch in read-only firmware. This adds to the image size. We have a recovery mode which must run from read-only firmware, and guides the user through the process (bearing in mind the user is probably not a techie!). Also, in 'developer' mode we print a nice large warning screen on boot to make sure the user intends to be in this mode. This is quite a different experience from a PC BIOS upgrade - all upgrades need to be seamless and automatic. We can't have it say 'Missing Operating System' and refuse to boot, no matter what happens. Yes these sorts of things have been done in various ways, but above all it needs to be secure and self-explanatory. As I said at the start, so far we are using rendered images in every language, but it is not very efficient. I am trying to find a way to improve on this. Regards, Simon Best 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10] arm: Add CONFIG_DELAY_ENVIRONMENT to delay environment loading
Hi Lucas,
On Fri, Jan 18, 2013 at 4:06 AM, Lucas Stach d...@lynxeye.de wrote:
Am Donnerstag, den 01.11.2012, 16:42 -0700 schrieb Simon Glass:
This option delays loading of the environment until later, so that only the
default environment will be available to U-Boot.
This can address the security risk of untrusted data being used during boot.
When CONFIG_DELAY_ENVIRONMENT is defined, it is convenient to have a
run-time way of enabling loadinlg of the environment. Add this to the
fdt as /config/delay-environment.
It's really unfortunate to only realize this after the final release of
v2013.01 as I haven't tested the -rc3, but this breaks environment for
almost all Tegra boards. I haven't checked all of them, but the ones I
looked at have CONFIG_OF_CONTROL defined, but no load-environment node
in the FDT.
So they're all going straight into secure boot mode, because of the
bogus standard value of not allowing env to load, which is probably not
what most people want.
Hmmm yes I think you are right - the value would be better the other
way around. I will create a patch for this and see what people think.
I have tended to create my own FDT file but I'm sure many will not.
Regards,
Simon
Regards,
Lucas
---
[...]
/*
-
+ * Tell if it's OK to load the environment early in boot.
+ *
+ * If CONFIG_OF_CONFIG is defined, we'll check with the FDT to see
+ * if this is OK (defaulting to saying it's not OK).
+ *
+ * NOTE: Loading the environment early can be a bad idea if security is
+ * important, since no verification is done on the environment.
+ *
+ * @return 0 if environment should not be loaded, !=0 if it is ok to load
+ */
+static int should_load_env(void)
+{
+#ifdef CONFIG_OF_CONTROL
+ return fdtdec_get_config_int(gd-fdt_blob, load-environment, 0);
+#elif defined CONFIG_DELAY_ENVIRONMENT
+ return 0;
+#else
+ return 1;
+#endif
+}
+
[...]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX6 Solo and Dual Lite
On 16/01/2013 23:33, Eric Nelson wrote: Hi all, Hi Eric, We're preparing to launch i.MX6 Solo/Dual-Lite and Dual versions of our Nitrogen6X product line. We made a couple of stabs at patches to support these processor variants in September and October last year. The first attempt added run-time detection using i.MX plugins: http://lists.denx.de/pipermail/u-boot/2012-September/#134442 It was soundly rejected. The second attempt added preprocessor support to imximage in order to allow a single board definition file to be compiled for each processor variant. http://lists.denx.de/pipermail/u-boot/2012-September/#134442 We think the approach was generally agreed to based on this comment from Tom: http://lists.denx.de/pipermail/u-boot/2012-October/137611.html And a follow-up patch from Troy: http://lists.denx.de/pipermail/u-boot/2012-October/138162.html But things seemed to stall here: http://lists.denx.de/pipermail/u-boot/2012-November/139918.html Right, also if the issue (where adding rule for a single SOC or SOC family) is marginal for this patchset. Troy submitted a number of other patches, including some fixes to the DDR initialization, but they were all made based on a 'preprocessorized' version of mx6q_4x_mt41j128.cfg. Troy and I also had some discussion surrounding **how** the preprocessor was used to define the differences between processors: http://lists.denx.de/pipermail/u-boot/2012-October/136751.html In a nutshell, the current patch set uses a set of preprocessor macros to configure things for each. For example, this macro call in the file mx6q_4x_mt41j128.cfg will write either 0x48254A36 (Quad or Dual) or 0x3F3F3035 (Dual-Lite/Solo) to register MMDC_P1_MPWRDLCTL: WRITE_ENTRY2(MMDC_P1_MPWRDLCTL, 0x48254A36, 0x3F3F3035) I read the patch and your comment on ML and agree with your comment. It seems to me that it is very tricky to add this macro to make possible to have a single imximage.cfg file. And, as you remark, this will work now with these set on boards, but things can be different with new SOC version. The concept here is that the processors use a different internal base address, and depending on this address, the macro does its work, writing on the selected address. But again, IMHO it is tricky, and it is strictly bound to i.MX6 when imximage is thought for all i.MX processors. Let's say, instead of it, I prefer the solution using the preprocessor or as you suggest, using different .cfg files for the memory configurations. Nobody else seemed to comment on this, and it seems pretty critical. Can we get some feedback before we prepare V2/V3 patches? Our expectation is that we'll submit patches for each of the following configurations of Nitrogen6X: nitrogen6q- Dual/Quad 1GB nitrogen6q2g- Dual/Quad 2GB nitrogen6solo- Solo 512MB nitrogen6duallite- Dual Lite 512MB nitrogen6solo1G- Solo 1GB nitrogen6duallite1G- Dual Lite 1GB Our hope is that we can do this with essentially one code base but a separate .cfg file or #ifdefs for each. I agree on this, but then do we still need WRITE_ENTRY2() ? I miss why we need if you use separate .cfg files. A single include/config/nitrogen6x.h with #ifdefs should allow us to exclude those features (e.g. SATA) on the Solo and Dual-Lite. Right, I think it is a good solution. 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] led: The gpio_led.c code expects that LED state is from the enum
u-boot is not consistent if state should be 0|1 or of the enum, the GPIO driver expects this to be one of the enum values. Update the caller. --- common/cmd_led.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/cmd_led.c b/common/cmd_led.c index 7f5ab43..c725f95 100644 --- a/common/cmd_led.c +++ b/common/cmd_led.c @@ -110,13 +110,13 @@ int do_led (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) if (led_commands[i].on) led_commands[i].on(); else - __led_set(led_commands[i].mask, 1); + __led_set(led_commands[i].mask, STATUS_LED_ON); break; case LED_OFF: if (led_commands[i].off) led_commands[i].off(); else - __led_set(led_commands[i].mask, 0); + __led_set(led_commands[i].mask, STATUS_LED_OFF); break; case LED_TOGGLE: if (led_commands[i].toggle) -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] mac: Fix the condition check for setting the MAC from the EEPROM
The issue got introduced in a cleanup by Manjunath Hadli in commit
826e99136e2bce61f3f6572e32d7aa724c116e6d. The eth_getenv_enetaddr_by_index
method will validate the MAC addr and if none is set in the environment
0 will be returned. Set the MAC from the eeprom if no valid address
is found in environment.
---
arch/arm/cpu/arm926ejs/davinci/misc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/davinci/misc.c
b/arch/arm/cpu/arm926ejs/davinci/misc.c
index c310c69..162c1e0 100644
--- a/arch/arm/cpu/arm926ejs/davinci/misc.c
+++ b/arch/arm/cpu/arm926ejs/davinci/misc.c
@@ -104,7 +104,7 @@ void davinci_sync_env_enetaddr(uint8_t *rom_enetaddr)
int ret;
ret = eth_getenv_enetaddr_by_index(eth, 0, env_enetaddr);
- if (ret) {
+ if (!ret) {
/*
* There is no MAC address in the environment, so we
* initialize it from the value in the EEPROM.
@@ -115,7 +115,7 @@ void davinci_sync_env_enetaddr(uint8_t *rom_enetaddr)
ret = !eth_setenv_enetaddr(ethaddr, rom_enetaddr);
}
if (!ret)
- printf(Failed to set mac address from EEPROM\n);
+ printf(Failed to set mac address from EEPROM: %d\n, ret);
}
#endif /* CONFIG_DRIVER_TI_EMAC */
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] gpio: Build the da8xx_gpio code for the davinci644x device
The differences include the number of GPIOs and that one is
not required to set the pinmux on request.
---
arch/arm/include/asm/arch-davinci/gpio.h |8 +++-
drivers/gpio/Makefile|1 +
drivers/gpio/da8xx_gpio.c|4
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-davinci/gpio.h
b/arch/arm/include/asm/arch-davinci/gpio.h
index ef65ffb..5206b12 100644
--- a/arch/arm/include/asm/arch-davinci/gpio.h
+++ b/arch/arm/include/asm/arch-davinci/gpio.h
@@ -65,9 +65,15 @@ struct davinci_gpio_bank {
#define davinci_gpio_bank67 ((struct davinci_gpio *)DAVINCI_GPIO_BANK67)
#define davinci_gpio_bank8 ((struct davinci_gpio *)DAVINCI_GPIO_BANK8)
+#if defined(CONFIG_SOC_DM644X)
+/* GPIO0 to GPIO53, omit the V3.3 volts one */
+#define MAX_NUM_GPIOS 70
+#else
+#define MAX_NUM_GPIOS 144
+#endif
+
#define gpio_status() gpio_info()
#define GPIO_NAME_SIZE 20
-#define MAX_NUM_GPIOS 144
#define GPIO_BANK(gp) (davinci_gpio_bank01 + ((gp) 5))
#define GPIO_BIT(gp) ((gp) 0x1F)
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 2d97b4f..9df1e26 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_SANDBOX_GPIO) += sandbox.o
COBJS-$(CONFIG_SPEAR_GPIO) += spear_gpio.o
COBJS-$(CONFIG_TEGRA_GPIO) += tegra_gpio.o
COBJS-$(CONFIG_DA8XX_GPIO) += da8xx_gpio.o
+COBJS-$(CONFIG_DM644X_GPIO)+= da8xx_gpio.o
COBJS-$(CONFIG_ALTERA_PIO) += altera_pio.o
COBJS-$(CONFIG_MPC83XX_GPIO) += mpc83xx_gpio.o
COBJS-$(CONFIG_SH_GPIO_PFC)+= sh_pfc.o
diff --git a/drivers/gpio/da8xx_gpio.c b/drivers/gpio/da8xx_gpio.c
index 84d2b77..ed6a118 100644
--- a/drivers/gpio/da8xx_gpio.c
+++ b/drivers/gpio/da8xx_gpio.c
@@ -31,6 +31,7 @@ static struct gpio_registry {
char name[GPIO_NAME_SIZE];
} gpio_registry[MAX_NUM_GPIOS];
+#if defined(CONFIG_SOC_DA8XX)
#define pinmux(x) (davinci_syscfg_regs-pinmux[x])
static const struct pinmux_config gpio_pinmux[] = {
@@ -179,6 +180,9 @@ static const struct pinmux_config gpio_pinmux[] = {
{ pinmux(18), 8, 3 },
{ pinmux(18), 8, 2 },
};
+#else
+#define davinci_configure_pin_mux(a, b)
+#endif
int gpio_request(unsigned gpio, const char *label)
{
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request for u-boot-tegra/master into ARM/master
Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -a arm completes w/o any new errors, and checkpatch is clean. The following changes since commit 3a9d879f6f64585b819af728b53be0a05037fe0d: Tom Rini (1): Prepare v2013.01 are available in the git repository at: git://git.denx.de/u-boot-tegra master Allen Martin (5): tegra: remove IRDA pinmux synonym tegra: fdt: remove clocks nodes tegra: fdt: sort dts files tegra: fdt: add apbdma node fdt: fix dts preprocessor options Marc Dietrich (3): tegra: display: add board pinmux tegra: enable LCD on PAZ00 tegra: remove custom TEGRA_DEVICE_SETTINGS for board files Thierry Reding (3): video: tegra: Update line length to match resolution tegra: Enable LCD on Medcom-Wide tegra: Enable LCD on TEC Tom Warren (10): Tegra30: Add arch-tegra30 include files Tegra30: Add AVP (arm720t) files Tegra30: Add CPU (armv7) files Tegra30: Add common CPU (shared) files Tegra30: Cardhu: Add DT files Tegra30: Add generic Tegra30 build support Tegra30: Add/enable Cardhu build (T30 reference board) Tegra30: clocks: Fix clock tables for I2C and other periphs Tegra30: fdt: Update DT files with I2C info for T30/Cardhu Tegra30: I2C: Enable I2C driver on Cardhu Makefile |6 +- arch/arm/cpu/arm720t/tegra-common/Makefile |1 + arch/arm/cpu/arm720t/tegra-common/cpu.c | 335 +++ arch/arm/cpu/arm720t/tegra-common/cpu.h | 68 +- arch/arm/cpu/arm720t/tegra-common/spl.c |3 +- arch/arm/cpu/arm720t/tegra20/cpu.c | 216 + arch/arm/cpu/arm720t/tegra30/Makefile| 41 + arch/arm/cpu/arm720t/tegra30/config.mk | 19 + arch/arm/cpu/arm720t/tegra30/cpu.c | 176 arch/arm/cpu/armv7/Makefile |2 +- arch/arm/cpu/armv7/start.S |4 +- arch/arm/cpu/armv7/tegra30/Makefile | 40 + arch/arm/cpu/armv7/tegra30/config.mk | 19 + arch/arm/cpu/tegra-common/ap.c | 14 +- arch/arm/cpu/tegra-common/board.c| 43 +- arch/arm/cpu/tegra-common/sys_info.c | 16 +- arch/arm/cpu/tegra20-common/funcmux.c|4 +- arch/arm/cpu/tegra20-common/pinmux.c |2 +- arch/arm/cpu/tegra20-common/warmboot.c |2 +- arch/arm/cpu/tegra30-common/Makefile | 44 + arch/arm/cpu/tegra30-common/clock.c | 1102 ++ arch/arm/cpu/tegra30-common/funcmux.c| 57 ++ arch/arm/cpu/tegra30-common/pinmux.c | 506 ++ arch/arm/dts/tegra20.dtsi| 400 arch/arm/dts/tegra30.dtsi| 93 ++ arch/arm/include/asm/arch-tegra/ap.h | 52 +- arch/arm/include/asm/arch-tegra/board.h |7 +- arch/arm/include/asm/arch-tegra/clk_rst.h| 148 +++- arch/arm/include/asm/arch-tegra/clock.h |8 +- arch/arm/include/asm/arch-tegra/funcmux.h| 39 + arch/arm/include/asm/arch-tegra/gp_padctrl.h | 39 + arch/arm/include/asm/arch-tegra/tegra.h | 12 +- arch/arm/include/asm/arch-tegra20/funcmux.h | 28 +- arch/arm/include/asm/arch-tegra20/gp_padctrl.h | 17 +- arch/arm/include/asm/arch-tegra20/pinmux.h |1 - arch/arm/include/asm/arch-tegra30/clock-tables.h | 382 arch/arm/include/asm/arch-tegra30/clock.h| 24 + arch/arm/include/asm/arch-tegra30/flow.h | 35 + arch/arm/include/asm/arch-tegra30/funcmux.h | 31 + arch/arm/include/asm/arch-tegra30/gp_padctrl.h | 59 ++ arch/arm/include/asm/arch-tegra30/gpio.h | 304 ++ arch/arm/include/asm/arch-tegra30/hardware.h | 22 + arch/arm/include/asm/arch-tegra30/pinmux.h | 603 arch/arm/include/asm/arch-tegra30/pmu.h | 23 + arch/arm/include/asm/arch-tegra30/spl.h | 28 + arch/arm/include/asm/arch-tegra30/tegra.h| 26 + board/avionic-design/dts/tegra20-medcom-wide.dts | 38 +- board/avionic-design/dts/tegra20-plutux.dts | 14 - board/avionic-design/dts/tegra20-tec.dts | 56 +- board/compal/dts/tegra20-paz00.dts | 39 +- board/compal/paz00/paz00.c | 11 + board/compulab/dts/tegra20-trimslice.dts | 13 - board/nvidia/cardhu/Makefile | 44 + board/nvidia/cardhu/cardhu.c | 39 + board/nvidia/cardhu/cardhu.c.mmc | 151 +++ board/nvidia/cardhu/pinmux-config-cardhu.h | 329 +++ board/nvidia/common/board.c | 24 +- board/nvidia/dts/tegra20-harmony.dts | 33 +- board/nvidia/dts/tegra20-seaboard.dts| 118 +-- board/nvidia/dts/tegra20-ventana.dts
Re: [U-Boot] Slow tftp boot with Ubuntu 12.04 tftp server
On Thu, Jan 17, 2013 at 8:29 AM, David Aldrich david.aldr...@emea.nec.comwrote: I would like to give some more information about my problem. u-boot's tftp transfers do eventually complete and the evm boots. I can then execute tftp get commands from Linux on the evm and these execute quickly. So the problem definitely has to do with the way u-boot uses tftp. I have experienced similar issues. It seems that once U-Boot's TFTP client has trouble with one packet that it tends to have a lot more trouble thereafter. For example, if the file I try to TFTP doesn't exist when I start the transfer, it retries until the file does exist at which time it starts the transfer (so far, so good), but the file transfer is then very slow. If I press CTRL-C to stop it then start it again, it runs quickly. I have also had problems using TFTP from U-Boot through Ethernet hubs that seem to work well for everything else. Replacing the hubs with switches solved the problem in multiple cases. I haven't tried to capture the packets and troubleshoot it, but it seems like there is something non-optimal in the timing. Steve -- Steve Strobel Link Communications, Inc. 1035 Cerise Rd Billings, MT 59101-7378 (406) 245-5002 ext 102 (406) 245-4889 (fax) WWW: http://www.link-comm.com MailTo:steve.stro...@link-comm.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Fri, 18 Jan 2013 09:00:44 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -a arm completes w/o any new errors, and checkpatch is clean. The following changes since commit 3a9d879f6f64585b819af728b53be0a05037fe0d: Tom Rini (1): Prepare v2013.01 are available in the git repository at: git://git.denx.de/u-boot-tegra master Allen Martin (5): tegra: remove IRDA pinmux synonym tegra: fdt: remove clocks nodes tegra: fdt: sort dts files tegra: fdt: add apbdma node fdt: fix dts preprocessor options Marc Dietrich (3): tegra: display: add board pinmux tegra: enable LCD on PAZ00 tegra: remove custom TEGRA_DEVICE_SETTINGS for board files Thierry Reding (3): video: tegra: Update line length to match resolution tegra: Enable LCD on Medcom-Wide tegra: Enable LCD on TEC Tom Warren (10): Tegra30: Add arch-tegra30 include files Tegra30: Add AVP (arm720t) files Tegra30: Add CPU (armv7) files Tegra30: Add common CPU (shared) files Tegra30: Cardhu: Add DT files Tegra30: Add generic Tegra30 build support Tegra30: Add/enable Cardhu build (T30 reference board) Tegra30: clocks: Fix clock tables for I2C and other periphs Tegra30: fdt: Update DT files with I2C info for T30/Cardhu Tegra30: I2C: Enable I2C driver on Cardhu Makefile |6 +- arch/arm/cpu/arm720t/tegra-common/Makefile |1 + arch/arm/cpu/arm720t/tegra-common/cpu.c | 335 +++ arch/arm/cpu/arm720t/tegra-common/cpu.h | 68 +- arch/arm/cpu/arm720t/tegra-common/spl.c |3 +- arch/arm/cpu/arm720t/tegra20/cpu.c | 216 + arch/arm/cpu/arm720t/tegra30/Makefile| 41 + arch/arm/cpu/arm720t/tegra30/config.mk | 19 + arch/arm/cpu/arm720t/tegra30/cpu.c | 176 arch/arm/cpu/armv7/Makefile |2 +- arch/arm/cpu/armv7/start.S |4 +- arch/arm/cpu/armv7/tegra30/Makefile | 40 + arch/arm/cpu/armv7/tegra30/config.mk | 19 + arch/arm/cpu/tegra-common/ap.c | 14 +- arch/arm/cpu/tegra-common/board.c| 43 +- arch/arm/cpu/tegra-common/sys_info.c | 16 +- arch/arm/cpu/tegra20-common/funcmux.c|4 +- arch/arm/cpu/tegra20-common/pinmux.c |2 +- arch/arm/cpu/tegra20-common/warmboot.c |2 +- arch/arm/cpu/tegra30-common/Makefile | 44 + arch/arm/cpu/tegra30-common/clock.c | 1102 ++ arch/arm/cpu/tegra30-common/funcmux.c| 57 ++ arch/arm/cpu/tegra30-common/pinmux.c | 506 ++ arch/arm/dts/tegra20.dtsi| 400 arch/arm/dts/tegra30.dtsi| 93 ++ arch/arm/include/asm/arch-tegra/ap.h | 52 +- arch/arm/include/asm/arch-tegra/board.h |7 +- arch/arm/include/asm/arch-tegra/clk_rst.h| 148 +++- arch/arm/include/asm/arch-tegra/clock.h |8 +- arch/arm/include/asm/arch-tegra/funcmux.h| 39 + arch/arm/include/asm/arch-tegra/gp_padctrl.h | 39 + arch/arm/include/asm/arch-tegra/tegra.h | 12 +- arch/arm/include/asm/arch-tegra20/funcmux.h | 28 +- arch/arm/include/asm/arch-tegra20/gp_padctrl.h | 17 +- arch/arm/include/asm/arch-tegra20/pinmux.h |1 - arch/arm/include/asm/arch-tegra30/clock-tables.h | 382 arch/arm/include/asm/arch-tegra30/clock.h| 24 + arch/arm/include/asm/arch-tegra30/flow.h | 35 + arch/arm/include/asm/arch-tegra30/funcmux.h | 31 + arch/arm/include/asm/arch-tegra30/gp_padctrl.h | 59 ++ arch/arm/include/asm/arch-tegra30/gpio.h | 304 ++ arch/arm/include/asm/arch-tegra30/hardware.h | 22 + arch/arm/include/asm/arch-tegra30/pinmux.h | 603 arch/arm/include/asm/arch-tegra30/pmu.h | 23 + arch/arm/include/asm/arch-tegra30/spl.h | 28 + arch/arm/include/asm/arch-tegra30/tegra.h| 26 + board/avionic-design/dts/tegra20-medcom-wide.dts | 38 +- board/avionic-design/dts/tegra20-plutux.dts | 14 - board/avionic-design/dts/tegra20-tec.dts | 56 +- board/compal/dts/tegra20-paz00.dts | 39 +- board/compal/paz00/paz00.c | 11 + board/compulab/dts/tegra20-trimslice.dts | 13 - board/nvidia/cardhu/Makefile | 44 + board/nvidia/cardhu/cardhu.c | 39 + board/nvidia/cardhu/cardhu.c.mmc | 151 +++ board/nvidia/cardhu/pinmux-config-cardhu.h | 329 +++ board/nvidia/common/board.c
Re: [U-Boot] cc-list modified?
Am 18.01.2013 04:17, schrieb Scott Wood: On 01/17/2013 07:22:57 PM, Alexander Holler wrote: Am 18.01.2013 01:50, schrieb Alexander Holler: (...) Yes. Sounds nice at first, but there will be no end of features people would want afterwards. Next will be video tutorials and fancy sound. ;) (...) I've just wondered what happened to the cc-list of that mail I sent. I've send it with CC: Simon Glass s...@chromium.org, U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jer...@myspectrum.nl and received it just with Cc: U-Boot Mailing List u-boot@lists.denx.de, Jeroen Hofstee jer...@myspectrum.nl Looks like mailman is confused. Yes, this is a very old known bug in mailman: https://bugs.launchpad.net/mailman/+bug/266161 Thanks for the pointer. I've now disabled that avoid duplicates option as the bug suggests. Good to know that such seems to be needed for mailman lists. Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/p5040: enable NAND boot support
On 01/17/2013 11:17:15 PM, Xie Shaohui-B21989 wrote: You don't even update strings like P3041/P5020 in README.pblimage to include P5040. :-) [S.H] Thanks for pointing it out. I will update the README.pblimage in next version. Why is P4080 excluded, BTW? I realize that P4080DS doesn't have NAND, but the file talks about chips, not boards. [S.H] there is no P4080DS_NAND entry in boards.cfg... Yes, I said I realize that P4080DS (note the DS) doesn't have NAND. But P4080 the SoC should support NAND boot on custom boards that have NAND, and README.pblimage doesn't appear to be talking about specific boards (except for the hardware switch section). -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 0/5] Initial IPv6 support
On Fri, Jan 18, 2013 at 4:44 AM, Wolfgang Denk w...@denx.de wrote: Dear Chris, In message 50f91851.5050...@gmail.com you wrote: Personally I'm happy to have a long running series and periodically send updates to the list. I have a repository on github[1] which has an ipv6 branch collecting my changes if anyone wants to pull it down for their own testing. If we want to apply some of the simple stuff early that's fine by me. I see no problem with handling this as a branch (for example in the u-boot-net or u-boot-testing repositories). This should probably be decided by Joe Hershberger, though. I'm fine with hosting these changes as a branch in the u-boot-net repo. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Graphics Library?
Hi, On Fri, Jan 18, 2013 at 7:47 AM, Steve Strobel steve.stro...@link-comm.com wrote: Maybe the USB flash drive used for recovery could contain not only the image to be written to flash, but also a bootable OS image used to provide on-screen messages during the recovery process. You would still need the read-only code to provide enough of a UI to boot from the USB flash drive, but the rest of the messages could be generated by that OS. Yes that's exactly what we do...and yes we still need the read-only code to provide a minimal GUI to get things started. That was the subject of this thread. The recovery mode GUI is provided by a Linux user space tool, but we need to get there first... Regards, Simon Steve -- Steve Strobel Link Communications, Inc. 1035 Cerise Rd Billings, MT 59101-7378 (406) 245-5002 ext 102 (406) 245-4889 (fax) WWW: http://www.link-comm.com MailTo:steve.stro...@link-comm.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/15] km82xx, km83xx: move ethernet_present() from common to cpu specific
On Fri, 18 Jan 2013 09:07:32 +0100
Holger Brunck holger.bru...@keymile.com wrote:
On 01/18/2013 01:23 AM, Kim Phillips wrote:
On Thu, 17 Jan 2013 13:47:50 +0100
Holger Brunck holger.bru...@keymile.com wrote:
+int piggy_present(void)
+{
+ struct km_bec_fpga *base =
+ (struct km_bec_fpga *)CONFIG_SYS_KMBEC_FPGA_BASE;
+
+ return in_8(base-bprth) PIGGY_PRESENT;
+}
this change produces two new sparse warnings:
km83xx.c:137:22: warning: incorrect type in argument 1 (different address
spaces)
km83xx.c:137:22:expected unsigned char const volatile [noderef]
asn:2*addr
km83xx.c:137:22:got unsigned char *noident
km83xx.c:132:5: warning: symbol 'piggy_present' was not declared. Should it
be static?
so make the function static, and add __iomem annotation to the
assignment of 'base'.
ok will do. Just out of curiosity which compiler throws these warnings? I use
powerpc-gcc (GCC) 4.7.2 and don't see them.
it's not a compiler, it's sparse - Linus' kernel sanity checking
tool. Get it from here:
http://git.kernel.org/?p=devel/sparse/sparse.git;a=summary
build it, add it to your path, and in u-boot, use make C=1
or ./MAKEALL -C/--check.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry
Signed-off-by: Tom Warren twar...@nvidia.com
---
arch/arm/cpu/arm720t/tegra-common/cpu.c |7 ---
arch/arm/include/asm/arch-tegra/tegra.h |1 -
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index 693d584..c32925b 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -75,13 +75,6 @@ struct clk_pll_table
tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
{ 700, 6, 0, 8},
{ 700, 13, 0, 8},
},
-
- /* TEGRA_SOC2_SLOW: 312 MHz */
- {{ 312, 13, 0, 12}, /* OSC 13M */
-{ 260, 16, 0, 8}, /* OSC 19.2M */
-{ 312, 12, 0, 12}, /* OSC 12M */
-{ 312, 26, 0, 12}, /* OSC 26M */
- },
};
void adjust_pllp_out_freqs(void)
diff --git a/arch/arm/include/asm/arch-tegra/tegra.h
b/arch/arm/include/asm/arch-tegra/tegra.h
index 953936c..013a3c5 100644
--- a/arch/arm/include/asm/arch-tegra/tegra.h
+++ b/arch/arm/include/asm/arch-tegra/tegra.h
@@ -85,7 +85,6 @@ enum {
TEGRA_SOC_T20,
TEGRA_SOC_T25,
TEGRA_SOC_T30,
- TEGRA_SOC2_SLOW,/* T2x needs to run at slow clock initially */
TEGRA_SOC_CNT,
TEGRA_SOC_UNKNOWN = -1,
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] Add support for NVIDIA Tegra114 SoC
This patch series adds basic (boot to cmd prompt) support for Tegra114. This is based on the Tegra30 SPL, which inits the AVP (ARM7TDMI boot proc) first, then control is passed to the CPU (A15 quad cluster). It is based on current u-boot-tegra/next. Future patches will add support/drivers for I2C, SPI, MMC, USB, etc. The Dalmore (E1611) T114 board is supported initially. Changes in v2: - Rework patchset as per feedback from Stephen and Allen. Tom Warren (7): Tegra114: Add arch-tegra114 include files Tegra114: Add AVP (arm720t) files Tegra114: Add CPU (armv7) files Tegra114: Add common CPU (shared) files Tegra114: Dalmore: Add DT files Tegra114: Add generic Tegra114 build support Tegra114: Add/enable Dalmore build (T114 reference board) arch/arm/cpu/arm720t/tegra-common/cpu.c | 75 +- arch/arm/cpu/arm720t/tegra-common/cpu.h |8 +- arch/arm/cpu/arm720t/tegra114/Makefile | 42 + arch/arm/cpu/arm720t/tegra114/config.mk| 19 + arch/arm/cpu/arm720t/tegra114/cpu.c | 315 ++ arch/arm/cpu/armv7/tegra114/Makefile | 40 + arch/arm/cpu/armv7/tegra114/config.mk | 19 + arch/arm/cpu/tegra-common/ap.c|9 +- arch/arm/cpu/tegra-common/board.c | 21 +- arch/arm/cpu/tegra114-common/Makefile | 41 + arch/arm/cpu/tegra114-common/clock.c | 1150 + arch/arm/cpu/tegra114-common/funcmux.c | 63 ++ arch/arm/cpu/tegra114-common/pinmux.c | 506 + arch/arm/dts/tegra114.dtsi |5 + arch/arm/include/asm/arch-tegra/clk_rst.h | 58 +- arch/arm/include/asm/arch-tegra/gp_padctrl.h |1 + arch/arm/include/asm/arch-tegra/pmc.h | 12 + arch/arm/include/asm/arch-tegra/tegra.h |3 + arch/arm/include/asm/arch-tegra114/clock-tables.h | 402 +++ arch/arm/include/asm/arch-tegra114/clock.h| 28 + arch/arm/include/asm/arch-tegra114/flow.h | 35 + arch/arm/include/asm/arch-tegra114/funcmux.h | 31 + arch/arm/include/asm/arch-tegra114/gp_padctrl.h | 59 ++ arch/arm/include/asm/arch-tegra114/gpio.h | 30 + arch/arm/include/asm/arch-tegra114/hardware.h | 22 + arch/arm/include/asm/arch-tegra114/pinmux.h| 618 +++ arch/arm/include/asm/arch-tegra114/pmu.h | 23 + arch/arm/include/asm/arch-tegra114/spl.h | 22 + arch/arm/include/asm/arch-tegra114/tegra.h| 31 + arch/arm/include/asm/arch-tegra20/clock.h |4 + arch/arm/include/asm/arch-tegra30/clock.h |4 + board/nvidia/common/board.c|2 +- board/nvidia/dalmore/Makefile | 36 + board/nvidia/dalmore/dalmore.c| 32 + board/nvidia/dalmore/pinmux-config-dalmore.h | 249 + board/nvidia/dts/tegra114-dalmore.dts | 13 + boards.cfg |1 + include/configs/dalmore.h | 50 + include/configs/tegra114-common.h | 79 ++ 39 files changed, 4108 insertions(+), 50 deletions(-) create mode 100644 arch/arm/cpu/arm720t/tegra114/Makefile create mode 100644 arch/arm/cpu/arm720t/tegra114/config.mk create mode 100644 arch/arm/cpu/arm720t/tegra114/cpu.c create mode 100644 arch/arm/cpu/armv7/tegra114/Makefile create mode 100644 arch/arm/cpu/armv7/tegra114/config.mk create mode 100644 arch/arm/cpu/tegra114-common/Makefile create mode 100644 arch/arm/cpu/tegra114-common/clock.c create mode 100644 arch/arm/cpu/tegra114-common/funcmux.c create mode 100644 arch/arm/cpu/tegra114-common/pinmux.c create mode 100644 arch/arm/dts/tegra114.dtsi create mode 100644 arch/arm/include/asm/arch-tegra114/clock-tables.h create mode 100644 arch/arm/include/asm/arch-tegra114/clock.h create mode 100644 arch/arm/include/asm/arch-tegra114/flow.h create mode 100644 arch/arm/include/asm/arch-tegra114/funcmux.h create mode 100644 arch/arm/include/asm/arch-tegra114/gp_padctrl.h create mode 100644 arch/arm/include/asm/arch-tegra114/gpio.h create mode 100644 arch/arm/include/asm/arch-tegra114/hardware.h create mode 100644 arch/arm/include/asm/arch-tegra114/pinmux.h create mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h create mode 100644 arch/arm/include/asm/arch-tegra114/spl.h create mode 100644 arch/arm/include/asm/arch-tegra114/tegra.h create mode 100644 board/nvidia/dalmore/Makefile create mode 100644 board/nvidia/dalmore/dalmore.c create mode 100644 board/nvidia/dalmore/pinmux-config-dalmore.h create mode 100644 board/nvidia/dts/tegra114-dalmore.dts create mode 100644 include/configs/dalmore.h create mode 100644 include/configs/tegra114-common.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] Tegra114: Add AVP (arm720t) files
This provides SPL support for T114 boards - AVP early init, plus
CPU (A15) init/jump to main U-Boot.
Signed-off-by: Tom Warren twar...@nvidia.com
---
Changes in v2:
- update all new copyright header dates to 2013
- use CHIPID directly to figure num cpus
- set CPU2/3 bits at runtime using num cpus instead of ifdef
- remove private TRUE/FALSE defines, not needed now
- clrbits/setbits_le32 used instead of reg read//|/write
arch/arm/cpu/arm720t/tegra-common/cpu.c | 75
arch/arm/cpu/arm720t/tegra-common/cpu.h |8 +-
arch/arm/cpu/arm720t/tegra114/Makefile | 42
arch/arm/cpu/arm720t/tegra114/config.mk | 19 ++
arch/arm/cpu/arm720t/tegra114/cpu.c | 315 +++
5 files changed, 421 insertions(+), 38 deletions(-)
create mode 100644 arch/arm/cpu/arm720t/tegra114/Makefile
create mode 100644 arch/arm/cpu/arm720t/tegra114/config.mk
create mode 100644 arch/arm/cpu/arm720t/tegra114/cpu.c
diff --git a/arch/arm/cpu/arm720t/tegra-common/cpu.c
b/arch/arm/cpu/arm720t/tegra-common/cpu.c
index c32925b..b6ac0ef 100644
--- a/arch/arm/cpu/arm720t/tegra-common/cpu.c
+++ b/arch/arm/cpu/arm720t/tegra-common/cpu.c
@@ -25,30 +25,24 @@
#include asm/arch-tegra/scu.h
#include cpu.h
-enum tegra_family_t {
- TEGRA_FAMILY_T2x,
- TEGRA_FAMILY_T3x,
-};
-
-
-enum tegra_family_t get_family(void)
-{
- u32 reg, chip_id;
-
- reg = readl(NV_PA_APB_MISC_BASE + GP_HIDREV);
-
- chip_id = reg 8;
- chip_id = 0xff;
- debug( tegra_get_family: chip_id = %x\n, chip_id);
- if (chip_id == 0x30)
- return TEGRA_FAMILY_T3x;
- else
- return TEGRA_FAMILY_T2x;
-}
-
int get_num_cpus(void)
{
- return get_family() == TEGRA_FAMILY_T3x ? 4 : 2;
+ struct apb_misc_gp_ctlr *gp;
+ uint rev;
+
+ gp = (struct apb_misc_gp_ctlr *)NV_PA_APB_MISC_GP_BASE;
+ rev = (readl(gp-hidrev) HIDREV_CHIPID_MASK) HIDREV_CHIPID_SHIFT;
+
+ switch (rev) {
+ case CHIPID_TEGRA20:
+ return 2;
+ break;
+ case CHIPID_TEGRA30:
+ case CHIPID_TEGRA114:
+ default:
+ return 4;
+ break;
+ }
}
/*
@@ -56,6 +50,7 @@ int get_num_cpus(void)
*/
struct clk_pll_table tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
/* T20: 1 GHz */
+ /* n, m, p, cpcon */
{{ 1000, 13, 0, 12},/* OSC 13M */
{ 625, 12, 0, 8}, /* OSC 19.2M */
{ 1000, 12, 0, 12},/* OSC 12M */
@@ -75,6 +70,13 @@ struct clk_pll_table
tegra_pll_x_table[TEGRA_SOC_CNT][CLOCK_OSC_FREQ_COUNT] = {
{ 700, 6, 0, 8},
{ 700, 13, 0, 8},
},
+
+ /* T114: 1.4 GHz */
+ {{ 862, 8, 0, 8},
+{ 583, 8, 0, 4},
+{ 696, 12, 0, 8},
+{ 700, 13, 0, 8},
+ },
};
void adjust_pllp_out_freqs(void)
@@ -159,8 +161,8 @@ void init_pllx(void)
sel = tegra_pll_x_table[chip_type][osc];
pllx_set_rate(pll, sel-n, sel-m, sel-p, sel-cpcon);
- /* adjust PLLP_out1-4 on T30 */
- if (chip_type == TEGRA_SOC_T30) {
+ /* adjust PLLP_out1-4 on T30/T114 */
+ if (chip_type == TEGRA_SOC_T30 || chip_type == TEGRA_SOC_T114) {
debug( init_pllx: adjusting PLLP out freqs\n);
adjust_pllp_out_freqs();
}
@@ -196,10 +198,9 @@ void enable_cpu_clock(int enable)
*/
clk = readl(clkrst-crc_clk_cpu_cmplx);
clk |= 1 CPU1_CLK_STP_SHIFT;
-#if defined(CONFIG_TEGRA30)
- clk |= 1 CPU2_CLK_STP_SHIFT;
- clk |= 1 CPU3_CLK_STP_SHIFT;
-#endif
+ if (get_num_cpus() == 4)
+ clk |= (1 CPU2_CLK_STP_SHIFT) + (1 CPU3_CLK_STP_SHIFT);
+
/* Stop/Unstop the CPU clock */
clk = ~CPU0_CLK_STP_MASK;
clk |= !enable CPU0_CLK_STP_SHIFT;
@@ -285,7 +286,8 @@ void reset_A9_cpu(int reset)
void clock_enable_coresight(int enable)
{
- u32 rst, src;
+ u32 rst, src = 2;
+ int chip;
debug(clock_enable_coresight entry\n);
clock_set_enable(PERIPH_ID_CORESIGHT, enable);
@@ -301,20 +303,23 @@ void clock_enable_coresight(int enable)
* Clock divider request for 204MHz would setup CSITE clock as
* 144MHz for PLLP base 216MHz and 204MHz for PLLP base 408MHz
*/
- if (tegra_get_chip_type() == TEGRA_SOC_T30)
+ chip = tegra_get_chip_type();
+ if (chip == TEGRA_SOC_T30 || chip == TEGRA_SOC_T114)
src = CLK_DIVIDER(NVBL_PLLP_KHZ, 204000);
- else
+ else if(chip == TEGRA_SOC_T20 || chip == TEGRA_SOC_T25)
src = CLK_DIVIDER(NVBL_PLLP_KHZ, 144000);
+ else
+ printf(%s: Unknown chip type %X!\n, __func__, chip);
clock_ll_set_source_divisor(PERIPH_ID_CSI, 0, src);
/* Unlock the CPU CoreSight interfaces */
rst =
[U-Boot] [PATCH v2 1/7] Tegra114: Add arch-tegra114 include files
Common Tegra files are in arch-tegra, shared between T20/T30/T114.
Tegra114-specific headers are in arch-tegra114. Note that some of
these will be filled in as more T114 support is added (drivers,
WB/LP0 support, etc.).
Signed-off-by: Tom Warren twar...@nvidia.com
---
Changes in v2:
- update all new copyright header dates to 2013
- put OSC_FREQ defines in SoC-specific headers
- use correct BIT/BCT offsets for T114 ODMDATA
- use T30 gpio header for T114
arch/arm/include/asm/arch-tegra/clk_rst.h | 58 ++-
arch/arm/include/asm/arch-tegra/gp_padctrl.h |1 +
arch/arm/include/asm/arch-tegra/pmc.h | 12 +
arch/arm/include/asm/arch-tegra/tegra.h |3 +
arch/arm/include/asm/arch-tegra114/clock-tables.h | 402 +
arch/arm/include/asm/arch-tegra114/clock.h| 28 +
arch/arm/include/asm/arch-tegra114/flow.h | 35 ++
arch/arm/include/asm/arch-tegra114/funcmux.h | 31 +
arch/arm/include/asm/arch-tegra114/gp_padctrl.h | 59 ++
arch/arm/include/asm/arch-tegra114/gpio.h | 30 +
arch/arm/include/asm/arch-tegra114/hardware.h | 22 +
arch/arm/include/asm/arch-tegra114/pinmux.h | 618 +
arch/arm/include/asm/arch-tegra114/pmu.h | 23 +
arch/arm/include/asm/arch-tegra114/spl.h | 22 +
arch/arm/include/asm/arch-tegra114/tegra.h| 31 +
arch/arm/include/asm/arch-tegra20/clock.h |4 +
arch/arm/include/asm/arch-tegra30/clock.h |4 +
17 files changed, 1376 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/include/asm/arch-tegra114/clock-tables.h
create mode 100644 arch/arm/include/asm/arch-tegra114/clock.h
create mode 100644 arch/arm/include/asm/arch-tegra114/flow.h
create mode 100644 arch/arm/include/asm/arch-tegra114/funcmux.h
create mode 100644 arch/arm/include/asm/arch-tegra114/gp_padctrl.h
create mode 100644 arch/arm/include/asm/arch-tegra114/gpio.h
create mode 100644 arch/arm/include/asm/arch-tegra114/hardware.h
create mode 100644 arch/arm/include/asm/arch-tegra114/pinmux.h
create mode 100644 arch/arm/include/asm/arch-tegra114/pmu.h
create mode 100644 arch/arm/include/asm/arch-tegra114/spl.h
create mode 100644 arch/arm/include/asm/arch-tegra114/tegra.h
diff --git a/arch/arm/include/asm/arch-tegra/clk_rst.h
b/arch/arm/include/asm/arch-tegra/clk_rst.h
index 6a6e507..c754ec7 100644
--- a/arch/arm/include/asm/arch-tegra/clk_rst.h
+++ b/arch/arm/include/asm/arch-tegra/clk_rst.h
@@ -121,16 +121,43 @@ struct clk_rst_ctlr {
uint crc_clk_cpug_cmplx;/* _CLK_CPUG_CMPLX_0, 0x378 */
uint crc_clk_cpulp_cmplx; /* _CLK_CPULP_CMPLX_0, 0x37C */
uint crc_cpu_softrst_ctrl; /* _CPU_SOFTRST_CTRL_0, 0x380 */
- uint crc_reserved33[11];/* _reserved_33,0x384-3ac */
+ uint crc_cpu_softrst_ctrl1; /* _CPU_SOFTRST_CTR1L_0,0x384 */
+ uint crc_cpu_softrst_ctrl2; /* _CPU_SOFTRST_CTRL2_0,0x388 */
+ uint crc_reserved33[9]; /* _reserved_33,0x38c-3ac */
uint crc_clk_src_vw[TEGRA_CLK_SOURCES_VW]; /* _G3D2_0..., 0x3b0-0x42c */
/* _RST_DEV_V/W_SET_0 0x430 ~ 0x43c */
struct clk_set_clr crc_rst_dev_ex_vw[TEGRA_CLK_REGS_VW];
/* _CLK_ENB_V/W_CLR_0 0x440 ~ 0x44c */
struct clk_set_clr crc_clk_enb_ex_vw[TEGRA_CLK_REGS_VW];
- uint crc_reserved40[12];/* _reserved_40,0x450-47C */
- uint crc_pll_cfg0; /* _PLL_CFG0_0, 0x480 */
- uint crc_pll_cfg1; /* _PLL_CFG1_0, 0x484 */
- uint crc_pll_cfg2; /* _PLL_CFG2_0, 0x488 */
+ /* Additional (T114) registers */
+ uint crc_rst_cpug_cmplx_set;/* _RST_CPUG_CMPLX_SET_0, 0x450 */
+ uint crc_rst_cpug_cmplx_clr;/* _RST_CPUG_CMPLX_CLR_0, 0x454 */
+ uint crc_rst_cpulp_cmplx_set; /* _RST_CPULP_CMPLX_SET_0, 0x458 */
+ uint crc_rst_cpulp_cmplx_clr; /* _RST_CPULP_CMPLX_CLR_0, 0x45C */
+ uint crc_clk_cpug_cmplx_set;/* _CLK_CPUG_CMPLX_SET_0, 0x460 */
+ uint crc_clk_cpug_cmplx_clr;/* _CLK_CPUG_CMPLX_CLR_0, 0x464 */
+ uint crc_clk_cpulp_cmplx_set; /* _CLK_CPULP_CMPLX_SET_0, 0x468 */
+ uint crc_clk_cpulp_cmplx_clr; /* _CLK_CPULP_CMPLX_CLR_0, 0x46C */
+ uint crc_cpu_cmplx_status; /* _CPU_CMPLX_STATUS_0,0x470 */
+ uint crc_reserved40[1]; /* _reserved_40,0x474 */
+ uint crc_intstatus; /* __INTSTATUS_0, 0x478 */
+ uint crc_intmask; /* __INTMASK_0, 0x47C */
+ uint crc_utmip_pll_cfg0;/* _UTMIP_PLL_CFG0_0, 0x480 */
+ uint crc_utmip_pll_cfg1;/* _UTMIP_PLL_CFG1_0, 0x484 */
+ uint crc_utmip_pll_cfg2;/* _UTMIP_PLL_CFG2_0, 0x488 */
+
+ uint crc_plle_aux; /* _PLLE_AUX_0, 0x48C */
+ uint crc_sata_pll_cfg0; /* _SATA_PLL_CFG0_0,0x490 */
+
[U-Boot] [PATCH v2 6/7] Tegra114: Add generic Tegra114 build support
This patch adds basic Tegra114 (T114) build support - no specific
board is targeted.
Signed-off-by: Tom Warren twar...@nvidia.com
---
Changes in v2: none
board/nvidia/common/board.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index a4af539..e986fcf 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -196,7 +196,7 @@ void gpio_early_init(void) __attribute__((weak,
alias(__gpio_early_init)));
int board_early_init_f(void)
{
-#if defined(CONFIG_TEGRA30)
+#if !defined(CONFIG_TEGRA20)
pinmux_init();
#endif
board_init_uart_f();
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] Tegra114: Dalmore: Add DT files
These are stripped down for bringup, They'll be filled out later
to match-up with the kernel DT contents, and/or as devices are
brought up (mmc, usb, spi, etc.).
Signed-off-by: Tom Warren twar...@nvidia.com
---
---
Changes in v2:
- change memory size to 2GB
arch/arm/dts/tegra114.dtsi|5 +
board/nvidia/dts/tegra114-dalmore.dts | 13 +
2 files changed, 18 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/dts/tegra114.dtsi
create mode 100644 board/nvidia/dts/tegra114-dalmore.dts
diff --git a/arch/arm/dts/tegra114.dtsi b/arch/arm/dts/tegra114.dtsi
new file mode 100644
index 000..d06cd12
--- /dev/null
+++ b/arch/arm/dts/tegra114.dtsi
@@ -0,0 +1,5 @@
+/include/ skeleton.dtsi
+
+/ {
+ compatible = nvidia,tegra114;
+};
diff --git a/board/nvidia/dts/tegra114-dalmore.dts
b/board/nvidia/dts/tegra114-dalmore.dts
new file mode 100644
index 000..7315577
--- /dev/null
+++ b/board/nvidia/dts/tegra114-dalmore.dts
@@ -0,0 +1,13 @@
+/dts-v1/;
+
+/include/ ARCH_CPU_DTS
+
+/ {
+ model = NVIDIA Dalmore;
+ compatible = nvidia,dalmore, nvidia,tegra114;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x8000;
+ };
+};
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] Tegra114: Add/enable Dalmore build (T114 reference board)
This build is stripped down. It boots to the command prompt.
GPIO is the only peripheral supported. Others TBD.
Signed-off-by: Tom Warren twar...@nvidia.com
---
Changes in v2:
- update all new copyright header dates to 2013
- use correct table names in pinmux_init
board/nvidia/dalmore/Makefile| 36
board/nvidia/dalmore/dalmore.c | 32
board/nvidia/dalmore/pinmux-config-dalmore.h | 249 ++
boards.cfg |1 +
include/configs/dalmore.h| 50 +
include/configs/tegra114-common.h| 79
6 files changed, 447 insertions(+), 0 deletions(-)
create mode 100644 board/nvidia/dalmore/Makefile
create mode 100644 board/nvidia/dalmore/dalmore.c
create mode 100644 board/nvidia/dalmore/pinmux-config-dalmore.h
create mode 100644 include/configs/dalmore.h
create mode 100644 include/configs/tegra114-common.h
diff --git a/board/nvidia/dalmore/Makefile b/board/nvidia/dalmore/Makefile
new file mode 100644
index 000..699b9f6
--- /dev/null
+++ b/board/nvidia/dalmore/Makefile
@@ -0,0 +1,36 @@
+#
+# Copyright (c) 2010-2013, NVIDIA CORPORATION. All rights reserved.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms and conditions of the GNU General Public License,
+# version 2, as published by the Free Software Foundation.
+#
+# This program is distributed in the hope 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, see http://www.gnu.org/licenses/.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := $(BOARD).o
+
+SRCS := $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+
+$(LIB):$(obj).depend $(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/nvidia/dalmore/dalmore.c b/board/nvidia/dalmore/dalmore.c
new file mode 100644
index 000..aca3c7d
--- /dev/null
+++ b/board/nvidia/dalmore/dalmore.c
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2010-2013, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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, see http://www.gnu.org/licenses/.
+ */
+
+#include common.h
+#include asm/arch/pinmux.h
+#include pinmux-config-dalmore.h
+
+/*
+ * Routine: pinmux_init
+ * Description: Do individual peripheral pinmux configs
+ */
+void pinmux_init(void)
+{
+ pinmux_config_table(tegra114_pinmux_common,
+ ARRAY_SIZE(tegra114_pinmux_common));
+
+ pinmux_config_table(unused_pins_lowpower,
+ ARRAY_SIZE(unused_pins_lowpower));
+}
diff --git a/board/nvidia/dalmore/pinmux-config-dalmore.h
b/board/nvidia/dalmore/pinmux-config-dalmore.h
new file mode 100644
index 000..3dd47da
--- /dev/null
+++ b/board/nvidia/dalmore/pinmux-config-dalmore.h
@@ -0,0 +1,249 @@
+/*
+ * Copyright (c) 2010-2013, NVIDIA CORPORATION. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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, see http://www.gnu.org/licenses/.
+ */
+
+#ifndef _PINMUX_CONFIG_DALMORE_H_
+#define _PINMUX_CONFIG_DALMORE_H_
+
+#define DEFAULT_PINMUX(_pingroup, _mux, _pull, _tri, _io) \
+ { \
+ .pingroup = PINGRP_##_pingroup, \
+ .func = PMUX_FUNC_##_mux, \
+ .pull = PMUX_PULL_##_pull,\
+ .tristate = PMUX_TRI_##_tri, \
+ .io
Re: [U-Boot] [PATCH 05/15] powerpc/83xx/km: add MV88E6122 switch support for kmvect1
On Fri, 18 Jan 2013 10:14:39 +0100
Holger Brunck holger.bru...@keymile.com wrote:
On 01/18/2013 01:44 AM, Kim Phillips wrote:
On Thu, 17 Jan 2013 13:47:51 +0100
Holger Brunck holger.bru...@keymile.com wrote:
+ if (piggy_present()) {
+ uchar enetaddr[6];
+ if (eth_getenv_enetaddr(ethaddr, enetaddr)) {
+ /* increment last 3 bytes */
+ u32 val = (enetaddr[3] 16) + (enetaddr[4] 8)
+ + enetaddr[5];
+ val++;
+ enetaddr[3] = (val 16) 0xFF;
+ enetaddr[4] = (val 8) 0xFF;
+ enetaddr[5] = (val 0) 0xFF;
+ if (!eth_setenv_enetaddr(eth1addr, enetaddr)) {
+ setenv(ethact, UEC2);
+ setenv(netdev, eth1);
+ puts(using PIGGY for network boot\n);
+ } else
+ puts(using frontport for network boot\n);
+ }
+ } else
+ puts(using frontport for network boot\n);
+#endif
+
AFAIK, assigning the switch MAC address to the front port's MAC
address plus one isn't acceptable practice for u-boot board code.
Get eth1addr in the same manner ethaddr is obtained/assigned.
Because you may get a MAC adress which is already given to someone else? In
our
case this can't happen. We reserve for one instance of this board exactly two
MAC adresses. The first one is read out at startup from the inventory in
keymile/common/ivm.c. The second one is calculated like above. But it is a
unique MAC adress, because exactly this MAC adress is reserved for this board.
it can happen if if setting ethaddr from eeprom somehow fails, and/or
the user manually modifies ethaddr in the environment.
But maybe we should move the code to the location where we set ethaddr,
yes, indeed
even if the calculation would be the same?
ideally ethaddr and eth1addr would be stored as separate entities in
the eeprom.
Kim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v2 1/5] Initial net6.h
On Fri, 18 Jan 2013 14:35:28 +1300 Chris Packham judge.pack...@gmail.com wrote: From: Chris Packham chris.pack...@alliedtelesis.co.nz Has the definition of an IPv6 address and IPv6 header. It may make sense to separate the v4 support from net.h (or to include this in net.h). Signed-off-by: Chris Packham chris.pack...@alliedtelesis.co.nz --- Reviewed-by: Kim Phillips kim.phill...@freescale.com NOTICE: This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify Allied Telesis Labs Ltd immediately. Any views expressed in this message are those of the individual sender, except where the sender has the authority to issue and specifically states them to be the views of Allied Telesis Labs. get rid of this message; this is a public forum. Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Tegra: T20: Remove unused 'SLOW' SoC ID and PLLX table entry
On 01/18/2013 02:11 PM, Tom Warren wrote: Signed-off-by: Tom Warren twar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mtd: resync with Linux-3.7.1
On 01/18/2013 06:00:28 AM, Sergey Lapin wrote:
diff --git a/drivers/mtd/nand/bfin_nand.c
b/drivers/mtd/nand/bfin_nand.c
index c7ddbb2..7e755e8 100644
--- a/drivers/mtd/nand/bfin_nand.c
+++ b/drivers/mtd/nand/bfin_nand.c
@@ -374,9 +374,11 @@ int board_nand_init(struct nand_chip *chip)
if (!NAND_IS_512()) {
chip-ecc.bytes = 3;
chip-ecc.size = 256;
+ chip-ecc.strength = 1;
} else {
chip-ecc.bytes = 6;
chip-ecc.size = 512;
+ chip-ecc.strength = 2;
}
Hmm, I'm not sure that ecc.strength should be set to 2 here, if it's
really two separate 256-byte regions each of which can correct 1 bit.
2 bit correction can only be done under certain circumstances (i.e. the
errors are not in the same half).
Linux does the same thing you've done, but that was also a fix all the
drivers patch, so I'd like the input of someone familiar with the
hardware. CCing Mike Frysinger. Maybe the driver should be reporting
an ECC block size of 256 bytes? Or at least internally return the
number of bitflips from the half that had more bitflips.
chip-ecc.mode = NAND_ECC_HW;
chip-ecc.calculate = bfin_nfc_calculate_ecc;
diff --git a/drivers/mtd/nand/davinci_nand.c
b/drivers/mtd/nand/davinci_nand.c
index 04b24f3..9777878 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -613,6 +613,7 @@ void davinci_nand_init(struct nand_chip *nand)
nand-ecc.mode = NAND_ECC_HW;
nand-ecc.size = 512;
nand-ecc.bytes = 3;
+ nand-ecc.strength = 4;
nand-ecc.calculate = nand_davinci_calculate_ecc;
nand-ecc.correct = nand_davinci_correct_data;
nand-ecc.hwctl = nand_davinci_enable_hwecc;
This is in the 1-bit ECC #ifdef, so ecc.strength should be 1, and later
in CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST in should be set to 4.
diff --git a/drivers/mtd/nand/diskonchip.c
b/drivers/mtd/nand/diskonchip.c
index 104d97f..4cd741e 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -1658,6 +1658,7 @@ static int __init doc_probe(unsigned long
physadr)
nand-ecc.mode = NAND_ECC_HW_SYNDROME;
nand-ecc.size = 512;
nand-ecc.bytes = 6;
+ nand-ecc.strength = 2;
nand-bbt_options= NAND_BBT_USE_FLASH;
doc-physadr = physadr;
diff --git a/drivers/mtd/nand/fsl_elbc_nand.c
b/drivers/mtd/nand/fsl_elbc_nand.c
index 65edbf5..c3f350d 100644
--- a/drivers/mtd/nand/fsl_elbc_nand.c
+++ b/drivers/mtd/nand/fsl_elbc_nand.c
@@ -781,6 +781,12 @@ static int fsl_elbc_chip_init(int devnum, u8
*addr)
nand-ecc.size = 512;
nand-ecc.bytes = 3;
nand-ecc.steps = 1;
+ chip-ecc.strength = 1;
+ /*
+ * FIXME: can hardware ecc correct 4 bitflips if page
size is
+ * 2k? Then does hardware report number of corrections
for this
+ * case? If so, ecc_stats reporting needs to be fixed
as well.
+*/
It can correct 1 bitflip per 512 bytes. This is a similar situation to
blackfin (as far as I can tell), except that we report the actual
hardware ECC block size, so ecc.strength = 1 is clearly correct.
As for ecc_stats, read_page() is supposed to return the number of
bitflips from the ECC block with the most bitflips (see the generic
read_page implementations). This change was made to fsl_elbc_nand.c in
Linux. Note that all of the conversions of read_page() functions to
simply return zero seem to be incorrect, and should be returning
max_bitflips.
diff --git a/drivers/mtd/nand/fsl_ifc_nand.c
b/drivers/mtd/nand/fsl_ifc_nand.c
index 5d47b40..823a2eb 100644
--- a/drivers/mtd/nand/fsl_ifc_nand.c
+++ b/drivers/mtd/nand/fsl_ifc_nand.c
@@ -871,6 +871,7 @@ int board_nand_init(struct nand_chip *nand)
/* Hardware generates ECC per 512 Bytes */
nand-ecc.size = 512;
nand-ecc.bytes = 8;
+ nand-ecc.strength = 1;
switch (csor CSOR_NAND_PGS_MASK) {
case CSOR_NAND_PGS_512:
IFC has ECC strength of 4 or 8 depending on ECC mode. It also needs
max_bitflips handling in read_page().
diff --git a/drivers/mtd/nand/jz4740_nand.c
b/drivers/mtd/nand/jz4740_nand.c
index 3ec34f3..3f64dc3 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -253,6 +253,11 @@ int board_nand_init(struct nand_chip *nand)
nand-ecc.mode = NAND_ECC_HW_OOB_FIRST;
nand-ecc.size = CONFIG_SYS_NAND_ECCSIZE;
nand-ecc.bytes = CONFIG_SYS_NAND_ECCBYTES;
+ nand-ecc.strength = 2;
+ /*
+ * FIXME: ecc_strength value of 2 bits per 512 bytes of data is
a
+* conservative guess, given 9 ecc bytes and reed-solomon alg.
Re: [U-Boot] [PATCH v2 1/7] Tegra114: Add arch-tegra114 include files
On 01/18/2013 02:12 PM, Tom Warren wrote:
Common Tegra files are in arch-tegra, shared between T20/T30/T114.
Tegra114-specific headers are in arch-tegra114. Note that some of
these will be filled in as more T114 support is added (drivers,
WB/LP0 support, etc.).
diff --git a/arch/arm/include/asm/arch-tegra/tegra.h
b/arch/arm/include/asm/arch-tegra/tegra.h
index 013a3c5..2dbe6a3 100644
--- a/arch/arm/include/asm/arch-tegra/tegra.h
+++ b/arch/arm/include/asm/arch-tegra/tegra.h
@@ -73,6 +73,7 @@ enum {
SKU_ID_AP25E= 0x1b,
SKU_ID_T25E = 0x1c,
SKU_ID_T30 = 0x81, /* Cardhu value */
+ SKU_ID_T114 = 0x00, /* Dalmore value */
I believe a SKU ID of 0 indicates an unfused or engineering part. I'll
try to find the relevant email and forward it to you off-list. As such,
I think it'll save us trouble in the future if you simply rename that
SKU_ID_T114_UNFUSED/GENERIC/ENG/ENGINEERING to make it explicit what
this means. You should probably talk to someone internally to confirm
the best terminology to use here; probably whoever originally sent the
email that I'll try to forward to you. I think you can make such a
trivial symbol renaming change when you apply the patch, without
reposting the patches, unless any other changes are needed.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] Tegra114: Add AVP (arm720t) files
On 01/18/2013 02:12 PM, Tom Warren wrote:
This provides SPL support for T114 boards - AVP early init, plus
CPU (A15) init/jump to main U-Boot.
+void powerup_cpus(void)
+{
+ debug(powerup_cpus entry\n);
+
+ /* Are we booting to the fast cluster? */
+ if (get_cluster_id() == 0) {
+ debug(powerup_cpus entry: G cluster\n);
+ /* Power up the fast cluster rail partition */
+ power_partition(CRAIL, CRAILID);
+
+ /* Power up the fast cluster non-CPU partition */
+ power_partition(C0NC, C0NCID);
+
+ /* Power up the fast cluster CPU0 partition */
+ power_partition(CE0, CE0ID);
+ } else {
+ debug(powerup_cpus entry: LP cluster\n);
+ /* Power up the slow cluster non-CPU partition */
+ power_partition(C1NC, C1NCID);
+
+ /* Power up the slow cluster CPU partition */
+ power_partition(CELP, CELPID);
+ }
+}
I strongly believe we should determine why that is needed rather than
blindly upstreaming it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 7/7] Tegra114: Add/enable Dalmore build (T114 reference board)
On 01/18/2013 02:12 PM, Tom Warren wrote: This build is stripped down. It boots to the command prompt. GPIO is the only peripheral supported. Others TBD. Aside from the couple of comment I already made, the series briefly, Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/7] Tegra114: Add AVP (arm720t) files
On 01/18/2013 05:01 PM, Stephen Warren wrote:
On 01/18/2013 02:12 PM, Tom Warren wrote:
This provides SPL support for T114 boards - AVP early init, plus
CPU (A15) init/jump to main U-Boot.
+void powerup_cpus(void)
+{
+debug(powerup_cpus entry\n);
+
+/* Are we booting to the fast cluster? */
+if (get_cluster_id() == 0) {
+debug(powerup_cpus entry: G cluster\n);
+/* Power up the fast cluster rail partition */
+power_partition(CRAIL, CRAILID);
+
+/* Power up the fast cluster non-CPU partition */
+power_partition(C0NC, C0NCID);
+
+/* Power up the fast cluster CPU0 partition */
+power_partition(CE0, CE0ID);
+} else {
+debug(powerup_cpus entry: LP cluster\n);
+/* Power up the slow cluster non-CPU partition */
+power_partition(C1NC, C1NCID);
+
+/* Power up the slow cluster CPU partition */
+power_partition(CELP, CELPID);
+}
+}
I strongly believe we should determine why that is needed rather than
blindly upstreaming it.
Thinking about this more, this makes even less sense. When Tegra boots,
code runs on the AVP. That code is U-Boot. U-Boot then boots the A15
cores, and hence U-Boot is what decides whether to boot the LP or G
cluster; it doesn't follow some decision by some other SW since there is
no other SW.
The only possible exception to this might be resume from some low-power
state where you want to restart the same A15 cluster as was running
prior to entering sleep. But that would require the flow controller
register read by get_cluster_id() to be in an always-on power domain.
I'm not sure if that's true or not. (If it isnt', presumably the
power-on state would always be static, hence there would be no need to
read the register).
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/85xx: select -mcpu=8540 to match -Wa, e500
This allows building with toolchains that by default target e6500. When targetting e6500, GCC generates a two-operand form of mfcr which gas normally maps to mfocr. However, when we tell gas to target e500 rather than e6500, it rejects two-operand mfcr. Tell GCC to target a least-common-denominator e500 to match what we tell the assembler. -misel and -mno-strict-align are added to keep the code size from growing (it actually ends up shrinking a bit compared to -mcpu=603e, which was the default on my old toolchain). Signed-off-by: Scott Wood scottw...@freescale.com --- v2: add -misel and -mno-strict-align arch/powerpc/cpu/mpc85xx/config.mk |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc85xx/config.mk b/arch/powerpc/cpu/mpc85xx/config.mk index f36d823..450d511 100644 --- a/arch/powerpc/cpu/mpc85xx/config.mk +++ b/arch/powerpc/cpu/mpc85xx/config.mk @@ -23,7 +23,8 @@ PLATFORM_RELFLAGS += -meabi -PLATFORM_CPPFLAGS += -ffixed-r2 -Wa,-me500 -msoft-float -mno-string +PLATFORM_CPPFLAGS += -ffixed-r2 -mcpu=8540 -misel -mno-strict-align \ + -Wa,-me500 -msoft-float -mno-string # -mspe=yes is needed to have -mno-spe accepted by a buggy GCC; # see [PATCH,rs6000] make -mno-spe work as expected on -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: add support for MMUv2 page sizes
e6500 implements MMUv2 and supports power-of-2 page sizes rather than
power-of-4. Add support for such pages.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/cpu/mpc85xx/start.S |2 +-
arch/powerpc/cpu/mpc85xx/tlb.c | 21 +++
arch/powerpc/include/asm/mmu.h | 52 +-
3 files changed, 51 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index bb0dc1a..fb67469 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -449,7 +449,7 @@ nexti: mflrr1 /* R1 = our PC */
/* Set the size of the TLB to 4KB */
mfspr r3, MAS1
- li r2, 0xF00
+ li r2, 0xF80
andcr3, r3, r2 /* Clear the TSIZE bits */
ori r3, r3, MAS1_TSIZE(BOOKE_PAGESZ_4K)@l
orisr3, r3, MAS1_IPROT@h
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
index f44fadc..de65f30 100644
--- a/arch/powerpc/cpu/mpc85xx/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/tlb.c
@@ -66,7 +66,7 @@ void read_tlbcam_entry(int idx, u32 *valid, u32 *tsize,
unsigned long *epn,
_mas1 = mfspr(MAS1);
*valid = (_mas1 MAS1_VALID);
- *tsize = (_mas1 8) 0xf;
+ *tsize = (_mas1 7) 0x1f;
*epn = mfspr(MAS2) MAS2_EPN;
*rpn = mfspr(MAS3) MAS3_RPN;
#ifdef CONFIG_ENABLE_36BIT_PHYS
@@ -156,6 +156,15 @@ void set_tlb(u8 tlb, u32 epn, u64 rpn,
if (tlb == 1)
use_tlb_cam(esel);
+ if ((mfspr(SPRN_MMUCFG) MMUCFG_MAVN) == MMUCFG_MAVN_V1
+ tsize 1) {
+#ifndef CONFIG_SPL_MINIMAL
+ printf(%s: bad tsize %d on entry %d at 0x%08x\n,
+ __func__, tsize, tlb, epn);
+#endif
+ return;
+ }
+
_mas0 = FSL_BOOKE_MAS0(tlb, esel, 0);
_mas1 = FSL_BOOKE_MAS1(1, iprot, 0, ts, tsize);
_mas2 = FSL_BOOKE_MAS2(epn, wimge);
@@ -251,7 +260,7 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
unsigned int tlb_size;
unsigned int wimge = MAS2_M;
unsigned int ram_tlb_address = (unsigned int)CONFIG_SYS_DDR_SDRAM_BASE;
- unsigned int max_cam;
+ unsigned int max_cam, tsize_mask;
u64 size, memsize = (u64)memsize_in_meg 20;
#ifdef CONFIG_SYS_PPC_DDR_WIMGE
@@ -261,15 +270,17 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
if ((mfspr(SPRN_MMUCFG) MMUCFG_MAVN) == MMUCFG_MAVN_V1) {
/* Convert (4^max) kB to (2^max) bytes */
max_cam = ((mfspr(SPRN_TLB1CFG) 16) 0xf) * 2 + 10;
+ tsize_mask = ~1U;
} else {
/* Convert (2^max) kB to (2^max) bytes */
max_cam = __ilog2(mfspr(SPRN_TLB1PS)) + 10;
+ tsize_mask = ~0U;
}
for (i = 0; size i 8; i++) {
int ram_tlb_index = find_free_tlbcam();
- u32 camsize = __ilog2_u64(size) ~1U;
- u32 align = __ilog2(ram_tlb_address) ~1U;
+ u32 camsize = __ilog2_u64(size) tsize_mask;
+ u32 align = __ilog2(ram_tlb_address) tsize_mask;
if (ram_tlb_index == -1)
break;
@@ -281,7 +292,7 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
if (camsize max_cam)
camsize = max_cam;
- tlb_size = (camsize - 10) / 2;
+ tlb_size = camsize - 10;
set_tlb(1, ram_tlb_address, p_addr,
MAS3_SX|MAS3_SW|MAS3_SR, wimge,
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 2e0e292..b700a3a 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -401,8 +401,8 @@ extern void print_bats(void);
#define MAS1_IPROT 0x4000
#define MAS1_TID(x)(((x) 16) 0x3FFF)
#define MAS1_TS0x1000
-#define MAS1_TSIZE(x) (((x) 8) 0x0F00)
-#define TSIZE_TO_BYTES(x) (1ULL (((x) * 2) + 10))
+#define MAS1_TSIZE(x) (((x) 7) 0x0F80)
+#define TSIZE_TO_BYTES(x) (1ULL ((x) + 10))
#define MAS2_EPN 0xF000
#define MAS2_X00x0040
@@ -458,22 +458,38 @@ extern void print_bats(void);
#define FSL_BOOKE_MAS7(rpn) \
(((u64)(rpn)) 32)
-#define BOOKE_PAGESZ_1K 0
-#define BOOKE_PAGESZ_4K 1
-#define BOOKE_PAGESZ_16K2
-#define BOOKE_PAGESZ_64K3
-#define BOOKE_PAGESZ_256K 4
-#define BOOKE_PAGESZ_1M 5
-#define BOOKE_PAGESZ_4M 6
-#define BOOKE_PAGESZ_16M7
-#define BOOKE_PAGESZ_64M8
-#define BOOKE_PAGESZ_256M 9
-#define BOOKE_PAGESZ_1G10
-#define BOOKE_PAGESZ_4G11
-#define BOOKE_PAGESZ_16GB 12
-#define BOOKE_PAGESZ_64GB 13
-#define BOOKE_PAGESZ_256GB 14
-#define BOOKE_PAGESZ_1TB
[U-Boot] [PATCH] serial/ns16550: don't generate functions for undefined ports
This saved 640 bytes on MPC8536DS (a board with two of the six
ports defined).
Signed-off-by: Scott Wood scottw...@freescale.com
---
drivers/serial/serial_ns16550.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/serial/serial_ns16550.c b/drivers/serial/serial_ns16550.c
index fc01a3c..b92eef4 100644
--- a/drivers/serial/serial_ns16550.c
+++ b/drivers/serial/serial_ns16550.c
@@ -247,24 +247,36 @@ serial_setbrg_dev(unsigned int dev_index)
_serial_setbrg(dev_index);
}
+#if defined(CONFIG_SYS_NS16550_COM1)
DECLARE_ESERIAL_FUNCTIONS(1);
struct serial_device eserial1_device =
INIT_ESERIAL_STRUCTURE(1, eserial0);
+#endif
+#if defined(CONFIG_SYS_NS16550_COM2)
DECLARE_ESERIAL_FUNCTIONS(2);
struct serial_device eserial2_device =
INIT_ESERIAL_STRUCTURE(2, eserial1);
+#endif
+#if defined(CONFIG_SYS_NS16550_COM3)
DECLARE_ESERIAL_FUNCTIONS(3);
struct serial_device eserial3_device =
INIT_ESERIAL_STRUCTURE(3, eserial2);
+#endif
+#if defined(CONFIG_SYS_NS16550_COM4)
DECLARE_ESERIAL_FUNCTIONS(4);
struct serial_device eserial4_device =
INIT_ESERIAL_STRUCTURE(4, eserial3);
+#endif
+#if defined(CONFIG_SYS_NS16550_COM5)
DECLARE_ESERIAL_FUNCTIONS(5);
struct serial_device eserial5_device =
INIT_ESERIAL_STRUCTURE(5, eserial4);
+#endif
+#if defined(CONFIG_SYS_NS16550_COM6)
DECLARE_ESERIAL_FUNCTIONS(6);
struct serial_device eserial6_device =
INIT_ESERIAL_STRUCTURE(6, eserial5);
+#endif
__weak struct serial_device *default_serial_console(void)
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/mpc85xx: add support for MMUv2 page sizes
e6500 implements MMUv2 and supports power-of-2 page sizes rather than
power-of-4. Add support for such pages.
Signed-off-by: Scott Wood scottw...@freescale.com
---
v2: remove #ifdef CONFIG_SPL_MINIMAL around printf -- the whole function
is in an area not built in the SPL
arch/powerpc/cpu/mpc85xx/start.S |2 +-
arch/powerpc/cpu/mpc85xx/tlb.c | 19 ++
arch/powerpc/include/asm/mmu.h | 52 +-
3 files changed, 49 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index bb0dc1a..fb67469 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -449,7 +449,7 @@ nexti: mflrr1 /* R1 = our PC */
/* Set the size of the TLB to 4KB */
mfspr r3, MAS1
- li r2, 0xF00
+ li r2, 0xF80
andcr3, r3, r2 /* Clear the TSIZE bits */
ori r3, r3, MAS1_TSIZE(BOOKE_PAGESZ_4K)@l
orisr3, r3, MAS1_IPROT@h
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
index f44fadc..23d3357 100644
--- a/arch/powerpc/cpu/mpc85xx/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/tlb.c
@@ -66,7 +66,7 @@ void read_tlbcam_entry(int idx, u32 *valid, u32 *tsize,
unsigned long *epn,
_mas1 = mfspr(MAS1);
*valid = (_mas1 MAS1_VALID);
- *tsize = (_mas1 8) 0xf;
+ *tsize = (_mas1 7) 0x1f;
*epn = mfspr(MAS2) MAS2_EPN;
*rpn = mfspr(MAS3) MAS3_RPN;
#ifdef CONFIG_ENABLE_36BIT_PHYS
@@ -156,6 +156,13 @@ void set_tlb(u8 tlb, u32 epn, u64 rpn,
if (tlb == 1)
use_tlb_cam(esel);
+ if ((mfspr(SPRN_MMUCFG) MMUCFG_MAVN) == MMUCFG_MAVN_V1
+ tsize 1) {
+ printf(%s: bad tsize %d on entry %d at 0x%08x\n,
+ __func__, tsize, tlb, epn);
+ return;
+ }
+
_mas0 = FSL_BOOKE_MAS0(tlb, esel, 0);
_mas1 = FSL_BOOKE_MAS1(1, iprot, 0, ts, tsize);
_mas2 = FSL_BOOKE_MAS2(epn, wimge);
@@ -251,7 +258,7 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
unsigned int tlb_size;
unsigned int wimge = MAS2_M;
unsigned int ram_tlb_address = (unsigned int)CONFIG_SYS_DDR_SDRAM_BASE;
- unsigned int max_cam;
+ unsigned int max_cam, tsize_mask;
u64 size, memsize = (u64)memsize_in_meg 20;
#ifdef CONFIG_SYS_PPC_DDR_WIMGE
@@ -261,15 +268,17 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
if ((mfspr(SPRN_MMUCFG) MMUCFG_MAVN) == MMUCFG_MAVN_V1) {
/* Convert (4^max) kB to (2^max) bytes */
max_cam = ((mfspr(SPRN_TLB1CFG) 16) 0xf) * 2 + 10;
+ tsize_mask = ~1U;
} else {
/* Convert (2^max) kB to (2^max) bytes */
max_cam = __ilog2(mfspr(SPRN_TLB1PS)) + 10;
+ tsize_mask = ~0U;
}
for (i = 0; size i 8; i++) {
int ram_tlb_index = find_free_tlbcam();
- u32 camsize = __ilog2_u64(size) ~1U;
- u32 align = __ilog2(ram_tlb_address) ~1U;
+ u32 camsize = __ilog2_u64(size) tsize_mask;
+ u32 align = __ilog2(ram_tlb_address) tsize_mask;
if (ram_tlb_index == -1)
break;
@@ -281,7 +290,7 @@ setup_ddr_tlbs_phys(phys_addr_t p_addr, unsigned int
memsize_in_meg)
if (camsize max_cam)
camsize = max_cam;
- tlb_size = (camsize - 10) / 2;
+ tlb_size = camsize - 10;
set_tlb(1, ram_tlb_address, p_addr,
MAS3_SX|MAS3_SW|MAS3_SR, wimge,
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 2e0e292..b700a3a 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -401,8 +401,8 @@ extern void print_bats(void);
#define MAS1_IPROT 0x4000
#define MAS1_TID(x)(((x) 16) 0x3FFF)
#define MAS1_TS0x1000
-#define MAS1_TSIZE(x) (((x) 8) 0x0F00)
-#define TSIZE_TO_BYTES(x) (1ULL (((x) * 2) + 10))
+#define MAS1_TSIZE(x) (((x) 7) 0x0F80)
+#define TSIZE_TO_BYTES(x) (1ULL ((x) + 10))
#define MAS2_EPN 0xF000
#define MAS2_X00x0040
@@ -458,22 +458,38 @@ extern void print_bats(void);
#define FSL_BOOKE_MAS7(rpn) \
(((u64)(rpn)) 32)
-#define BOOKE_PAGESZ_1K 0
-#define BOOKE_PAGESZ_4K 1
-#define BOOKE_PAGESZ_16K2
-#define BOOKE_PAGESZ_64K3
-#define BOOKE_PAGESZ_256K 4
-#define BOOKE_PAGESZ_1M 5
-#define BOOKE_PAGESZ_4M 6
-#define BOOKE_PAGESZ_16M7
-#define BOOKE_PAGESZ_64M8
-#define BOOKE_PAGESZ_256M 9
-#define BOOKE_PAGESZ_1G10
-#define BOOKE_PAGESZ_4G11
-#define BOOKE_PAGESZ_16GB 12
-#define
Re: [U-Boot] [Patch v2] Introduce a global bool type
On Mon, Jan 07, 2013 at 03:55:48PM -0800, York Sun wrote: 'bool' is defined in random places. This patch consolidates them into a single typedef, using _Bool introduced in C99. Signed-off-by: York Sun york...@freescale.com --- Change since v1: Move 'false' and 'true' to the common header file. Need help from other arch maintainers to test it. I could only test powerpc. Thank you for taking this on, it's definately in need of cleanup. There are also many duplicate definitions of the upper case variants (BOOL/TRUE/FALSE). Those should get fixed too. +typedef _Bool bool; +#define false 0 +#define true 1 + Linux defines true/false as an enum type in stddef.h, since u-boot already has a copy of this Linux header, shouldn't it go in there? -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Patch v2] Introduce a global bool type
On Mon, Jan 07, 2013 at 10:29:28PM -0800, Wolfgang Denk wrote: Dear York Sun, In message 1357602948-16848-1-git-send-email-york...@freescale.com you wrote: 'bool' is defined in random places. This patch consolidates them into a single typedef, using _Bool introduced in C99. Signed-off-by: York Sun york...@freescale.com --- Change since v1: Move 'false' and 'true' to the common header file. Please see Måns Rullgård's comment about using stdbool.h instead. Isn't stdbool.h more for backward compatability for user space programs, so only newer C99 aware programs can opt-in to the new data type? Linux for example doesn't use stdbool.h, it puts the definition of bool in types.h, and true/false in stddef.h. Since, like Linux, u-boot is a single codebase, all the data types can go in a common place and not have to worry about breaking old programs with new types. Then please make sure that a sufficient number of tool chains as well as configurations using USE_PRIVATE_LIBGCC continue to work, i. e. in a first step verify that these are still compile-clean. If you cc me on newer versions of the patch I can help verify on tegra, which uses USE_PRIVATE_LIBGCC. -Allen -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
