[U-Boot] [PATCH v2] net, phy, cpsw: fix NULL pointer deference
if phy_connect() did not find a phy, phydev is NULL and
following code in cpsw_phy_init() crashes. Fix this.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Mugunthan V N mugunthan...@ti.com
Cc: Tom Rini tr...@ti.com
---
- changes for v2:
- change commit message as it is a NULL pointer deference error
not an unaligned access problem, as Tom Rini mentioned
- fix more places in the driver with NULL pointer problem
Found on the dxr2 board with no phy connected to the board,
U-Boot crashes with:
U-Boot 2013.07-12701-gea98378-dirty (Sep 04 2013 - 06:58:16)
I2C: ready
DRAM: 128 MiB
Enable d-cache
FactorySet is not right in eeprom.
NAND: 256 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
8-bit BCH HW ECC selected
Net: Could not get PHY for cpsw: addr 0
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [87f80574] lr : [87f80fcc]
sp : 86f5aee0 ip : 0034 fp : 80100020
r10: 0014 r9 : 07e5d000 r8 : 86f5af30
r7 : 86f5f750 r6 : 86f5f804 r5 : 86f5f708 r4 : 86f5f750
r3 : r2 : r1 : 87fa4d08 r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
---
drivers/net/cpsw.c | 26 +-
1 Datei geändert, 25 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 9bab71a..186665b 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -561,6 +561,9 @@ static inline void setbit_and_wait_for_clear32(void *addr)
static void cpsw_set_slave_mac(struct cpsw_slave *slave,
struct cpsw_priv *priv)
{
+ if (!priv)
+ return;
+
__raw_writel(mac_hi(priv-dev-enetaddr), slave-regs-sa_hi);
__raw_writel(mac_lo(priv-dev-enetaddr), slave-regs-sa_lo);
}
@@ -568,9 +571,17 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
static void cpsw_slave_update_link(struct cpsw_slave *slave,
struct cpsw_priv *priv, int *link)
{
- struct phy_device *phy = priv-phydev;
+ struct phy_device *phy;
u32 mac_control = 0;
+ if (!priv)
+ return;
+
+ phy = priv-phydev;
+
+ if (!phy)
+ return;
+
phy_startup(phy);
*link = phy-link;
@@ -604,8 +615,12 @@ static int cpsw_update_link(struct cpsw_priv *priv)
int link = 0;
struct cpsw_slave *slave;
+ if (!priv)
+ return -1;
+
for_each_slave(slave, priv)
cpsw_slave_update_link(slave, priv, link);
+
priv-mdio_link = readl(mdio_regs-link);
return link;
}
@@ -614,6 +629,9 @@ static int cpsw_check_link(struct cpsw_priv *priv)
{
u32 link = 0;
+ if (!priv)
+ return -1;
+
link = __raw_readl(mdio_regs-link) priv-phy_mask;
if ((link) (link == priv-mdio_link))
return 1;
@@ -623,6 +641,9 @@ static int cpsw_check_link(struct cpsw_priv *priv)
static inline u32 cpsw_get_slave_port(struct cpsw_priv *priv, u32 slave_num)
{
+ if (!priv)
+ return -1;
+
if (priv-host_port == 0)
return slave_num + 1;
else
@@ -947,6 +968,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct
cpsw_slave *slave)
dev,
slave-data-phy_if);
+ if (!phydev)
+ return -1;
+
phydev-supported = supported;
phydev-advertising = phydev-supported;
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] net, phy: fix NULL pointer deference
if phydev is a NULL pointer, code crash, so add check if phydev != NULL
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Andy Fleming aflem...@freescale.com
Cc: Kumar Gala ga...@kernel.crashing.org
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Tom Rini tr...@ti.com
---
Found on the dxr2 board with no phy connected to the board,
U-Boot crashes with:
U-Boot# tftp 0x8020 /tftpboot/dxr2/u-boot.bin
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [87f80ffc] lr : [87f7fbdc]
sp : 86f5ace0 ip : ff00 fp : 87f9a2c2
r10: r9 : 87f9a2c7 r8 : 86f5af30
r7 : r6 : 86f5f750 r5 : 86f5f7f0 r4 : 86f5f750
r3 : 86f5f804 r2 : 86f5f7f0 r1 : 0014 r0 :
Flags: Nzcv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
resetting ...
---
drivers/net/phy/phy.c | 30 ++
1 Datei geändert, 30 Zeilen hinzugefügt(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 62925bb..4885100 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -36,6 +36,9 @@ static int genphy_config_advert(struct phy_device *phydev)
int oldadv, adv;
int err, changed = 0;
+ if (!phydev)
+ return -1;
+
/* Only allow advertising what
* this PHY supports */
phydev-advertising = phydev-supported;
@@ -114,6 +117,9 @@ static int genphy_setup_forced(struct phy_device *phydev)
int err;
int ctl = 0;
+ if (!phydev)
+ return -1;
+
phydev-pause = phydev-asym_pause = 0;
if (SPEED_1000 == phydev-speed)
@@ -166,6 +172,9 @@ int genphy_config_aneg(struct phy_device *phydev)
{
int result;
+ if (!phydev)
+ return -1;
+
if (AUTONEG_ENABLE != phydev-autoneg)
return genphy_setup_forced(phydev);
@@ -206,6 +215,9 @@ int genphy_update_link(struct phy_device *phydev)
{
unsigned int mii_reg;
+ if (!phydev)
+ return -1;
+
/*
* Wait if the link is up, and autonegotiation is in progress
* (ie - we're capable and it's not done)
@@ -274,6 +286,9 @@ int genphy_parse_link(struct phy_device *phydev)
{
int mii_reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMSR);
+ if (!phydev)
+ return -1;
+
/* We're using autonegotiation */
if (mii_reg BMSR_ANEGCAPABLE) {
u32 lpa = 0;
@@ -365,6 +380,9 @@ int genphy_config(struct phy_device *phydev)
int val;
u32 features;
+ if (!phydev)
+ return -1;
+
/* For now, I'll claim that the generic driver supports
* all possible port types */
features = (SUPPORTED_TP | SUPPORTED_MII
@@ -495,6 +513,9 @@ static int phy_probe(struct phy_device *phydev)
{
int err = 0;
+ if (!phydev)
+ return -1;
+
phydev-advertising = phydev-supported = phydev-drv-features;
phydev-mmds = phydev-drv-mmds;
@@ -782,6 +803,9 @@ struct phy_device *phy_connect(struct mii_dev *bus, int
addr,
*/
int phy_startup(struct phy_device *phydev)
{
+ if (!phydev)
+ return -1;
+
if (phydev-drv-startup)
return phydev-drv-startup(phydev);
@@ -790,6 +814,9 @@ int phy_startup(struct phy_device *phydev)
static int __board_phy_config(struct phy_device *phydev)
{
+ if (!phydev)
+ return -1;
+
if (phydev-drv-config)
return phydev-drv-config(phydev);
return 0;
@@ -808,6 +835,9 @@ int phy_config(struct phy_device *phydev)
int phy_shutdown(struct phy_device *phydev)
{
+ if (!phydev)
+ return -1;
+
if (phydev-drv-shutdown)
phydev-drv-shutdown(phydev);
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
Dear Scott Wood, On 04.09.13 21:44, Scott Wood wrote: On Wed, 2013-09-04 at 17:15 +0200, Andreas Bießmann wrote: On 09/04/2013 02:46 PM, Bo Shen wrote: On 9/4/2013 8:30 PM, Andreas Bießmann wrote: Yes, we need libbch. If we really want to enable software BCH support. It also need add following two options in board configuration file. ---8--- #define CONFIG_NAND_ECC_BCH #define CONFIG_BCH ---8--- So, this patch give us option to enable software BCH. got it. So the NAND_ECC_BCH is the adoption for the SW BCH correction in mtd layer. I understand that this would be helpful for at91 SoC without PMECC HW. But there is no user currently, so I hesitate to apply this. Frankly, there is no EK boards from Atmel use software BCH now, however, a lot of customers use NAND with 224 bytes OOB, can not use software ECC, they need use software BCH. I understand this. But it will be a piece of dead code until a user of it would be submitted. So, I think it is better to apply this patch. If it will break the rule of u-boot, then I think we can wait real user in u-boot need this and then apply this patch. I'd like to hear Scott's comment on that. Is this for the benefit of out-of-tree boards, or for boards which will be submitted but haven't yet? In the latter case, it could be submitted at the same time. In the former case, of course we encourage the boards to be submitted, and we don't generally add code solely for the benefit of out-of-tree boards. In any case, this is minor enough that I don't care all that much. If we ever get kconfig, then hopefully the dead code rules will relax to code which could be enabled through some legal config, rather than code which is enabled in some default config for a board. Things like allyesconfig and randconfig could help with build test coverage. I think this is a 'yes we take it'. Scott, would you pull it in or should I do? Is it even that minor to pull it into 2013.10? It was posted weeks after merge window closed. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sf:eon: Add support for EN25S64
Add support for EON EN25S64 SPI flash memory
Features: 64Mb size, 1.8V, 4KB sector
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
---
drivers/mtd/spi/eon.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/eon.c b/drivers/mtd/spi/eon.c
index 25cfc12..45a0052 100644
--- a/drivers/mtd/spi/eon.c
+++ b/drivers/mtd/spi/eon.c
@@ -27,6 +27,11 @@ static const struct eon_spi_flash_params
eon_spi_flash_table[] = {
.nr_sectors = 4096,
.name = EN25Q128,
},
+ {
+ .idcode1 = 0x3817,
+ .nr_sectors = 4096,
+ .name = EN25S64,
+ },
};
struct spi_flash *spi_flash_probe_eon(struct spi_slave *spi, u8 *idcode)
--
1.7.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
于 2013年09月04日 23:46, Hector Palacios 写道:
Dear Marek,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Huang Shijie,
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
Dear Huang Shijie,
How come hector was then able to write his JFFS2 partition ?
If he uses the gpmi, he should not write the JFFS2, since the gpmi
does not support the jffs2. He will get the failure in the end.
Hector, can you comment on this?
I don't think I'm following these comments. The facts are:
1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
a) does not mount on kernel v3.10
b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from
Huang
(actually I didn't use linux-next but instead a v3.10 where I merged
all the commits done to MTD in linux-next, which are a lot).
2) A JFFS2 filesystem image written with U-Boot v2013.01
a) mounts OK on old FSL kernel 2.6.35
b) does not mount on kernel v3.10 (neither on v3.8, I believe).
c) does not mount on linux-next with the patchset [1]
The gpmi driver in FSL kernel 2.6.35 is different from the linux-next or
linux v3.10.
We have abandoned the old gpmi driver, and we use the same gpmi code in
current FSL kernel.
Since we swtich to the upstream gpmi code, and it could not support the
jffs2,
and that's why you mount always failed.
[1]
http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
Marek, could you please confirm 2b on your side, just in case I'm
doing anything wrong in my custom U-Boot?
So the jffs2 support is compatiable all the time.
Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
after applying this patchset?
Not compatible.
This patch set is still underreview.
So this patch breaks compatiblity with FSL kernel release? This needs
fixing,
otherwise it's impossible to do a drop-in replacement for the ancient
FSL
kernel.
that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.
Ok, does that mean that we need this patchset in U-Boot in order to
properly write JFFS2 onto GPMI NAND there? Is that the message you
wanted to relay to us?
Besides this patchset, the u-boot needs more patches to sync with the
kernel mtd code. Such as the full-id features.
Can you elaborate on this more? This is very vague, I would like to
know what
exactly is missing.
92a2645 mtd: add 4 Toshiba nand chips for the full-id case
ec6e87e mtd: add the support to parse out the full-id nand type
f22d5f6 mtd: add new fields to nand_flash_dev{}
2febcdf mtd: gpmi: set the BCH's geometry with the ecc info
d1048aa mtd: add the ecc info for some full-id nand chips
5721934 mtd: parse out the ECC info for the full-id nand chips
2dc0bdd mtd: add ECC info for nand_flash_dev{}
e2985fc mtd: replace the hardcode with the onfi_feature()
6dcbe0c mtd: get the ECC info from the Extended Parameter Page
5b40db6 mtd: add a helper to get the supported features for ONFI nand
5138a98 mtd: add data structures for Extended Parameter Page
10c86ba mtd: get the ECC info from the parameter page for ONFI nand
4cfeca2 mtd: add datasheet's ECC information to nand_chip{}
Yes, please, we need more details. This seems to be related with how
the MTD drivers (in Linux and in U-Boot) access the OOB area to store
the JFFS2 cleanmarkers, right?
The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
if (!oinfo || oinfo-oobavail == 0) {
pr_err(inconsistent device description\n);
return -EINVAL;
}
Before apply the patches above, the gpmi will use all the oob, so
oinfo-oobavail == 0 becomes true.
After apply the patches, the gpmi will not use all the oob for the ONFI
SLC nand or the full-id nand,
and it can supports the jffs2 when you apply the other SLC/MLC patchset.
thanks
Huang Shijie
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net, phy, cpsw: fix NULL pointer deference
On Thursday 05 September 2013 11:35 AM, Heiko Schocher wrote:
if phy_connect() did not find a phy, phydev is NULL and
following code in cpsw_phy_init() crashes. Fix this.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Mugunthan V N mugunthan...@ti.com
Cc: Tom Rini tr...@ti.com
---
- changes for v2:
- change commit message as it is a NULL pointer deference error
not an unaligned access problem, as Tom Rini mentioned
- fix more places in the driver with NULL pointer problem
Found on the dxr2 board with no phy connected to the board,
U-Boot crashes with:
U-Boot 2013.07-12701-gea98378-dirty (Sep 04 2013 - 06:58:16)
I2C: ready
DRAM: 128 MiB
Enable d-cache
FactorySet is not right in eeprom.
NAND: 256 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
8-bit BCH HW ECC selected
Net: Could not get PHY for cpsw: addr 0
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [87f80574] lr : [87f80fcc]
sp : 86f5aee0 ip : 0034 fp : 80100020
r10: 0014 r9 : 07e5d000 r8 : 86f5af30
r7 : 86f5f750 r6 : 86f5f804 r5 : 86f5f708 r4 : 86f5f750
r3 : r2 : r1 : 87fa4d08 r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
---
drivers/net/cpsw.c | 26 +-
1 Datei geändert, 25 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 9bab71a..186665b 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -561,6 +561,9 @@ static inline void setbit_and_wait_for_clear32(void *addr)
static void cpsw_set_slave_mac(struct cpsw_slave *slave,
struct cpsw_priv *priv)
{
+ if (!priv)
+ return;
+
__raw_writel(mac_hi(priv-dev-enetaddr), slave-regs-sa_hi);
__raw_writel(mac_lo(priv-dev-enetaddr), slave-regs-sa_lo);
}
@@ -568,9 +571,17 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
static void cpsw_slave_update_link(struct cpsw_slave *slave,
struct cpsw_priv *priv, int *link)
{
- struct phy_device *phy = priv-phydev;
+ struct phy_device *phy;
u32 mac_control = 0;
+ if (!priv)
+ return;
+
+ phy = priv-phydev;
+
+ if (!phy)
+ return;
+
phy_startup(phy);
*link = phy-link;
@@ -604,8 +615,12 @@ static int cpsw_update_link(struct cpsw_priv *priv)
int link = 0;
struct cpsw_slave *slave;
+ if (!priv)
+ return -1;
+
for_each_slave(slave, priv)
cpsw_slave_update_link(slave, priv, link);
+
priv-mdio_link = readl(mdio_regs-link);
return link;
}
@@ -614,6 +629,9 @@ static int cpsw_check_link(struct cpsw_priv *priv)
{
u32 link = 0;
All the above *priv* check can be remove as priv is already validated in
this function and all the above functions are called only from this
function.
+ if (!priv)
+ return -1;
+
link = __raw_readl(mdio_regs-link) priv-phy_mask;
if ((link) (link == priv-mdio_link))
return 1;
@@ -623,6 +641,9 @@ static int cpsw_check_link(struct cpsw_priv *priv)
static inline u32 cpsw_get_slave_port(struct cpsw_priv *priv, u32 slave_num)
{
+ if (!priv)
+ return -1;
+
if (priv-host_port == 0)
return slave_num + 1;
else
@@ -947,6 +968,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct
cpsw_slave *slave)
dev,
slave-data-phy_if);
+ if (!phydev)
+ return -1;
+
phydev-supported = supported;
phydev-advertising = phydev-supported;
I don't think you need to validate *priv* as it is already validated in
driver register (cpsw_register()). In any case priv is NULL, then there
is some corruption in dev structure as without priv, dev should not
exist and stack is not supposed to call any cpsw apis.
Regards
Mugunthan V N
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND write error with HW ECC on OMAP3
Dear Ash Charles,
On 09/04/2013 08:00 PM, Ash Charles wrote:
On Wed, Sep 4, 2013 at 1:54 AM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
I can't confirm your complaints. Here it works (at least on tricorder,
which utilizes BCH for U-Boot section in SPL):
Hi Andreas,
Thanks for your response---this was very helpful. When I boot my
board using the tricorder board file, it flashes nand correctly.
Likewise, I moved over some of the NAND configuration from
include/configs/tricorder.h to include/configs/omap3_overo.h and,
after a little rearranging to enlarge SPL, it also flashed NAND
correctly.
So...any guesses what it is about setting these variables that gets
NAND flashing to work properly?
+#define CONFIG_NAND_OMAP_BCH8
+#define CONFIG_BCH
-#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9,\
- 10, 11, 12, 13}
+#define CONFIG_SYS_NAND_ECCPOS {12, 13, 14, 15, 16, 17, 18, 19, 20, \
+21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,\
+34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,\
+47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,\
+60, 61, 62, 63}
-#define CONFIG_SYS_NAND_ECCBYTES 3
+#define CONFIG_SYS_NAND_ECCBYTES 13
these settings are for BCH8! The original settings you replaced are for
so called 'SW hamming' (1 bit ecc with special OOB layout for omap3,
differs from 1 bit ecc mapping used by the omap3 HW calculation in ROM
code).
If you need higher ECC schemes for your NAND, you should update your
setup (u-boot + SPL _and_ linux) to use some BCH codec. BCH4 calculation
seems buggy on some omap3, therefore I used BCH8 here.
Obviously is it a required step, since even SLC need 4 bit ecc nowadays,
some allow just 1 bit for the first sector if only a few erasures occur.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND write error with HW ECC on OMAP3
Dear Ash Charles, On 09/05/2013 01:02 AM, Ash Charles wrote: Hi, I did a little bit more work with git bisect and found an issue on commit c788ecfdc3eb577757ffc1bfb8416added07ef33 nand: Move the sub-page read support enable to a flag. Making this change on top of v2013.07 allowed me to again write to NAND correctly. -#define NAND_HAS_SUBPAGE_READ(chip) ((chip-options NAND_SUBPAGE_READ)) +#define NAND_HAS_SUBPAGE_READ(chip) ((chip-ecc.mode == NAND_ECC_SOFT) \ +(chip-page_shift 9)) this check moved into nand_scan_tail() which is also handled when calling nandecc from u-boot cmdline, on first sight your change isn't not necessary. Can you please check if the chip-options is modified somewhere between the nand_scan_tail() and the place where the NAND_SUBPAGE_READ flag is checked? Like some other OMAP3 platforms, my platform uses 1-bit hardware ECC for the first NAND partition and software ECC elsewhere. Does this ecc.mode switch need to be partition specific? This can not be partition specific by design. The ecc scheme is bound to an NAND device and therefore we introduced the nandecc command for omap3 (cause ROM code can only handle 1 bit hamming, but today's devices require sometimes more than 1 bit ecc). Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
Hi everyone, I changed CONFIG_SPL_TEXT_BASE from 0x40300300 to 0x40300350 and sufddenly it works. Do you know why this configuration works, even though with this configuration there are 0x50 bytes less? It even works with a MLO with 47519 bytes. Here the summary of my config: /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_TEXT_BASE0x40300350 #define CONFIG_SPL_MAX_SIZE (46 * 1024) #define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK Thanks again for the support! -b Am 04.09.2013 11:07, schrieb Sricharan R: On Wednesday 04 September 2013 02:34 PM, bin4ry wrote: Am 04.09.2013 10:56, schrieb Sricharan R: On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote: Hi On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote: On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? if it is Pandaboard? No he has not. I have increased up to 40Kb and it works with serial boot and sdcard/emmc boot. Sorry i missed to read PANDA. So it is anyways GP. and you changed the CONFIG_SPL_TEXT_BASE as well right ? Regards, Sricharan First off, sorry for double-posting to this list. No, the PandaBoard is no HS but a GP device. This is my configuration: /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_TEXT_BASE0x40303000 #define CONFIG_SPL_MAX_SIZE(45 * 1024) #define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK The MLO binary has 46094 Bytes. Actually I should have enough space (from 0x4030 - 0x4030bfff - ~49 kB). However, the device does not start. Right now I am reviewing the code to check, whether it is because of the code and not because of the size that makes u-boot does not start. Can you try by setting CONFIG_SPL_TEXT_BASE 0x40300350 ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Minkyu, On Fri, 30 Aug 2013 14:10:19 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit 9ed887caecb9ecb0c68773a1870d143b9f28d3da: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-08-17 18:24:13 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to 812d7576cdbecc12d7eec7b53d3a4a06234b: drivers:power:max77686: add function to set voltage and mode (2013-08-30 12:24:54 +0900) Chander Kashyap (2): CONFIG: EXYNOS5: Replace misnomer SMDK5250 with EXYNOS5250 and update Makefiles exynos5250: Add arndale board support Inderpal Singh (1): exynos5250: arndale: Add mmc support Minkyu Kang (2): arm: smdkc100: remove config.mk file arm: goni: remove config.mk file Piotr Wilczek (2): arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 drivers:power:max77686: add function to set voltage and mode MAINTAINERS |4 + Makefile |2 +- arch/arm/include/asm/arch-exynos/gpio.h | 17 +- board/samsung/arndale/Makefile | 34 board/samsung/arndale/arndale.c | 101 board/samsung/arndale/arndale_spl.c | 50 ++ board/samsung/dts/exynos5250-arndale.dts | 39 + board/samsung/goni/config.mk | 18 --- board/samsung/smdkc100/config.mk | 16 -- boards.cfg |1 + drivers/power/pmic/pmic_max77686.c | 192 ++ include/configs/arndale.h| 255 ++ include/configs/exynos5250-dt.h |2 +- include/configs/s5p_goni.h |3 + include/configs/smdkc100.h |3 + include/power/max77686_pmic.h| 26 +++ tools/Makefile |4 +- 17 files changed, 725 insertions(+), 42 deletions(-) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/dts/exynos5250-arndale.dts delete mode 100644 board/samsung/goni/config.mk delete mode 100644 board/samsung/smdkc100/config.mk create mode 100644 include/configs/arndale.h Fails for arndale: Error: /home/albert/src/u-boot-arm/board/samsung/dts/exynos5250-arndale.dts:11.2-9 syntax error My dtc -v: Version: DTC 1.4.0, built from source. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] net, phy, cpsw: fix NULL pointer deference
Hello Mugunthan,
Am 05.09.2013 10:27, schrieb Mugunthan V N:
On Thursday 05 September 2013 11:35 AM, Heiko Schocher wrote:
if phy_connect() did not find a phy, phydev is NULL and
following code in cpsw_phy_init() crashes. Fix this.
Signed-off-by: Heiko Schocherh...@denx.de
Cc: Joe Hershbergerjoe.hershber...@gmail.com
Cc: Mugunthan V Nmugunthan...@ti.com
Cc: Tom Rinitr...@ti.com
---
[...]
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 9bab71a..186665b 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -561,6 +561,9 @@ static inline void setbit_and_wait_for_clear32(void *addr)
static void cpsw_set_slave_mac(struct cpsw_slave *slave,
struct cpsw_priv *priv)
{
+ if (!priv)
+ return;
+
__raw_writel(mac_hi(priv-dev-enetaddr),slave-regs-sa_hi);
__raw_writel(mac_lo(priv-dev-enetaddr),slave-regs-sa_lo);
}
@@ -568,9 +571,17 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
static void cpsw_slave_update_link(struct cpsw_slave *slave,
struct cpsw_priv *priv, int *link)
{
- struct phy_device *phy = priv-phydev;
+ struct phy_device *phy;
u32 mac_control = 0;
+ if (!priv)
+ return;
+
+ phy = priv-phydev;
+
+ if (!phy)
+ return;
+
phy_startup(phy);
*link = phy-link;
@@ -604,8 +615,12 @@ static int cpsw_update_link(struct cpsw_priv *priv)
int link = 0;
struct cpsw_slave *slave;
+ if (!priv)
+ return -1;
+
for_each_slave(slave, priv)
cpsw_slave_update_link(slave, priv,link);
+
priv-mdio_link = readl(mdio_regs-link);
return link;
}
@@ -614,6 +629,9 @@ static int cpsw_check_link(struct cpsw_priv *priv)
{
u32 link = 0;
All the above *priv* check can be remove as priv is already validated in
this function and all the above functions are called only from this
function.
No, cpsw_update_link() is called for example directly from cpsw_init()
cpsw_set_slave_mac() from cpsw_slave_init()
+ if (!priv)
+ return -1;
+
link = __raw_readl(mdio_regs-link) priv-phy_mask;
if ((link) (link == priv-mdio_link))
return 1;
@@ -623,6 +641,9 @@ static int cpsw_check_link(struct cpsw_priv *priv)
static inline u32 cpsw_get_slave_port(struct cpsw_priv *priv, u32 slave_num)
{
+ if (!priv)
+ return -1;
+
if (priv-host_port == 0)
return slave_num + 1;
else
@@ -947,6 +968,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct
cpsw_slave *slave)
dev,
slave-data-phy_if);
+ if (!phydev)
+ return -1;
+
phydev-supported= supported;
phydev-advertising = phydev-supported;
I don't think you need to validate *priv* as it is already validated in
driver register (cpsw_register()). In any case priv is NULL, then there
is some corruption in dev structure as without priv, dev should not
exist and stack is not supposed to call any cpsw apis.
Yes, you are right. Checked it on the dxr2 board. We do not need
the priv check ... Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Albert, On 5 September 2013 14:43, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Minkyu, On Fri, 30 Aug 2013 14:10:19 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit 9ed887caecb9ecb0c68773a1870d143b9f28d3da: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-08-17 18:24:13 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to 812d7576cdbecc12d7eec7b53d3a4a06234b: drivers:power:max77686: add function to set voltage and mode (2013-08-30 12:24:54 +0900) Chander Kashyap (2): CONFIG: EXYNOS5: Replace misnomer SMDK5250 with EXYNOS5250 and update Makefiles exynos5250: Add arndale board support Inderpal Singh (1): exynos5250: arndale: Add mmc support Minkyu Kang (2): arm: smdkc100: remove config.mk file arm: goni: remove config.mk file Piotr Wilczek (2): arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 drivers:power:max77686: add function to set voltage and mode MAINTAINERS |4 + Makefile |2 +- arch/arm/include/asm/arch-exynos/gpio.h | 17 +- board/samsung/arndale/Makefile | 34 board/samsung/arndale/arndale.c | 101 board/samsung/arndale/arndale_spl.c | 50 ++ board/samsung/dts/exynos5250-arndale.dts | 39 + board/samsung/goni/config.mk | 18 --- board/samsung/smdkc100/config.mk | 16 -- boards.cfg |1 + drivers/power/pmic/pmic_max77686.c | 192 ++ include/configs/arndale.h| 255 ++ include/configs/exynos5250-dt.h |2 +- include/configs/s5p_goni.h |3 + include/configs/smdkc100.h |3 + include/power/max77686_pmic.h| 26 +++ tools/Makefile |4 +- 17 files changed, 725 insertions(+), 42 deletions(-) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/dts/exynos5250-arndale.dts delete mode 100644 board/samsung/goni/config.mk delete mode 100644 board/samsung/smdkc100/config.mk create mode 100644 include/configs/arndale.h Fails for arndale: Error: /home/albert/src/u-boot-arm/board/samsung/dts/exynos5250-arndale.dts:11.2-9 syntax error My dtc -v: Version: DTC 1.4.0, built from source. Its working for me. But my dtc -v: Version: DTC 1.3.0 Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] net, phy, cpsw: fix NULL pointer deference
if phy_connect() did not find a phy, phydev is NULL and
following code in cpsw_phy_init() crashes. Fix this.
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Joe Hershberger joe.hershber...@gmail.com
Cc: Mugunthan V N mugunthan...@ti.com
Cc: Tom Rini tr...@ti.com
---
- changes for v2:
- change commit message as it is a NULL pointer deference error
not a unaligned access problem, as Tom Rini mentioned
- fix more places in the driver with NULL pointer problem
- changes for v3:
- add comment from Mugunthan V N:
- priv NULL pointer checks not needed
Found on the dxr2 board with no phy connected to the board,
U-Boot crashes with:
U-Boot 2013.07-12701-gea98378-dirty (Sep 04 2013 - 06:58:16)
I2C: ready
DRAM: 128 MiB
Enable d-cache
FactorySet is not right in eeprom.
NAND: 256 MiB
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
8-bit BCH HW ECC selected
Net: Could not get PHY for cpsw: addr 0
data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [87f80574] lr : [87f80fcc]
sp : 86f5aee0 ip : 0034 fp : 80100020
r10: 0014 r9 : 07e5d000 r8 : 86f5af30
r7 : 86f5f750 r6 : 86f5f804 r5 : 86f5f708 r4 : 86f5f750
r3 : r2 : r1 : 87fa4d08 r0 :
Flags: nZCv IRQs off FIQs on Mode SVC_32
Resetting CPU ...
---
drivers/net/cpsw.c | 10 +-
1 Datei geändert, 9 Zeilen hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 9bab71a..39240d9 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -568,9 +568,14 @@ static void cpsw_set_slave_mac(struct cpsw_slave *slave,
static void cpsw_slave_update_link(struct cpsw_slave *slave,
struct cpsw_priv *priv, int *link)
{
- struct phy_device *phy = priv-phydev;
+ struct phy_device *phy;
u32 mac_control = 0;
+ phy = priv-phydev;
+
+ if (!phy)
+ return;
+
phy_startup(phy);
*link = phy-link;
@@ -947,6 +952,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct
cpsw_slave *slave)
dev,
slave-data-phy_if);
+ if (!phydev)
+ return -1;
+
phydev-supported = supported;
phydev-advertising = phydev-supported;
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
On 5 September 2013 15:12, Chander Kashyap chander.kash...@linaro.org wrote: Hi Albert, On 5 September 2013 14:43, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Minkyu, On Fri, 30 Aug 2013 14:10:19 +0900, Minkyu Kang mk7.k...@samsung.com wrote: Dear Albert, The following changes since commit 9ed887caecb9ecb0c68773a1870d143b9f28d3da: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-08-17 18:24:13 +0200) are available in the git repository at: git://git.denx.de/u-boot-samsung master for you to fetch changes up to 812d7576cdbecc12d7eec7b53d3a4a06234b: drivers:power:max77686: add function to set voltage and mode (2013-08-30 12:24:54 +0900) Chander Kashyap (2): CONFIG: EXYNOS5: Replace misnomer SMDK5250 with EXYNOS5250 and update Makefiles exynos5250: Add arndale board support Inderpal Singh (1): exynos5250: arndale: Add mmc support Minkyu Kang (2): arm: smdkc100: remove config.mk file arm: goni: remove config.mk file Piotr Wilczek (2): arm:exynos:gpio: fix s5p_gpio_part_max for exynos4x12 drivers:power:max77686: add function to set voltage and mode MAINTAINERS |4 + Makefile |2 +- arch/arm/include/asm/arch-exynos/gpio.h | 17 +- board/samsung/arndale/Makefile | 34 board/samsung/arndale/arndale.c | 101 board/samsung/arndale/arndale_spl.c | 50 ++ board/samsung/dts/exynos5250-arndale.dts | 39 + board/samsung/goni/config.mk | 18 --- board/samsung/smdkc100/config.mk | 16 -- boards.cfg |1 + drivers/power/pmic/pmic_max77686.c | 192 ++ include/configs/arndale.h| 255 ++ include/configs/exynos5250-dt.h |2 +- include/configs/s5p_goni.h |3 + include/configs/smdkc100.h |3 + include/power/max77686_pmic.h| 26 +++ tools/Makefile |4 +- 17 files changed, 725 insertions(+), 42 deletions(-) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/dts/exynos5250-arndale.dts delete mode 100644 board/samsung/goni/config.mk delete mode 100644 board/samsung/smdkc100/config.mk create mode 100644 include/configs/arndale.h Fails for arndale: Error: /home/albert/src/u-boot-arm/board/samsung/dts/exynos5250-arndale.dts:11.2-9 syntax error My dtc -v: Version: DTC 1.4.0, built from source. Its working for me. But my dtc -v: Version: DTC 1.3.0 Tested now with dtc -v: Version: DTC 1.4.0 It got compiled. properly. Or I missed something. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- with warm regards, Chander Kashyap -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] : Please pull u-boot-imx
Hi Stefano, On Tue, 03 Sep 2013 10:20:44 +0200, Stefano Babic sba...@denx.de wrote: Hi Albert, please pull from u-boot-imx, thanks ! The following changes since commit 326ea986ac150acdc7656d57fca647db80b50158: Merge git://git.denx.de/u-boot-arm (2013-07-31 11:30:38 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to 8467faef7fce8c5faad7224b7737a58e16c52186: i.MX6: Set and clear the gating bits for Phase Fractional Dividers (2013-08-31 18:09:37 +0200) Amaury Pouly (1): mmc: mxsmmc: Enable MMC HC support Andreas Wass (2): ARM: mxs: Added application UART driver ARM: mxs: Add mx28evk_auart_console target Eric Nelson (6): i.MX6: nitrogen6x: force HDMI onto IPU0/DI0 fec_mxc: set ethaddr if fuses burned and not previously set i.MX6: Add convenience macros cpu_type(rev) and is_cpu_type(cpu) i.MX6: Correct ANATOP_PFD (Phase Fractional Divider) register declarations i.MX6: nitrogen6x: Don't bother setting PLL3(480) PFD1 divisor i.MX6: Set and clear the gating bits for Phase Fractional Dividers Hector Palacios (1): ARM: mxs: rename function that sets AUTO_RESTART flag Marek Vasut (3): ARM: mxs: tools: Add mkimage support for MXS bootstream tools: Sort lists of files in Makefile tools: mxsboot: Staticize functions SARTRE Leo (1): ARM: Congatec: README update Stefano Babic (7): tools: imx_header should not include flash_offset tools: rename mximage_flash_offset to imximage_ivt_offset tools: dynamically allocate imx_header in imximage tools: add variable padding of data image in mkimage tools: add padding of data image file for imximage tools: add support for setting the CSF into imximage imx: add status reporting for HAB status arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg |6 + arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg |8 + arch/arm/cpu/arm926ejs/mxs/spl_power_init.c |9 +- arch/arm/cpu/armv7/mx6/Makefile |7 +- arch/arm/cpu/armv7/mx6/hab.c | 104 ++ arch/arm/cpu/armv7/mx6/soc.c | 28 + arch/arm/include/asm/arch-mx6/hab.h | 67 + arch/arm/include/asm/arch-mx6/imx-regs.h | 37 +- arch/arm/include/asm/arch-mx6/sys_proto.h|7 + arch/arm/include/asm/arch-mxs/regs-uartapp.h | 220 +++ board/boundary/nitrogen6x/nitrogen6x.c |8 +- board/congatec/cgtqmx6eval/README|3 +- boards.cfg |1 + common/image.c |1 + config.mk|9 + doc/README.imximage | 30 +- doc/README.mxc_hab | 48 + doc/README.mxsimage | 165 ++ drivers/mmc/mxsmmc.c |3 +- drivers/net/fec_mxc.c|2 + drivers/serial/Makefile |1 + drivers/serial/mxs_auart.c | 151 ++ drivers/serial/serial.c |2 + include/configs/mxs.h|7 +- include/image.h |1 + tools/Makefile | 42 +- tools/imximage.c | 180 +- tools/imximage.h | 20 +- tools/mkimage.c | 26 +- tools/mkimage.h |6 +- tools/mxsboot.c | 12 +- tools/mxsimage.c | 2347 ++ tools/mxsimage.h | 230 +++ 33 files changed, 3691 insertions(+), 97 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg create mode 100644 arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg create mode 100644 arch/arm/cpu/armv7/mx6/hab.c create mode 100644 arch/arm/include/asm/arch-mx6/hab.h create mode 100644 arch/arm/include/asm/arch-mxs/regs-uartapp.h create mode 100644 doc/README.mxc_hab create mode 100644 doc/README.mxsimage create mode 100644 drivers/serial/mxs_auart.c create mode 100644 tools/mxsimage.c create mode 100644 tools/mxsimage.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net, phy, cpsw: fix NULL pointer deference
On Thursday 05 September 2013 03:20 PM, Heiko Schocher wrote: if phy_connect() did not find a phy, phydev is NULL and following code in cpsw_phy_init() crashes. Fix this. Signed-off-by: Heiko Schocher h...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Mugunthan V N mugunthan...@ti.com Cc: Tom Rini tr...@ti.com Acked-by: Mugunthan V N mugunthan...@ti.com Regards Mugunthan V N ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot 2009.11.1 USB Issue and Building U-Boot 2013.07
Dear Chuck Wical, On 09/03/2013 10:53 PM, Chuck Wical wrote: First I am fairly new to U-Boot but over the last 2 weeks I have been going through the README files and anything else I can find that would help resolve the issue I have. Here is a recap: Currently the project I am working on was setup with U-Boot 2009-11-01 and works just fine with one exception. I was asked to find a solution where our field support engineers could recover if a firmware update failed causing our board to no longer boot. Basically it cycles through RomBOOT and U-Boot. As I looked through the environment variables and commands I came across the USB subsystem and found I could use fatload. With our system there are three files I need to load from USB, these are uImage, etc.jff2 and rootfs.ext2.gz.uboot. you could also use fatload on mmc. Do you have some mmc in your device? I found if I used tftp these files transferred correctly and the board would boot with the new files. I thought the solution was found and I could simply setup the same files using USB through environment variables. The script worked but the problem was when it tried to load rootfs into RAM it would cause a CPU reset and RomBOOT to start. At first I thought there was something wrong with the script so I tried to load the file by typing it the command but got the same result. I tested the 2009.11.1 release on my 9263ek here and can confirm, that the usb support there is really buggy. It doesn't support current storage devices, seems to behave differently every time I access the device (timeouts, ...). I managed however to load a 16MiB file via usb storage successfully. Command: usb start fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot where loadaddr is the same address used by tftp. That's in general correct. My first question is, is there a solution for this issue using U-Boot 2009.11.1? This version builds currently within our project. As these are my first steps with 2009.11.1 and usb storage I can't say it. You could backport current usb stack to have better support. On the other hand porting your board forward isn't that hard. Second question is I downloaded U-Boot 2013.07 but noticed huge change in the build process. I figured out the patches I need along with the AT91 configuration for our board. We are using the arm926ej6 processor with a board similar to at91sam9260ek. When I try to build I get the hardware.h:49:3 error: #error Unsupported AT91 processor message. When I HAve a look at 9260ek config, it is still in current releases and builds at least. I rarely test the built on real hardware, at the moment I only have an sam9263ek handy. look at the header file I see where it fails but I don't understand why since I do have a matching define. For some reason hardware.h is not seeing this define and I am stumped as to why. So any suggestions on how to solve or figure this out would be appreciated. If you plan to integrate your patches into mainline, we could help to adopt them where needed. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Hi Andreas, On Wed, 4 Sep 2013 17:15:51 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Albert Aribaud, please pull these two fixes into u-boot-arm/master for 2013.10 release. The following changes since commit 4eef93da262048eb1118e726b3ec5b8ebd3c6c91: Merge branch 'u-boot-atmel/master' into 'u-boot-arm/master' (2013-09-04 11:50:25 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 27871e6b519ccd933bd91c879241995c272fef3b: ARM: atmel: sama5d3: drop unused CONFIG_NET_MULTI (2013-09-04 17:07:30 +0200) Bo Shen (1): ARM: atmel: sama5d3: drop unused CONFIG_NET_MULTI Wu, Josh (1): mtd: atmel_nand: pmecc: fix bug fail to correct bit error in 1024-bytes sector drivers/mtd/nand/atmel_nand.c |3 ++- include/configs/sama5d3xek.h |1 - 2 files changed, 2 insertions(+), 2 deletions(-) Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Chander, Its working for me. But my dtc -v: Version: DTC 1.3.0 Have you managed to properly build test Samsung's u-boot tree with DTC 1.3.0? On my setup (debian - 1.3.0-4) it fails. Tested now with dtc -v: Version: DTC 1.4.0 It got compiled. properly. Or I missed something. The Exynos5x boards with DT support shall be compiled with DTC version 1.4+. Otherwise they fail: Configuring for snow board... make: *** [checkdtc] Error 1 make: *** [checkdtc] Error 1 make: *** Waiting for unfinished jobs Configuring for smdk5250 board... make: *** [checkdtc] Error 1 make: *** [checkdtc] Error 1 make: *** Waiting for unfinished jobs -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Albert/Tom -- could we get patch applied or some feedback (was Re: [PATCH v6 1/1] socfpga: Adding configuration for development kit)
Hi! Wonder any updates on this? We plan to send the new patches only once these existing patches are accepted. Appreciate for your helps again. Albert seems to be back, perhaps he'll us how he wants us to proceed? Thanks, Pavel Albert, Tom this patch has been here for a week, without any comments. As far as I can tell, it is pretty much perfect. Can we get any comments on it, or (better), get it applied? Another week passed, and nothing happens. Is there just slow holiday time, or are we doing something wrong? If you excuse one extra newline at end of file, [PATCH v6 1/1] socfpga: Creating driver for Reset Manager is in good shape too, and applying it would be nice. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Lukasz, On 5 September 2013 16:27, Lukasz Majewski l.majew...@samsung.com wrote: Hi Chander, Its working for me. But my dtc -v: Version: DTC 1.3.0 Have you managed to properly build test Samsung's u-boot tree with DTC 1.3.0? Yes, I am able to build and test. I am running on ubuntu. On my setup (debian - 1.3.0-4) it fails. Tested now with dtc -v: Version: DTC 1.4.0 It got compiled. properly. Or I missed something. The Exynos5x boards with DT support shall be compiled with DTC version 1.4+. Otherwise they fail: Configuring for snow board... make: *** [checkdtc] Error 1 make: *** [checkdtc] Error 1 make: *** Waiting for unfinished jobs Configuring for smdk5250 board... make: *** [checkdtc] Error 1 make: *** [checkdtc] Error 1 make: *** Waiting for unfinished jobs -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC, am335x_evm.h patch for u-boot on SD and rest on eMMC on BBB
i'm still interested on thoughts on this proposed patch: On Wed, 4 Sep 2013, Robert P. J. Day wrote: soldiering on with my configuring and building u-boot for my BBB, i have a proposal for include/configs/am335x_evm.h: #define CONFIG_BOOTCOMMAND \ run findfdt; \ run mmcboot; \ setenv mmcdev 1; \ setenv bootpart 1:2; \ setenv mmcroot /dev/mmcblk1p2 ro; \-- add this line run mmcboot; \ run nandboot; to recap, the idea is that if the first run mmcboot fails and both mmcdev and bootpart are reassigned to refer to mmc device 1, it only makes sense to adjust mmcroot to refer to the same device from which to get the root filesystem. naturally, that can be done from within uEnv.txt, but it seems to make sense that that should be the default. to be a bit more verbose, i'm setting up a classroom exercise where students will have a fully installed and bootable BBB, but they'll get an exercise to download, configure and install u-boot (MLO and u-boot.img) on an SD card where that's *all* that will be on the SD card, so the BBB will run u-boot off of the SD card, but will automatically switch to eMMC for the kernel image and root filesystem when it tries to boot. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Chander, On Thu, 5 Sep 2013 16:47:27 +0530, Chander Kashyap chander.kash...@linaro.org wrote: Hi Lukasz, On 5 September 2013 16:27, Lukasz Majewski l.majew...@samsung.com wrote: Hi Chander, Its working for me. But my dtc -v: Version: DTC 1.3.0 Have you managed to properly build test Samsung's u-boot tree with DTC 1.3.0? Yes, I am able to build and test. I am running on ubuntu. Then you are not testing on a recent enough U-Boot source tree; currently, master (and arm) require dtc version = 1.4.0, and will fail as indicated by Lukasz and as experienced by me -- I had to build dtc version 1.4.0 from git source. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Albert/Tom -- could we get patch applied or some feedback (was Re: [PATCH v6 1/1] socfpga: Adding configuration for development kit)
Hi Pavel, On Thu, 2013-09-05 at 13:10 +0200, ZY - pavel wrote: Hi! Wonder any updates on this? We plan to send the new patches only once these existing patches are accepted. Appreciate for your helps again. Albert seems to be back, perhaps he'll us how he wants us to proceed? Yup, I saw his posting again. Hope we can hear from Albert soon on these patches. Thanks Chin Liang Thanks, Pavel Albert, Tom this patch has been here for a week, without any comments. As far as I can tell, it is pretty much perfect. Can we get any comments on it, or (better), get it applied? Another week passed, and nothing happens. Is there just slow holiday time, or are we doing something wrong? If you excuse one extra newline at end of file, [PATCH v6 1/1] socfpga: Creating driver for Reset Manager is in good shape too, and applying it would be nice. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Albert, On 5 September 2013 17:08, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Chander, On Thu, 5 Sep 2013 16:47:27 +0530, Chander Kashyap chander.kash...@linaro.org wrote: Hi Lukasz, On 5 September 2013 16:27, Lukasz Majewski l.majew...@samsung.com wrote: Hi Chander, Its working for me. But my dtc -v: Version: DTC 1.3.0 Have you managed to properly build test Samsung's u-boot tree with DTC 1.3.0? Yes, I am able to build and test. I am running on ubuntu. Then you are not testing on a recent enough U-Boot source tree; currently, master (and arm) require dtc version = 1.4.0, and will fail as indicated by Lukasz and as experienced by me -- I had to build dtc version 1.4.0 from git source. Sorry for big mess. I had re-based my tree to u-boot samsung. I have tested it after re-basing to u-boot tree. It was failing. Shall i send all the patches again, or is it possible to send the single failing patch. Amicalement, -- Albert. -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 1/2] exynos5250: Add arndale board support
Arndale board is based on samsung's exynos5250 soc.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
MAINTAINERS |4 +
board/samsung/arndale/Makefile | 34
board/samsung/arndale/arndale.c | 87 ++
board/samsung/arndale/arndale_spl.c | 50 ++
board/samsung/dts/exynos5250-arndale.dts | 21 +++
boards.cfg |1 +
include/configs/arndale.h| 255 ++
7 files changed, 452 insertions(+)
create mode 100644 board/samsung/arndale/Makefile
create mode 100644 board/samsung/arndale/arndale.c
create mode 100644 board/samsung/arndale/arndale_spl.c
create mode 100644 board/samsung/dts/exynos5250-arndale.dts
create mode 100644 include/configs/arndale.h
diff --git a/MAINTAINERS b/MAINTAINERS
index bd0f3a0..9c53ca4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -464,6 +464,10 @@ Andre Schwarz andre.schw...@matrix-vision.de
mvblm7 MPC8343
mvsmr MPC5200
+Inderpal Singh inderpal.si...@linaro.org
+
+ Arndale ARM ARMV7 (EXYNOS5250 SoC)
+
Jon Smirl jonsm...@gmail.com
pcm030 MPC5200
diff --git a/board/samsung/arndale/Makefile b/board/samsung/arndale/Makefile
new file mode 100644
index 000..afd8db3
--- /dev/null
+++ b/board/samsung/arndale/Makefile
@@ -0,0 +1,34 @@
+#
+# Copyright (C) 2013 Samsung Electronics
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS += arndale_spl.o
+
+ifndef CONFIG_SPL_BUILD
+COBJS += arndale.o
+endif
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+ALL:= $(obj).depend $(LIB)
+
+all: $(ALL)
+
+$(LIB):$(OBJS)
+ $(call cmd_link_o_target, $(OBJS))
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/arndale/arndale.c b/board/samsung/arndale/arndale.c
new file mode 100644
index 000..84d8f19
--- /dev/null
+++ b/board/samsung/arndale/arndale.c
@@ -0,0 +1,87 @@
+/*
+ * Copyright (C) 2013 Samsung Electronics
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/pinmux.h
+#include asm/arch/power.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ gd-bd-bi_boot_params = (PHYS_SDRAM_1 + 0x100UL);
+ return 0;
+}
+
+int dram_init(void)
+{
+ int i;
+ u32 addr;
+
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ addr = CONFIG_SYS_SDRAM_BASE + (i * SDRAM_BANK_SIZE);
+ gd-ram_size += get_ram_size((long *)addr, SDRAM_BANK_SIZE);
+ }
+ return 0;
+}
+
+int power_init_board(void)
+{
+ set_ps_hold_ctrl();
+ return 0;
+}
+
+void dram_init_banksize(void)
+{
+ int i;
+ u32 addr, size;
+
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ addr = CONFIG_SYS_SDRAM_BASE + (i * SDRAM_BANK_SIZE);
+ size = get_ram_size((long *)addr, SDRAM_BANK_SIZE);
+
+ gd-bd-bi_dram[i].start = addr;
+ gd-bd-bi_dram[i].size = size;
+ }
+}
+
+static int board_uart_init(void)
+{
+ int err = 0, uart_id;
+
+ for (uart_id = PERIPH_ID_UART0; uart_id = PERIPH_ID_UART3; uart_id++) {
+ err = exynos_pinmux_config(uart_id, PINMUX_FLAG_NONE);
+ if (err) {
+ debug(UART%d not configured\n,
+ (uart_id - PERIPH_ID_UART0));
+ return err;
+ }
+ }
+ return err;
+}
+
+#ifdef CONFIG_BOARD_EARLY_INIT_F
+int board_early_init_f(void)
+{
+ int err;
+
+ err = board_uart_init();
+ if (err) {
+ debug(UART init failed\n);
+ return err;
+ }
+ return err;
+}
+#endif
+
+#ifdef CONFIG_DISPLAY_BOARDINFO
+int checkboard(void)
+{
+ printf(\nBoard: Arndale\n);
+
+ return 0;
+}
+#endif
diff --git a/board/samsung/arndale/arndale_spl.c
b/board/samsung/arndale/arndale_spl.c
new file mode 100644
index 000..2949c08
--- /dev/null
+++ b/board/samsung/arndale/arndale_spl.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include asm/arch/spl.h
+
+#define SIGNATURE 0xdeadbeef
+
+/* Parameters of early board initialization in SPL */
+static struct spl_machine_param machine_param
+ __attribute__((section(.machine_param))) = {
+ .signature = SIGNATURE,
+ .version= 1,
+ .params = vmubfasirM,
+ .size = sizeof(machine_param),
+
+ .mem_iv_size= 0x1f,
+ .mem_type
[U-Boot] [PATCH v8 0/2] Add Arndale board support
The Arndale board is based on samsung's exynos5250 SOC. For spl generation, it depends on the patch at [5]. First patch provides the basic arndale board support. The second patch adds the MMC support. Changes in v2: - split from earlier patchset at [3] as per Minkyu - Removed checkpatch errors pointed out by Wolfgang - rebased to latest u-boot-samsung master branch - created mmc_boot.c to remove dependency on consolidation patch at [4] - split the mmc support to new patch as it depends on [2] [1] http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/162883 [2] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/159887 [3] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/157101 [4] http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/156272 Changes in v3: - Used dt based serial - rebased to latest u-boot-samsung master branch Changes in v4: - Removed the config dependency on exynos5_dt.h as it contains smdk5250 configurations rather than the common exynos5 generic configurations. - rebased to latest u-boot-samsung master branch Changes in v5: - Fix comments suggested by Minkyu - Added SPDX-License-Identifier to new files Changes in v6: - Fixed missed out sorting of Maintainers entry Changes in v7: - Fixed regression caused due to v6. - rebased to latest u-boot-samsung master branch - Fixed checkpatch warning for parenthesis alignment. Changes in v7: - Fixed DT compilation error with DTC 1.4.0 [5] [PATCH v2] CONFIG: EXYNOS5: Replace misnomer SMDK5250 with EXYNOS5250 and update Makefiles Chander Kashyap (1): exynos5250: Add arndale board support Inderpal Singh (1): exynos5250: arndale: Add mmc support MAINTAINERS |4 + board/samsung/arndale/Makefile | 34 board/samsung/arndale/arndale.c | 101 board/samsung/arndale/arndale_spl.c | 50 ++ board/samsung/dts/exynos5250-arndale.dts | 39 + boards.cfg |1 + include/configs/arndale.h| 255 ++ 7 files changed, 484 insertions(+) create mode 100644 board/samsung/arndale/Makefile create mode 100644 board/samsung/arndale/arndale.c create mode 100644 board/samsung/arndale/arndale_spl.c create mode 100644 board/samsung/dts/exynos5250-arndale.dts create mode 100644 include/configs/arndale.h -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8 2/2] exynos5250: arndale: Add mmc support
From: Inderpal Singh inderpal.si...@linaro.org
This patch adds mmc support to the arndale board.
Signed-off-by: Inderpal Singh inderpal.si...@linaro.org
---
board/samsung/arndale/arndale.c | 14 ++
board/samsung/dts/exynos5250-arndale.dts | 18 ++
2 files changed, 32 insertions(+)
diff --git a/board/samsung/arndale/arndale.c b/board/samsung/arndale/arndale.c
index 84d8f19..052fecd 100644
--- a/board/samsung/arndale/arndale.c
+++ b/board/samsung/arndale/arndale.c
@@ -6,6 +6,7 @@
#include common.h
#include asm/arch/pinmux.h
+#include asm/arch/dwmmc.h
#include asm/arch/power.h
DECLARE_GLOBAL_DATA_PTR;
@@ -48,6 +49,19 @@ void dram_init_banksize(void)
}
}
+#ifdef CONFIG_GENERIC_MMC
+int board_mmc_init(bd_t *bis)
+{
+ int ret;
+ /* dwmmc initializattion for available channels */
+ ret = exynos_dwmmc_init(gd-fdt_blob);
+ if (ret)
+ debug(dwmmc init failed\n);
+
+ return ret;
+}
+#endif
+
static int board_uart_init(void)
{
int err = 0, uart_id;
diff --git a/board/samsung/dts/exynos5250-arndale.dts
b/board/samsung/dts/exynos5250-arndale.dts
index ce75314..202f2ea 100644
--- a/board/samsung/dts/exynos5250-arndale.dts
+++ b/board/samsung/dts/exynos5250-arndale.dts
@@ -18,4 +18,22 @@
serial0 = /serial@12C2;
console = /serial@12C2;
};
+
+ mmc@1220 {
+ samsung,bus-width = 8;
+ samsung,timing = 1 3 3;
+ };
+
+ mmc@1221 {
+ status = disabled;
+ };
+
+ mmc@1222 {
+ samsung,bus-width = 4;
+ samsung,timing = 1 2 3;
+ };
+
+ mmc@1223 {
+ status = disabled;
+ };
};
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: change size_t to fix format warning for gcc 4.7.3
I have checked with Altera. This is a toolchain change. We will keep this and follow mostly the types in linux-2.6/include/uapi/asm-generic/posix_types.h . - Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] nios2: change size_t to fix format warning for gcc 4.7.3
On Thu, Sep 05, 2013 at 08:55:09PM +0800, Thomas Chou wrote: I have checked with Altera. This is a toolchain change. We will keep this and follow mostly the types in linux-2.6/include/uapi/asm-generic/posix_types.h . For clarity, this patch should be... Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: lds: Remove libgcc eabi exception handling tables
Hi Michal,
On Thu, 25 Jul 2013 16:16:46 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Remove ARM eabi exception handling tables (for frame unwinding).
AFAICT, u-boot stubs away the frame unwiding routines, so the tables will
more or less just consume space. It should be OK to remove them.
Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
This patch was sent to ML as RFC (May 9)
Here is the origin response in connection to this patch.
Ok, so Michal and I just did some fiddling with zynq builds and
*exidx* sections.
By default the *exidx* sections are between rodata and data, so
removing them causes many apparent changes at the binary level.
However, builds of zynq based on ARM master with the patch above vs
master with a patch mapping *exidx* sections after BSS gives identical
binaries. Thus the RFC has no functional effect.
Also, ARM EHABI states that [exception] Tables are not required for ABI
compliance at the C/Assembler level but are required for C++.
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
So as long as we don't put any C++ code in U-Boot (a prospect that I
don't see happening any time soon), this RFC is safe and either is a
no-op or removes useless bytes from the binary.
---
arch/arm/cpu/u-boot.lds | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 3037885..8894c8a 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -113,4 +113,6 @@ SECTIONS
/DISCARD/ : { *(.plt*) }
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
+ /DISCARD/ : { *(.ARM.exidx*) }
+ /DISCARD/ : { *(.gnu.linkonce.armexidx.*) }
}
--
1.8.2.3
The good news is, it applies and does not cause any build issues.
The less good news is, arch/arm/cpu/u-boot.lds is not the only linker
script file to fix if we want to fix it this way.
The fact is, I am not sure removing sections from the ELF filein order
to avoid them being in the binary is actually the right way to go. I
have recently had to 'un-discard' some sections in order for
'offline' debugging tools to properly understand the ELF file.
So I am wondering if we should not stop using /DISCARD/ and start using
$(CROSS_COMPILE)objcopy options (-j or --strip-* and --remove-section).
This way, the ELF file would be as complete as any debug tool might
expect it (e.g. objdump, especially when debugging relocation issues)
yet the binary file would remain unchanged.
But past rc2 is not a time to start such a change.
Still, I'd like your fix to be consistent across all of ARM. Can you
change all the linker scripts used for build ARM targets? These are,
according to an ugly mix of cat LOG/*.MAKELOG, sed, grep and sort -u:
arch/arm/cpu/arm1136/u-boot-spl.lds
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds
arch/arm/cpu/ixp/u-boot.lds
arch/arm/cpu/u-boot.lds
arch/arm/cpu/u-boot-spl.lds
board/actux1/u-boot.lds
board/actux2/u-boot.lds
board/actux3/u-boot.lds
board/ait/cam_enc_4xx/u-boot-spl.lds
board/davinci/da8xxevm/u-boot-spl-da850evm.lds
board/davinci/da8xxevm/u-boot-spl-hawk.lds
board/dvlhost/u-boot.lds
board/freescale/mx31ads/u-boot.lds
board/samsung/common/exynos-uboot-spl.lds
board/ti/am335x/u-boot.lds
board/vpac270/u-boot-spl.lds
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for Kees Cook's compression fixes
On Tue, Sep 03, 2013 at 04:04:14PM -0600, Simon Glass wrote: Hi Tom, I believe these qualify for the release since they are fixes/tests, but this is up to you. To help with the process I have done a pull request. Also I ran them through buildman (unfortunately I cannot build all archs, but I build most). No new errors/warnings. ./tools/buildman/buildman -b x86-push -s Summary of 8 commits for 1155 boards (32 threads, 1 job per thread) 01: Prepare v2013.10-rc2 blackfin: + bf561-acvilon cm-bf561 blackstamp br4 bct-brettl2 cm-bf527 dnp5370 bf506f-ezkit ip04 bf527-sdp bf609-ezkit bf537-stamp bf527-ezkit-v2 cm-bf537e tcm-bf518 cm-bf537u bf537-pnav cm-bf533 pr1 bf533-ezkit ibf-dsp561 bf537-srv1 cm-bf548 bf537-minotaur bf538f-ezkit bf548-ezkit bf525-ucr2 blackvme bf527-ezkit tcm-bf537 bf533-stamp bf518f-ezbrd bf527-ad7160-eval bf526-ezbrd bf561-ezkit m68k: + M54455EVB_a66 M5329AFEE M5249EVB idmr M5208EVBE M5475FFE M54451EVB astro_mcf5373l M54418TWR_serial_rmii M54455EVB_intel M5282EVB M54455EVB_i66 M5475GFE M5253DEMO M54455EVB_stm33 M5485BFE M5485DFE M5329BFEE M52277EVB M5475EFE M5475CFE cobra5272 M5485AFE M53017EVB M5475AFE M5485HFE M5235EVB M5253EVBE M54418TWR_nand_mii M54418TWR_nand_rmii_lowfreq TASREG M5475BFE M5475DFE M5275EVB M52277EVB_stmicro eb_cpu5282 eb_cpu5282_internal M54451EVB_stmicro M5271EVB M5485GFE M5485EFE M5485FFE M54418TWR M5235EVB_Flash32 M5373EVB M54418TWR_nand_rmii M54418TWR_serial_mii M5485CFE M54455EVB M5272C3 powerpc: + MVBLM7 MVSMR lcd4_lwmon5 sparc: + grsim grsim_leon2 gr_cpci_ax2000 gr_xc3s_1500 gr_ep2s60 sh: + rsk7269 rsk7264 sh7752evb rsk7203 sh7757lcr nios2: + PCI5441 nios2-generic PK1C20 microblaze: + microblaze-generic openrisc: + openrisc-generic arm: + palmtc zipitz2 VCMA9 lubbock zynq_dcc vpac270_nor_128 colibri_pxa270 kzm9g zynq xaeniax palmtreo680 polaris pxa255_idp lp8x4x vpac270_ond_256 vpac270_nor_256 smdk2410 h2200 balloon3 palmld trizepsiv 02: sandbox: Correct compiler warnings in cmd_bootm/cmd_ximg 03: sandbox: add compression tests 04: documentation: add more compression configs 05: gzip: correctly bounds-check output buffer 06: lzma: correctly bounds-check output buffer 07: lzo: correctly bounds-check output buffer 08: bootm: allow correct bounds-check of destination The following changes since commit fb18fa95a14ae875ef0a5421cd9fecc00c7c3a4c: Prepare v2013.10-rc2 (2013-09-02 14:20:36 -0400) are available in the git repository at: ssh://gu-...@git.denx.de/u-boot-x86.git comp for you to fetch changes up to 315c0ace7c220591a9b220ab7698e85624b430c0: bootm: allow correct bounds-check of destination (2013-09-03 13:30:26 -0600) Kees Cook (6): sandbox: add compression tests documentation: add more compression configs gzip: correctly bounds-check output buffer lzma: correctly bounds-check output buffer lzo: correctly bounds-check output buffer bootm: allow correct bounds-check of destination Simon Glass (1): sandbox: Correct compiler warnings in cmd_bootm/cmd_ximg README | 9 +++ common/cmd_bootm.c | 12 +-- common/cmd_ximg.c | 5 +- include/configs/sandbox.h | 5 ++ lib/gunzip.c | 4 +- lib/lzma/LzmaTools.c | 8 +- lib/lzo/lzo1x_decompress.c | 8 +- test/Makefile | 1 + test/compression.c | 335 ++ 9 files changed, 375 insertions(+), 12 deletions(-) create mode 100644 test/compression.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board
On Wed, 04 Sep 2013 12:05:00 -0600
Stephen Warren swar...@wwwdotorg.org wrote:
On 09/04/2013 07:00 AM, Alban Bedel wrote:
Add support for the new Tamonten™ NG platform from Avionic Design.
Currently only I2C, MMC, USB and ethernet have been tested.
(Also CC'ing the Tegra maintainer here)
Ok, I'll add him in the next patch round.
diff --git a/board/avionic-design/common/tamonten-ng.c
b/board/avionic-design/common/tamonten-ng.c
+void pmu_write(uchar reg, uchar data)
+{
+ int i;
+ i2c_set_bus_num(0); /* PMU is on bus 0 */
+ for (i = 0; i MAX_I2C_RETRY; ++i) {
+ if (i2c_write(PMU_I2C_ADDRESS, reg, 1, data, 1))
+ udelay(100);
+ else
+ break;
+ }
+}
Is there really a need to retry the I2C transactions? If so, why do
they fail? I assume this was just copy/pasted from some other board
file, and there's no need for any retries?
Yes, that was adapted from the cardhu code and the retry are most
probably useless. I just made a bit more generic function because
we have to set several outputs, on cardhu only one is set.
It'd be nice if there was a proper PMU subsystem, so we could have a
specific driver for each PMU chip, rather than having
open-coded/custom writes to the PMU registers in each board file, but
I guess that's not an issue with this patch specfically.
A PMU subsystem would be nice, although something that would be
compatible with the Linux regulator and their representation in DT
would be even better.
Otherwise a first step could be to at least create a driver for this
PMU, similar to one for tps6586x. That would at least prevent too much
code duplication between the T30 boards.
diff --git a/include/configs/tec-ng.h b/include/configs/tec-ng.h
+/* support the new (FDT-based) image format */
+#define CONFIG_FIT
Hmmm. Do the standard Tegra boot scripts in tegra-common-post.h deal
well with FIT? I've tried to avoid FIT usage as much as possible.
AFAIU it doesn't change anything if you use old images, it just allow
you to also use FIT image. As the build system we use for our platform
produce FIT image we do need support for it. Or should such things,
which are not related to the HW config, be configured in another place?
Alban
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Chander, On Thu, 5 Sep 2013 17:36:34 +0530, Chander Kashyap chander.kash...@linaro.org wrote: Hi Albert, On 5 September 2013 17:08, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Chander, On Thu, 5 Sep 2013 16:47:27 +0530, Chander Kashyap chander.kash...@linaro.org wrote: Hi Lukasz, On 5 September 2013 16:27, Lukasz Majewski l.majew...@samsung.com wrote: Hi Chander, Its working for me. But my dtc -v: Version: DTC 1.3.0 Have you managed to properly build test Samsung's u-boot tree with DTC 1.3.0? Yes, I am able to build and test. I am running on ubuntu. Then you are not testing on a recent enough U-Boot source tree; currently, master (and arm) require dtc version = 1.4.0, and will fail as indicated by Lukasz and as experienced by me -- I had to build dtc version 1.4.0 from git source. Sorry for big mess. I had re-based my tree to u-boot samsung. I have tested it after re-basing to u-boot tree. It was failing. Shall i send all the patches again, or is it possible to send the single failing patch. Well, if you have rebased to u-boot-master, then you can as well do an interactive rebase so that the commit which breaks builds is omitted. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Enable serial console only before booting
On Sun, Jul 07, 2013 at 12:25:36PM +0200, Fr??d??ric Leroy wrote: When netconsole is active, some boards fail to boot. This patch enables only the serial console before control is handed by another operating system. Signed-off-by: Fr??d??ric Leroy fr...@starox.org --- Hello, I am facing the same problem with LaCie kirkwood boards. I took a simple approach for fixing this issue. This works for me ... Any comments are welcome :) Can you please re-base this to mainline and re-post? Also, can you expand on the comments in the commit message to explain the problem with netconsole and thus why this fixes it? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: gadget: Fix data aborts during USB ethernet boot
Dear Bo Shen, Hi Joel Fernandes, On 09/05/2013 07:55 AM, Joel Fernandes wrote: As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned on 4 byte boundaray causing data aborts in eth_setup - conf_buf during dhcp boot over usb_ether. Fix the issue my aligning control_req buffer using DEFINE_CACHE_ALIGN_BUFFER. Tested on am335x_evm platform (beaglebone). Applies on 2013.10-rc1 branch. Cc: Tom Rini tr...@ti.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Joel Fernandes jo...@ti.com --- v2 changes: - Using DEFINE_CACHE_ALIGN_BUFFER macro for the alignment. - Also fixed alignment for status_req. v3 changes: - Adjusted commit message for v2 change. drivers/usb/gadget/ether.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Test on sama5d3xek board with RNDIS gadget, it still has the unaligned access issue. However, I test with this patch usb: gadget: config: fix unaligned access issues from: Troy Kisky troy.ki...@boundarydevices.com really fix the unaligned access issue. more information at: http://patchwork.ozlabs.org/patch/264151/ Troy, care to fix up the patch's commit log so I can try and understand it? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] dfu:mmc: raw data write fix
On Wed, Aug 21, 2013 at 01:00:01PM +0200, Mateusz Zalega wrote: When user attempted to perform a raw write using DFU (vide dfu_fill_entity_mmc) with MMC interface not initialized before, get_mmc_blk_size() reported invalid (zero) block size - it wasn't possible to write ie. a new u-boot image. This commit fixes that by initializing device in get_mmc_blk_size() when needed. Tested on Samsung Goni. Signed-off-by: Mateusz Zalega m.zal...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Acked-by: Tom Rini tr...@ti.com I poked Marek on IRC yesterday, and he was fine with me taking this into master, but since it depends on some other samsung patches, I'm fine with this going in via u-boot-samsung. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: lds: Remove libgcc eabi exception handling tables
Hi Albert,
On 09/05/2013 03:03 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 25 Jul 2013 16:16:46 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Remove ARM eabi exception handling tables (for frame unwinding).
AFAICT, u-boot stubs away the frame unwiding routines, so the tables will
more or less just consume space. It should be OK to remove them.
Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
This patch was sent to ML as RFC (May 9)
Here is the origin response in connection to this patch.
Ok, so Michal and I just did some fiddling with zynq builds and
*exidx* sections.
By default the *exidx* sections are between rodata and data, so
removing them causes many apparent changes at the binary level.
However, builds of zynq based on ARM master with the patch above vs
master with a patch mapping *exidx* sections after BSS gives identical
binaries. Thus the RFC has no functional effect.
Also, ARM EHABI states that [exception] Tables are not required for ABI
compliance at the C/Assembler level but are required for C++.
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
So as long as we don't put any C++ code in U-Boot (a prospect that I
don't see happening any time soon), this RFC is safe and either is a
no-op or removes useless bytes from the binary.
---
arch/arm/cpu/u-boot.lds | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 3037885..8894c8a 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -113,4 +113,6 @@ SECTIONS
/DISCARD/ : { *(.plt*) }
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
+/DISCARD/ : { *(.ARM.exidx*) }
+/DISCARD/ : { *(.gnu.linkonce.armexidx.*) }
}
--
1.8.2.3
The good news is, it applies and does not cause any build issues.
The less good news is, arch/arm/cpu/u-boot.lds is not the only linker
script file to fix if we want to fix it this way.
The fact is, I am not sure removing sections from the ELF filein order
to avoid them being in the binary is actually the right way to go. I
have recently had to 'un-discard' some sections in order for
'offline' debugging tools to properly understand the ELF file.
So I am wondering if we should not stop using /DISCARD/ and start using
$(CROSS_COMPILE)objcopy options (-j or --strip-* and --remove-section).
This way, the ELF file would be as complete as any debug tool might
expect it (e.g. objdump, especially when debugging relocation issues)
yet the binary file would remain unchanged.
But past rc2 is not a time to start such a change.
Still, I'd like your fix to be consistent across all of ARM. Can you
change all the linker scripts used for build ARM targets? These are,
according to an ugly mix of cat LOG/*.MAKELOG, sed, grep and sort -u:
arch/arm/cpu/arm1136/u-boot-spl.lds
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds
arch/arm/cpu/ixp/u-boot.lds
arch/arm/cpu/u-boot.lds
arch/arm/cpu/u-boot-spl.lds
board/actux1/u-boot.lds
board/actux2/u-boot.lds
board/actux3/u-boot.lds
board/ait/cam_enc_4xx/u-boot-spl.lds
board/davinci/da8xxevm/u-boot-spl-da850evm.lds
board/davinci/da8xxevm/u-boot-spl-hawk.lds
board/dvlhost/u-boot.lds
board/freescale/mx31ads/u-boot.lds
board/samsung/common/exynos-uboot-spl.lds
board/ti/am335x/u-boot.lds
board/vpac270/u-boot-spl.lds
Honestly for me is much easier just fix our timer code not to use this section
instead of trying to fix 3rd party platforms.
Is there any reason why too many linkers scripts are in u-boot for ARM?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Failing USB devices
Dear Andrew Murray, On 30 August 2013 18:05, Andrew Murray amur...@embedded-bits.co.uk wrote: On 23 August 2013 04:23, Marek Vasut ma...@denx.de wrote: Dear Andrew Murray, Hello, I'm unable to use some mass storage devices with the current git version (6612ab33956ae09c5ba2fde9c1540b519625ba37) of UBoot on a TI Davinci custom board. I have 7 pen drives, and 2 of them fail. I-O DATA USB Flash Disk (0x04bb/0x0c43) ... 2 USB Device(s) found scan end scanning usb for storage devices... i=0 i=1 USB Mass Storage device detected Transport: Bulk/Bulk/Bulk Endpoints In 1 Out 2 Int 0 usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0 length 0x1 Get Max LUN - len = 1, result = 0 address 2 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 error in inquiry i=2 0 Storage Device(s) found In this case putting a delay of 1000ms in usb_stor_BBB_transport between the COMMAND and DATA phase, (in place of the conditional 5ms USB_READY delay), overcomes this issue. It seems this 1000ms delay is only required for the first COMMAND, subsequent COMMAND phases seem happy with the 5ms delay. Lexar JumpDrive 32GB (0x0424/0x2507): So the device takes too long to init itself after powering up the port. It would be nice if you could check the spec and see if there is a way to query the device for ready condition. Although I remember we already do that. After further investigation I've learnt that removing references to MUSB_CSR0_H_DIS_PING in musb_hcd.c removes the need for a large delay between the COMMAND and STATUS phases, this allows more USB mass storage devices to work. MUSB_CSR0_H_DIS_PING sets bit 12 of txcsr, however on the DM36x (http://www.ti.com/litv/pdf/sprufh9a) this appears to be a reserved bit. In any case it appears to have an undesirable effect. The linux driver does appear to use this bit, yet these devices do work under Linux. I'll submit a patch if you feel this is incorrect, any suggestions for the best way to fix this? Hi Marek, As there has been no feedback on this, are you happy to accept a patch that conditionally sets MUSB_CSR0_H_DIS_PING in the header file to 0 when CONFIG_SOC_DM365 is defined? Thanks, Andrew Murray I'd like to know from Tom what he things of this OMAP breakage first. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
On Thu, 2013-09-05 at 08:28 +0200, Andreas Bießmann wrote: Dear Scott Wood, On 04.09.13 21:44, Scott Wood wrote: On Wed, 2013-09-04 at 17:15 +0200, Andreas Bießmann wrote: On 09/04/2013 02:46 PM, Bo Shen wrote: On 9/4/2013 8:30 PM, Andreas Bießmann wrote: Yes, we need libbch. If we really want to enable software BCH support. It also need add following two options in board configuration file. ---8--- #define CONFIG_NAND_ECC_BCH #define CONFIG_BCH ---8--- So, this patch give us option to enable software BCH. got it. So the NAND_ECC_BCH is the adoption for the SW BCH correction in mtd layer. I understand that this would be helpful for at91 SoC without PMECC HW. But there is no user currently, so I hesitate to apply this. Frankly, there is no EK boards from Atmel use software BCH now, however, a lot of customers use NAND with 224 bytes OOB, can not use software ECC, they need use software BCH. I understand this. But it will be a piece of dead code until a user of it would be submitted. So, I think it is better to apply this patch. If it will break the rule of u-boot, then I think we can wait real user in u-boot need this and then apply this patch. I'd like to hear Scott's comment on that. Is this for the benefit of out-of-tree boards, or for boards which will be submitted but haven't yet? In the latter case, it could be submitted at the same time. In the former case, of course we encourage the boards to be submitted, and we don't generally add code solely for the benefit of out-of-tree boards. In any case, this is minor enough that I don't care all that much. If we ever get kconfig, then hopefully the dead code rules will relax to code which could be enabled through some legal config, rather than code which is enabled in some default config for a board. Things like allyesconfig and randconfig could help with build test coverage. I think this is a 'yes we take it'. Scott, would you pull it in or should I do? Is it even that minor to pull it into 2013.10? It was posted weeks after merge window closed. I can take it, but not for 2013.10. It's not a bugfix. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling certain files with extra compiler flags
On Wed, Sep 4, 2013 at 8:16 PM, Simon Glass s...@google.com wrote: Hi Vadim, OK I see. You can do something like this: CFLAGS_arch/arm/cpu/tegra20-common/warmboot_avp.o += -march=armv4t (this is used by Tegra) Regards, Simon Ah, this works, thank you, Simon! --vb On Wed, Sep 4, 2013 at 8:25 PM, Vadim Bendebury vben...@chromium.org wrote: this is the tweak -- Forwarded message -- From: Vadim Bendebury vben...@chromium.org Date: Wed, Sep 4, 2013 at 11:49 AM Subject: Compiling certain files with extra compiler flags To: uboot u-boot@lists.denx.de Does u-boot provide the ability to change compilation options 'on the fly', say when certain files need to be compiled for symbolic debugging? I looked but did not find any. How about something like this: vvv $ git diff config.mk diff --git a/config.mk b/config.mk index 853e6d8..41cafbb 100644 --- a/config.mk +++ b/config.mk @@ -406,7 +406,7 @@ $(obj)%.o: %.c ifneq ($(CHECKSRC),0) $(CHECK) $(CHECKFLAGS) $(ALL_CFLAGS) $ endif - $(CC) $(ALL_CFLAGS) -o $@ $ -c + $(CC) $(ALL_CFLAGS) $(CPP_$(subst .,_,$)) -o $@ $ -c $(obj)%.i: %.c $(CPP) $(ALL_CFLAGS) -o $@ $ -c $(obj)%.s: %.c ^ Then, say I want to have spl_boot.c compiled with extra flags, just invoking make like this does the trick: CPP_spl_boot_c='-O0 -fno-default-inline' make ... Or is there a better way? --vb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compiling certain files with extra compiler flags
Hi Vadim, On Thu, Sep 5, 2013 at 10:50 AM, Vadim Bendebury vben...@chromium.org wrote: On Wed, Sep 4, 2013 at 8:16 PM, Simon Glass s...@google.com wrote: Hi Vadim, OK I see. You can do something like this: CFLAGS_arch/arm/cpu/tegra20-common/warmboot_avp.o += -march=armv4t (this is used by Tegra) Regards, Simon Ah, this works, thank you, Simon! Great! --vb Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: new board-specific USB init interface
On 09/05/13 17:50, Marek Vasut wrote: v3 changes: - added 'index' argument to perform selective port initialization OK, a few general ideas again: Why not wrap board_usb_init() and board_usb_init_fail() into single call. You now pass some flags to board_usb_init() already, so just add another for the fail case. How does it sound to you? Like overengineering. It would lead to board_usb_init(USB_INIT_ALL, USB_INIT_DEVICE, USB_CLEANUP) calls, which are not very readable. Moreover, the 'int index' should likely be unsigned int and the special value to init all controllers at once should probably then be 0x Despite our greatest ambitions, I don't think we're likely to use more than 2^31-1 USB controllers at a time. Besides, negative values look better both in code and debugger session. Best Regards, -- Mateusz Zalega Samsung RD Institute Poland ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: lds: Remove libgcc eabi exception handling tables
Hi Michal,
On Thu, 05 Sep 2013 17:30:54 +0200, Michal Simek mon...@monstr.eu
wrote:
Hi Albert,
On 09/05/2013 03:03 PM, Albert ARIBAUD wrote:
Hi Michal,
On Thu, 25 Jul 2013 16:16:46 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Remove ARM eabi exception handling tables (for frame unwinding).
AFAICT, u-boot stubs away the frame unwiding routines, so the tables will
more or less just consume space. It should be OK to remove them.
Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
This patch was sent to ML as RFC (May 9)
Here is the origin response in connection to this patch.
Ok, so Michal and I just did some fiddling with zynq builds and
*exidx* sections.
By default the *exidx* sections are between rodata and data, so
removing them causes many apparent changes at the binary level.
However, builds of zynq based on ARM master with the patch above vs
master with a patch mapping *exidx* sections after BSS gives identical
binaries. Thus the RFC has no functional effect.
Also, ARM EHABI states that [exception] Tables are not required for ABI
compliance at the C/Assembler level but are required for C++.
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
So as long as we don't put any C++ code in U-Boot (a prospect that I
don't see happening any time soon), this RFC is safe and either is a
no-op or removes useless bytes from the binary.
---
arch/arm/cpu/u-boot.lds | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 3037885..8894c8a 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -113,4 +113,6 @@ SECTIONS
/DISCARD/ : { *(.plt*) }
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
+ /DISCARD/ : { *(.ARM.exidx*) }
+ /DISCARD/ : { *(.gnu.linkonce.armexidx.*) }
}
--
1.8.2.3
The good news is, it applies and does not cause any build issues.
The less good news is, arch/arm/cpu/u-boot.lds is not the only linker
script file to fix if we want to fix it this way.
The fact is, I am not sure removing sections from the ELF filein order
to avoid them being in the binary is actually the right way to go. I
have recently had to 'un-discard' some sections in order for
'offline' debugging tools to properly understand the ELF file.
So I am wondering if we should not stop using /DISCARD/ and start using
$(CROSS_COMPILE)objcopy options (-j or --strip-* and --remove-section).
This way, the ELF file would be as complete as any debug tool might
expect it (e.g. objdump, especially when debugging relocation issues)
yet the binary file would remain unchanged.
But past rc2 is not a time to start such a change.
Still, I'd like your fix to be consistent across all of ARM. Can you
change all the linker scripts used for build ARM targets? These are,
according to an ugly mix of cat LOG/*.MAKELOG, sed, grep and sort -u:
arch/arm/cpu/arm1136/u-boot-spl.lds
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds
arch/arm/cpu/ixp/u-boot.lds
arch/arm/cpu/u-boot.lds
arch/arm/cpu/u-boot-spl.lds
board/actux1/u-boot.lds
board/actux2/u-boot.lds
board/actux3/u-boot.lds
board/ait/cam_enc_4xx/u-boot-spl.lds
board/davinci/da8xxevm/u-boot-spl-da850evm.lds
board/davinci/da8xxevm/u-boot-spl-hawk.lds
board/dvlhost/u-boot.lds
board/freescale/mx31ads/u-boot.lds
board/samsung/common/exynos-uboot-spl.lds
board/ti/am335x/u-boot.lds
board/vpac270/u-boot-spl.lds
Honestly for me is much easier just fix our timer code not to use this section
instead of trying to fix 3rd party platforms.
I was only asking. I did not intend to force any work upon you. As I
said, we're past -rc2.
So, I'll just pick it as-is. Will your timer code go into mainline
soon? This would ensure that a build failure would be detected
immediately if the change was reverted by any later commit such as the
make a full ELF and a slashed .bin change I have mentioned.
Is there any reason why too many linkers scripts are in u-boot for ARM?
Yes: copy-paste. :)
More seriously, when start.o files started popping in different places
for different ARM targets, this was handled by duplicating .lds files
and changing the start.o location in each .lds. Then it got worse when
some targets starting needing different memory region mappings.
I am working on reducing both the start.o and lds mess. I was initially
aiming for 2013.10, will do it for 2014.01.
Thanks,
Michal
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: new board-specific USB init interface
Dear Mateusz Zalega, On 09/05/13 17:50, Marek Vasut wrote: v3 changes: - added 'index' argument to perform selective port initialization OK, a few general ideas again: Why not wrap board_usb_init() and board_usb_init_fail() into single call. You now pass some flags to board_usb_init() already, so just add another for the fail case. How does it sound to you? Like overengineering. It would lead to board_usb_init(USB_INIT_ALL, USB_INIT_DEVICE, USB_CLEANUP) calls, which are not very readable. This is not what I mean, see this: int board_usb_init(int index, enum board_usb_init_type init) Add a new init type (or maybe change the init field to be flags) that will say OK, do a fail init ? Moreover, the 'int index' should likely be unsigned int and the special value to init all controllers at once should probably then be 0x Despite our greatest ambitions, I don't think we're likely to use more than 2^31-1 USB controllers at a time. Besides, negative values look better both in code and debugger session. Thinking of it further, instead of using negative value here, like I mentioned above, why not make the board_usb_init_type into a field of flags , then add flag to init all controllers at once ? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board
On 09/05/2013 06:46 AM, Alban Bedel wrote: On Wed, 04 Sep 2013 12:05:00 -0600 Stephen Warren swar...@wwwdotorg.org wrote: On 09/04/2013 07:00 AM, Alban Bedel wrote: Add support for the new Tamonten™ NG platform from Avionic Design. Currently only I2C, MMC, USB and ethernet have been tested. ... diff --git a/include/configs/tec-ng.h b/include/configs/tec-ng.h +/* support the new (FDT-based) image format */ +#define CONFIG_FIT Hmmm. Do the standard Tegra boot scripts in tegra-common-post.h deal well with FIT? I've tried to avoid FIT usage as much as possible. AFAIU it doesn't change anything if you use old images, it just allow you to also use FIT image. As the build system we use for our platform produce FIT image we do need support for it. Or should such things, which are not related to the HW config, be configured in another place? No, this file is the right/only place for such things. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot 2009.11.1 USB Issue and Building U-Boot 2013.07
Hello Andreas, Thanks for the reply! Dear Chuck Wical, On 09/03/2013 10:53 PM, Chuck Wical wrote: First I am fairly new to U-Boot but over the last 2 weeks I have been going through the README files and anything else I can find that would help resolve the issue I have. Here is a recap: Currently the project I am working on was setup with U-Boot 2009-11-01 and works just fine with one exception. I was asked to find a solution where our field support engineers could recover if a firmware update failed causing our board to no longer boot. Basically it cycles through RomBOOT and U-Boot. As I looked through the environment variables and commands I came across the USB subsystem and found I could use fatload. With our system there are three files I need to load from USB, these are uImage, etc.jff2 and rootfs.ext2.gz.uboot. you could also use fatload on mmc. Do you have some mmc in your device? We do have mmc slots available on the board but U-Boot is not configured to use mmc. I don't know why that is as it would have made perfect sense to do so. In the meantime, I am trying to figure out how to enable mmc but running into a little difficulty. To put it simply, I just do not know where to enable it or where to look. I will keep trying but a little guidance would be very much appreciated. I found if I used tftp these files transferred correctly and the board would boot with the new files. I thought the solution was found and I could simply setup the same files using USB through environment variables. The script worked but the problem was when it tried to load rootfs into RAM it would cause a CPU reset and RomBOOT to start. At first I thought there was something wrong with the script so I tried to load the file by typing it the command but got the same result. I tested the 2009.11.1 release on my 9263ek here and can confirm, that the usb support there is really buggy. It doesn't support current storage devices, seems to behave differently every time I access the device (timeouts, ...). I managed however to load a 16MiB file via usb storage successfully. The size of file I am trying to load is 7MiB but with your comments above it makes me wonder if a timeout is occurring thus forcing the reboot. Command: usb start fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot where loadaddr is the same address used by tftp. That's in general correct. My first question is, is there a solution for this issue using U-Boot 2009.11.1? This version builds currently within our project. As these are my first steps with 2009.11.1 and usb storage I can't say it. You could backport current usb stack to have better support. On the other hand porting your board forward isn't that hard. Second question is I downloaded U-Boot 2013.07 but noticed huge change in the build process. I figured out the patches I need along with the AT91 configuration for our board. We are using the arm926ej6 processor with a board similar to at91sam9260ek. When I try to build I get the hardware.h:49:3 error: #error Unsupported AT91 processor message. When I HAve a look at 9260ek config, it is still in current releases and builds at least. I rarely test the built on real hardware, at the moment I only have an sam9263ek handy. I will take a look and yes, we are using real hardware and I do not have access to a sam9263ek either. look at the header file I see where it fails but I don't understand why since I do have a matching define. For some reason hardware.h is not seeing this define and I am stumped as to why. So any suggestions on how to solve or figure this out would be appreciated. If you plan to integrate your patches into mainline, we could help to adopt them where needed. I have no plans to incorporate the patches into mainline as they seem very specific to our board and configuration. Best regards Andreas Bießmann Cheers Chuck Wical ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] nand, davinci: add special UBL ecc position
On Thu, 2013-09-05 at 07:14 +0200, Heiko Schocher wrote:
enable the RBL/UBL ECC layout through
CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC define
see for more info:
http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/davinci_nand.c | 10 ++
1 Datei geändert, 10 Zeilen hinzugefügt(+)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index d8bb5d3..9f5bd85 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -267,6 +267,15 @@ static struct nand_ecclayout
nand_davinci_4bit_layout_oobfirst = {
#if defined(CONFIG_SYS_NAND_PAGE_2K)
.eccbytes = 40,
.eccpos = {
+#ifdef CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
+ 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+ 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
+ 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
+ },
+ .oobfree = {
+ {2, 4}, {16, 6}, {32, 6}, {48, 6},
+#else
24, 25, 26, 27, 28,
29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
@@ -275,6 +284,7 @@ static struct nand_ecclayout
nand_davinci_4bit_layout_oobfirst = {
},
.oobfree = {
{.offset = 2, .length = 22, },
+#endif /* #ifdef CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC */
},
#elif defined(CONFIG_SYS_NAND_PAGE_4K)
.eccbytes = 80,
The if/else/endif is located awkwardly relative to the braces... I
think it would be more readable if the conditional section started with
.eccpos = and ended with },.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: gadget: Fix data aborts during USB ethernet boot
Dear Joel Fernandes,
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer using DEFINE_CACHE_ALIGN_BUFFER.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Joel Fernandes jo...@ti.com
---
v2 changes:
- Using DEFINE_CACHE_ALIGN_BUFFER macro for the alignment.
- Also fixed alignment for status_req.
v3 changes:
- Adjusted commit message for v2 change.
drivers/usb/gadget/ether.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..700d5fb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,9 +849,10 @@ static struct usb_gadget_strings stringtab = {
};
/*
*/ -static u8 control_req[USB_BUFSIZ];
+DEFINE_CACHE_ALIGN_BUFFER(u8, control_req, USB_BUFSIZ);
+
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
-static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+DEFINE_CACHE_ALIGN_BUFFER(u8, status_req, STATUS_BYTECOUNT);
#endif
Applied, thanks
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: new board-specific USB init interface
Dear Mateusz Zalega, This commit unifies board-specific USB initialization implementations under one symbol (usb_board_init), declaration of which is available in usb.h. Signed-off-by: Mateusz Zalega m.zal...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Lukasz Majewski l.majew...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Marek Vasut ma...@denx.de --- Changes since RFC (v1): - NVIDIA Tegra doesn't postpone its USB init anymore - board_usb_init()'s sole argument name was shortened - networking code comment style (/* blurb...) dropped - squashed RFC changes so that patch won't break bisect v2 changes: - commit message fixup v3 changes: - added 'index' argument to perform selective port initialization OK, a few general ideas again: Why not wrap board_usb_init() and board_usb_init_fail() into single call. You now pass some flags to board_usb_init() already, so just add another for the fail case. How does it sound to you? Moreover, the 'int index' should likely be unsigned int and the special value to init all controllers at once should probably then be 0x Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Failing USB devices
On 30 August 2013 18:05, Andrew Murray amur...@embedded-bits.co.uk wrote: On 23 August 2013 04:23, Marek Vasut ma...@denx.de wrote: Dear Andrew Murray, Hello, I'm unable to use some mass storage devices with the current git version (6612ab33956ae09c5ba2fde9c1540b519625ba37) of UBoot on a TI Davinci custom board. I have 7 pen drives, and 2 of them fail. I-O DATA USB Flash Disk (0x04bb/0x0c43) ... 2 USB Device(s) found scan end scanning usb for storage devices... i=0 i=1 USB Mass Storage device detected Transport: Bulk/Bulk/Bulk Endpoints In 1 Out 2 Int 0 usb_control_msg: request: 0xFE, requesttype: 0xA1, value 0x0 index 0x0 length 0x1 Get Max LUN - len = 1, result = 0 address 2 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 COMMAND phase DATA phase STATUS phase !CSWSIGNATURE BBB_reset usb_control_msg: request: 0xFF, requesttype: 0x21, value 0x0 index 0x0 length 0x0 RESET:stall inquiry returns -1 error in inquiry i=2 0 Storage Device(s) found In this case putting a delay of 1000ms in usb_stor_BBB_transport between the COMMAND and DATA phase, (in place of the conditional 5ms USB_READY delay), overcomes this issue. It seems this 1000ms delay is only required for the first COMMAND, subsequent COMMAND phases seem happy with the 5ms delay. Lexar JumpDrive 32GB (0x0424/0x2507): So the device takes too long to init itself after powering up the port. It would be nice if you could check the spec and see if there is a way to query the device for ready condition. Although I remember we already do that. After further investigation I've learnt that removing references to MUSB_CSR0_H_DIS_PING in musb_hcd.c removes the need for a large delay between the COMMAND and STATUS phases, this allows more USB mass storage devices to work. MUSB_CSR0_H_DIS_PING sets bit 12 of txcsr, however on the DM36x (http://www.ti.com/litv/pdf/sprufh9a) this appears to be a reserved bit. In any case it appears to have an undesirable effect. The linux driver does appear to use this bit, yet these devices do work under Linux. I'll submit a patch if you feel this is incorrect, any suggestions for the best way to fix this? Hi Marek, As there has been no feedback on this, are you happy to accept a patch that conditionally sets MUSB_CSR0_H_DIS_PING in the header file to 0 when CONFIG_SOC_DM365 is defined? Thanks, Andrew Murray ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: lds: Remove libgcc eabi exception handling tables
Hi Michal,
On Thu, 25 Jul 2013 16:16:46 +0200, Michal Simek
michal.si...@xilinx.com wrote:
Remove ARM eabi exception handling tables (for frame unwinding).
AFAICT, u-boot stubs away the frame unwiding routines, so the tables will
more or less just consume space. It should be OK to remove them.
Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com
Signed-off-by: Michal Simek michal.si...@xilinx.com
---
This patch was sent to ML as RFC (May 9)
Here is the origin response in connection to this patch.
Ok, so Michal and I just did some fiddling with zynq builds and
*exidx* sections.
By default the *exidx* sections are between rodata and data, so
removing them causes many apparent changes at the binary level.
However, builds of zynq based on ARM master with the patch above vs
master with a patch mapping *exidx* sections after BSS gives identical
binaries. Thus the RFC has no functional effect.
Also, ARM EHABI states that [exception] Tables are not required for ABI
compliance at the C/Assembler level but are required for C++.
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
So as long as we don't put any C++ code in U-Boot (a prospect that I
don't see happening any time soon), this RFC is safe and either is a
no-op or removes useless bytes from the binary.
---
arch/arm/cpu/u-boot.lds | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds
index 3037885..8894c8a 100644
--- a/arch/arm/cpu/u-boot.lds
+++ b/arch/arm/cpu/u-boot.lds
@@ -113,4 +113,6 @@ SECTIONS
/DISCARD/ : { *(.plt*) }
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
+ /DISCARD/ : { *(.ARM.exidx*) }
+ /DISCARD/ : { *(.gnu.linkonce.armexidx.*) }
}
--
1.8.2.3
Applied to u-boot-arm/master, thanks!
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: sdhci: use the SDHCI_QUIRK_USE_WIDE8 for samsung SoC
On Jul 19, 2013, at 11:44 AM, Jaehoon Chung wrote: Samsung SoC is supported the WIDE8, even if Controller version is v2.0. So add the SDHCI_QUIRK_USE_WIDE8 for Samsung-SoC. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Pantelis Antoniou pa...@antoniou-consulting.com Thanks ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/mpc85xx: Fix the I2C bus speed error on p1022
From: Tang Yuantian yuantian.t...@freescale.com The source clock frequency of I2C bus on p1022 is the platform(CCB) clock, not CCB/2. The wrong source clock frequency leads to wrong I2C bus speed setting. so, fixed it. Signed-off-by: Tang Yuantian yuantian.t...@freescale.com --- fix bug: ENGR00274019 arch/powerpc/cpu/mpc85xx/speed.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c index 65cc7c0..75c92cc 100644 --- a/arch/powerpc/cpu/mpc85xx/speed.c +++ b/arch/powerpc/cpu/mpc85xx/speed.c @@ -415,7 +415,8 @@ int get_clocks (void) * AN2919. */ #if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \ - defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555) + defined(CONFIG_MPC8560) || defined(CONFIG_MPC8555) || \ + defined(CONFIG_P1022) gd-arch.i2c1_clk = sys_info.freq_systembus; #elif defined(CONFIG_MPC8544) /* -- 1.8.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] nand, davinci: add special UBL ecc position
enable the RBL/UBL ECC layout through
CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC define
see for more info:
http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Scott Wood scottw...@freescale.com
---
- changes for v2:
add comment from Scott Wood:
- move if/else/end to a more readable place
---
drivers/mtd/nand/davinci_nand.c | 12
1 Datei geändert, 12 Zeilen hinzugefügt(+)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index d8bb5d3..5b17d7b 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -266,6 +266,17 @@ static int nand_davinci_correct_data(struct mtd_info *mtd,
u_char *dat,
static struct nand_ecclayout nand_davinci_4bit_layout_oobfirst = {
#if defined(CONFIG_SYS_NAND_PAGE_2K)
.eccbytes = 40,
+#ifdef CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
+ .eccpos = {
+ 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+ 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
+ 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
+ },
+ .oobfree = {
+ {2, 4}, {16, 6}, {32, 6}, {48, 6},
+ },
+#else
.eccpos = {
24, 25, 26, 27, 28,
29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
@@ -276,6 +287,7 @@ static struct nand_ecclayout
nand_davinci_4bit_layout_oobfirst = {
.oobfree = {
{.offset = 2, .length = 22, },
},
+#endif /* #ifdef CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC */
#elif defined(CONFIG_SYS_NAND_PAGE_4K)
.eccbytes = 80,
.eccpos = {
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] arm, da85x: update for the ipam390 board
- switch to correct ecc layout used by the RBL
enable CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
- update default environment
- change A2CR to correct value for UART boot mode
- adapt cs3cfg timings for nand
- change LED bootmode signalization
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
---
- no changes for v2
board/Barix/ipam390/ipam390-ais-uart.cfg | 2 +-
board/Barix/ipam390/ipam390.c| 29 --
include/configs/ipam390.h| 35
3 Dateien geändert, 32 Zeilen hinzugefügt(+), 34 Zeilen entfernt(-)
diff --git a/board/Barix/ipam390/ipam390-ais-uart.cfg
b/board/Barix/ipam390/ipam390-ais-uart.cfg
index e1a99f2..709cf23 100644
--- a/board/Barix/ipam390/ipam390-ais-uart.cfg
+++ b/board/Barix/ipam390/ipam390-ais-uart.cfg
@@ -109,7 +109,7 @@ CLK2XSRC = 0x
;NANDFCR = 0x
[EMIF25ASYNC]
A1CR = 0x
-A2CR = 0x3FFE
+A2CR = 0x04202110
A3CR = 0x
A4CR = 0x
NANDFCR = 0x0012
diff --git a/board/Barix/ipam390/ipam390.c b/board/Barix/ipam390/ipam390.c
index f3f276e..ae88b42 100644
--- a/board/Barix/ipam390/ipam390.c
+++ b/board/Barix/ipam390/ipam390.c
@@ -264,7 +264,7 @@ void show_boot_progress(int status)
static int green;
if (red == 0)
- red = init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_OFF);
+ red = init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_ON);
if (red != CONFIG_IPAM390_GPIO_LED_RED)
return;
if (green == 0)
@@ -277,10 +277,10 @@ void show_boot_progress(int status)
case BOOTSTAGE_ID_RUN_OS:
/*
* set normal state
-* LED Red : off
+* LED Red : on
* LED green: off
*/
- gpio_set_value(red, LED_OFF);
+ gpio_set_value(red, LED_ON);
gpio_set_value(green, LED_OFF);
break;
case BOOTSTAGE_ID_MAIN_LOOP:
@@ -326,23 +326,12 @@ int spl_start_uboot(void)
if (!bootmode)
if (ret == 0)
bootmode = 1;
- if (bootmode) {
- /*
-* Booting U-Boot
-* LED Red : on
-* LED green: off
-*/
- init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_ON);
- init_led(CONFIG_IPAM390_GPIO_LED_GREEN, green, LED_OFF);
- } else {
- /*
-* Booting Linux
-* LED Red : off
-* LED green: off
-*/
- init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_OFF);
- init_led(CONFIG_IPAM390_GPIO_LED_GREEN, green, LED_OFF);
- }
+ /*
+* LED red : on
+* LED green: off
+*/
+ init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_ON);
+ init_led(CONFIG_IPAM390_GPIO_LED_GREEN, green, LED_OFF);
return bootmode;
}
#endif
diff --git a/include/configs/ipam390.h b/include/configs/ipam390.h
index 82d4298..155663e 100644
--- a/include/configs/ipam390.h
+++ b/include/configs/ipam390.h
@@ -122,13 +122,13 @@
(3 DV_DDR_SDCR_IBANK_SHIFT) |\
(2 DV_DDR_SDCR_PAGESIZE_SHIFT))
-#define CONFIG_SYS_DA850_CS3CFG(DAVINCI_ABCR_WSETUP(2) | \
+#define CONFIG_SYS_DA850_CS3CFG(DAVINCI_ABCR_WSETUP(1) | \
DAVINCI_ABCR_WSTROBE(2) | \
- DAVINCI_ABCR_WHOLD(1) | \
+ DAVINCI_ABCR_WHOLD(0) | \
DAVINCI_ABCR_RSETUP(1) | \
- DAVINCI_ABCR_RSTROBE(4) | \
- DAVINCI_ABCR_RHOLD(0) | \
- DAVINCI_ABCR_TA(1) | \
+ DAVINCI_ABCR_RSTROBE(2) | \
+ DAVINCI_ABCR_RHOLD(1) | \
+ DAVINCI_ABCR_TA(0) | \
DAVINCI_ABCR_ASIZE_8BIT)
@@ -161,6 +161,7 @@
#undef CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND devices */
#define CONFIG_SYS_NAND_HW_ECC_OOBFIRST
+#define CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_PAGE_SIZE (2 10)
#define CONFIG_SYS_NAND_BLOCK_SIZE (128 10)
@@ -173,11 +174,10 @@
CONFIG_SYS_MALLOC_LEN - \
GENERATED_GBL_DATA_SIZE)
#define CONFIG_SYS_NAND_ECCPOS { \
- 24, 25, 26, 27, 28, \
- 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, \
- 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, \
- 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, \
- 59, 60, 61, 62, 63 }
[U-Boot] [PATCH v2 0/2] arm, da85x: updates for the ipam390 board
enable the RBL/UBL ECC layout through CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC define see for more info: http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout and use this on the ipam390 board. Also do some minor changes for this board: - update default environment - change A2CR to correct value for UART boot mode - adapt cs3cfg timings for nand - change LED bootmode signalization - changes for v2: - patch: nand, davinci: add special UBL ecc position - add comment from Scott Wood: - move if/else/end to a more readable place Heiko Schocher (2): nand, davinci: add special UBL ecc position arm, da85x: update for the ipam390 board board/Barix/ipam390/ipam390-ais-uart.cfg | 2 +- board/Barix/ipam390/ipam390.c| 29 -- drivers/mtd/nand/davinci_nand.c | 12 +++ include/configs/ipam390.h| 35 4 Dateien geändert, 44 Zeilen hinzugefügt(+), 34 Zeilen entfernt(-) Signed-off-by: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com Cc: Scott Wood scottw...@freescale.com -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-nios/master
The following changes since commit 315c0ace7c220591a9b220ab7698e85624b430c0: bootm: allow correct bounds-check of destination (2013-09-03 13:30:26 -0600) are available in the git repository at: git://git.denx.de/u-boot-nios.git master for you to fetch changes up to 1a05b5f91e12845cf06f4b1ef34096861bf718b5: nios2: fix missing comment terminator from SPDX License commit (2013-09-06 11:03:42 +0800) Thomas Chou (1): nios2: fix missing comment terminator from SPDX License commit arch/nios2/lib/longlong.h | 1 + 1 file changed, 1 insertion(+) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
Hi Albert, On 5 September 2013 18:58, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Chander, On Thu, 5 Sep 2013 17:36:34 +0530, Chander Kashyap chander.kash...@linaro.org wrote: Hi Albert, On 5 September 2013 17:08, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Chander, On Thu, 5 Sep 2013 16:47:27 +0530, Chander Kashyap chander.kash...@linaro.org wrote: Hi Lukasz, On 5 September 2013 16:27, Lukasz Majewski l.majew...@samsung.com wrote: Hi Chander, Its working for me. But my dtc -v: Version: DTC 1.3.0 Have you managed to properly build test Samsung's u-boot tree with DTC 1.3.0? Yes, I am able to build and test. I am running on ubuntu. Then you are not testing on a recent enough U-Boot source tree; currently, master (and arm) require dtc version = 1.4.0, and will fail as indicated by Lukasz and as experienced by me -- I had to build dtc version 1.4.0 from git source. Sorry for big mess. I had re-based my tree to u-boot samsung. I have tested it after re-basing to u-boot tree. It was failing. Shall i send all the patches again, or is it possible to send the single failing patch. Well, if you have rebased to u-boot-master, then you can as well do an interactive rebase so that the commit which breaks builds is omitted. Offending patch was part of two patch series. I have fixed it and resend it with series again. Amicalement, -- Albert. -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
