[U-Boot] [PATCH 2/4] arm: rmobile: kzm9g: remove unrelated config
From: Tetsuyuki Kobayashi Remove CONFIG_INTEGRATOR and CONFIG_ARCH_CINTEGRATOR. These are not for kzm9g. Signed-off-by: Tetsuyuki Kobayashi --- include/configs/kzm9g.h |2 -- 1 file changed, 2 deletions(-) diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h index a4d2c37..bc6dc72 100644 --- a/include/configs/kzm9g.h +++ b/include/configs/kzm9g.h @@ -48,8 +48,6 @@ #define CONFIG_BAUDRATE115200 #define CONFIG_BOOTARGS"root=/dev/null console=ttySC4,115200" -#define CONFIG_INTEGRATOR -#define CONFIG_ARCH_CINTEGRATOR #define CONFIG_BOOTDELAY 3 #define CONFIG_VERSION_VARIABLE -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] arm: rmobile: kzm9g: fix CPU info
From: Tetsuyuki Kobayashi
CPU info register was read wrongly by mistake. And function
rmobile_get_cpu_rev() was not called properly.
Signed-off-by: Tetsuyuki Kobayashi
---
arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c |6 +++---
arch/arm/cpu/armv7/rmobile/cpu_info.c|2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
b/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
index f5273cf..a715efa 100644
--- a/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
+++ b/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
@@ -30,19 +30,19 @@ u32 rmobile_get_cpu_type(void)
u32 type;
struct sh73a0_hpb *hpb = (struct sh73a0_hpb *)HPB_BASE;
- id = readl(hpb->cccr);
+ id = readl(&hpb->cccr);
type = (id >> 8) & 0xFF;
return type;
}
-u32 get_cpu_rev(void)
+u32 rmobile_get_cpu_rev(void)
{
u32 id;
u32 rev;
struct sh73a0_hpb *hpb = (struct sh73a0_hpb *)HPB_BASE;
- id = readl(hpb->cccr);
+ id = readl(&hpb->cccr);
rev = (id >> 4) & 0xF;
return rev;
diff --git a/arch/arm/cpu/armv7/rmobile/cpu_info.c
b/arch/arm/cpu/armv7/rmobile/cpu_info.c
index 2148958..957a4fc 100644
--- a/arch/arm/cpu/armv7/rmobile/cpu_info.c
+++ b/arch/arm/cpu/armv7/rmobile/cpu_info.c
@@ -62,7 +62,7 @@ int print_cpuinfo(void)
break;
default:
printf("CPU: Renesas Electronics CPU rev %d\n",
- get_cpu_rev());
+ rmobile_get_cpu_rev());
break;
}
return 0;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] arm: rmobile: kzm9g: add NFS_TIMEOUT in config file
From: Tetsuyuki Kobayashi Set NFS_TIMEOUT to 10,000 msec. Signed-off-by: Tetsuyuki Kobayashi --- This patch needs "net: nfs: make NFS_TIMEOUT configurable", which is applied in u-boot-master next branch, to take effect. include/configs/kzm9g.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h index 14f088f..a4d2c37 100644 --- a/include/configs/kzm9g.h +++ b/include/configs/kzm9g.h @@ -150,6 +150,7 @@ #define CONFIG_SMC911X #define CONFIG_SMC911X_BASE(0x1000) #define CONFIG_SMC911X_32_BIT +#define CONFIG_NFS_TIMEOUT 1UL /* I2C */ #define CONFIG_CMD_I2C -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] arm: rmobile: kzm9g: separate cpu_rev to integer and fraction
From: Tetsuyuki Kobayashi
According to SoC document, revision info is separated to integer part and
fracton part. So I separete rmobile_get_cpu_rev() to
rmobile_get_cpu_rev_integer() and rmobile_get_cpu_rev_fraction().
Signed-off-by: Tetsuyuki Kobayashi
---
arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c | 16 ++--
arch/arm/cpu/armv7/rmobile/cpu_info.c| 23 ---
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
b/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
index a715efa..8239155 100644
--- a/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
+++ b/arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c
@@ -36,14 +36,26 @@ u32 rmobile_get_cpu_type(void)
return type;
}
-u32 rmobile_get_cpu_rev(void)
+u32 rmobile_get_cpu_rev_integer(void)
{
u32 id;
u32 rev;
struct sh73a0_hpb *hpb = (struct sh73a0_hpb *)HPB_BASE;
id = readl(&hpb->cccr);
- rev = (id >> 4) & 0xF;
+ rev = ((id >> 4) & 0xF) + 1;
+
+ return rev;
+}
+
+u32 rmobile_get_cpu_rev_fraction(void)
+{
+ u32 id;
+ u32 rev;
+ struct sh73a0_hpb *hpb = (struct sh73a0_hpb *)HPB_BASE;
+
+ id = readl(&hpb->cccr);
+ rev = id & 0xF;
return rev;
}
diff --git a/arch/arm/cpu/armv7/rmobile/cpu_info.c
b/arch/arm/cpu/armv7/rmobile/cpu_info.c
index 957a4fc..87287ce 100644
--- a/arch/arm/cpu/armv7/rmobile/cpu_info.c
+++ b/arch/arm/cpu/armv7/rmobile/cpu_info.c
@@ -46,23 +46,32 @@ static u32 __rmobile_get_cpu_type(void)
u32 rmobile_get_cpu_type(void)
__attribute__((weak, alias("__rmobile_get_cpu_type")));
-static u32 __rmobile_get_cpu_rev(void)
+static u32 __rmobile_get_cpu_rev_integer(void)
{
return 0;
}
-u32 rmobile_get_cpu_rev(void)
- __attribute__((weak, alias("__rmobile_get_cpu_rev")));
+u32 rmobile_get_cpu_rev_integer(void)
+ __attribute__((weak, alias("__rmobile_get_cpu_rev_integer")));
+
+static u32 __rmobile_get_cpu_rev_fraction(void)
+{
+ return 0;
+}
+u32 rmobile_get_cpu_rev_fraction(void)
+ __attribute__((weak, alias("__rmobile_get_cpu_rev_fraction")));
int print_cpuinfo(void)
{
switch (rmobile_get_cpu_type()) {
case 0x37:
- printf("CPU: Renesas Electronics SH73A0 rev %d\n",
- rmobile_get_cpu_rev());
+ printf("CPU: Renesas Electronics SH73A0 rev %d.%d\n",
+ rmobile_get_cpu_rev_integer(),
+ rmobile_get_cpu_rev_fraction());
break;
default:
- printf("CPU: Renesas Electronics CPU rev %d\n",
- rmobile_get_cpu_rev());
+ printf("CPU: Renesas Electronics CPU rev %d.%d\n",
+ rmobile_get_cpu_rev_integer(),
+ rmobile_get_cpu_rev_fraction());
break;
}
return 0;
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/4] arm: rmobile: kzm9g: update
From: Tetsuyuki Kobayashi Hi, Iwamatsu-san These are minor bug fixes for kzm9g board. Tetsuyuki Kobayashi (4): arm: rmobile: kzm9g: add NFS_TIMEOUT in config file arm: rmobile: kzm9g: remove unrelated config arm: rmobile: kzm9g: fix CPU info arm: rmobile: kzm9g: separate cpu_rev to integer and fraction arch/arm/cpu/armv7/rmobile/cpu_info-sh73a0.c | 20 arch/arm/cpu/armv7/rmobile/cpu_info.c| 23 --- include/configs/kzm9g.h |3 +-- 3 files changed, 33 insertions(+), 13 deletions(-) -- 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 0/3] mmc: sdhci: fixed some problems for Exynos
Hi, This patch-set need to merge for Exynos. Maybe didn't work eMMC at Exynos board in now. Best Regards, Jaehoon Chung On 07/20/2012 01:59 PM, Jaehoon Chung wrote: > To use SDHCI for Samsung-SoC, Some problem is fixed. > See the below mmcinfo message: > > 1. eMMC card: > Device: SAMSUNG SDHCI > Manufacturer ID: 15 > OEM: 100 > Name: VYL00 > Tran Speed: 2500 > Rd Block Len: 512 > MMC version 4.0 > High Capacity: Yes > Capacity: 14.7 GiB > Bus Width: 4-bit > > 2. SD-card > Device: SAMSUNG SDHCI > Manufacturer ID: 3 > OEM: 5344 > Name: SU04G > Tran Speed: 2500 > Rd Block Len: 512 > SD version 2.0 > High Capacity: Yes > Capacity: 3.7 GiB > Bus Width: 4-bit > > Jaehoon Chung (3): > mmc: s5p_sdhci: set the SDHCI_QUIRK_BROKEN_R1B > mmc: s5p_mmc: fixed wrong function argument > mmc: s5p_sdhci: add the set_mmc_clk for cmu control > > arch/arm/include/asm/arch-exynos/mmc.h |4 ++-- > arch/arm/include/asm/arch-s5pc1xx/mmc.h |4 ++-- > drivers/mmc/s5p_sdhci.c | 15 +-- > drivers/mmc/sdhci.c |3 +++ > include/sdhci.h |2 ++ > 5 files changed, 18 insertions(+), 10 deletions(-) > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerdown can't work (mx28)
The poweroff function in kernel can work. The similar code can be found in bootlet from FSL, and it also can work . After poweroff the system, press pswitch key and the board can startup. At 2012-07-26 04:42:28,"Marek Vasut" wrote: >Dear alex, > >> Hi: >> I find that mx28_powerdown function can't power down mx28, and continue >> to load kernel I don't know whether this issue is on your side. My >> board is changed frommx28evk. Was mx28_powerdown function tested? Best > >I think this question was here already. > >What do you expect that function to do? It won't do anything like ACPI >powerdown >you know from PC (it's not even possible on the hardware I guess). > >The function should probably be adjusted and some "for(;;);" added at the end, >but that's probably it. > >Best regards, >Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/85xx: use CONFIG_SYS_FSL_PCIE_COMPAT macro when setting the PCI LIODNs
The SET_PCI_LIODN() macro takes a compatible property string as a parameter, so
that it knows
which PCI device tree node to look for. The calls to these macros are using a
hard-coded string,
but we already have the CONFIG_SYS_FSL_PCIE_COMPAT macro which contains the
same string, so we
should use that.
Signed-off-by: Timur Tabi
---
We don't update p3060_ids.c because support for that SOC is going away.
arch/powerpc/cpu/mpc85xx/p2041_ids.c |6 +++---
arch/powerpc/cpu/mpc85xx/p3041_ids.c |8
arch/powerpc/cpu/mpc85xx/p4080_ids.c |6 +++---
arch/powerpc/cpu/mpc85xx/p5020_ids.c |8
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/p2041_ids.c
b/arch/powerpc/cpu/mpc85xx/p2041_ids.c
index b99b54d..91d9cac 100644
--- a/arch/powerpc/cpu/mpc85xx/p2041_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p2041_ids.c
@@ -62,9 +62,9 @@ struct liodn_id_table liodn_tbl[] = {
SET_SATA_LIODN(1, 127),
SET_SATA_LIODN(2, 128),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 1, 193),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 2, 194),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 3, 195),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 1, 193),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 2, 194),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 3, 195),
SET_DMA_LIODN(1, 197),
SET_DMA_LIODN(2, 198),
diff --git a/arch/powerpc/cpu/mpc85xx/p3041_ids.c
b/arch/powerpc/cpu/mpc85xx/p3041_ids.c
index c50b442..e46a714 100644
--- a/arch/powerpc/cpu/mpc85xx/p3041_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p3041_ids.c
@@ -62,10 +62,10 @@ struct liodn_id_table liodn_tbl[] = {
SET_SATA_LIODN(1, 127),
SET_SATA_LIODN(2, 128),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 1, 193),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 2, 194),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 3, 195),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 4, 196),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 1, 193),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 2, 194),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 3, 195),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 4, 196),
SET_DMA_LIODN(1, 197),
SET_DMA_LIODN(2, 198),
diff --git a/arch/powerpc/cpu/mpc85xx/p4080_ids.c
b/arch/powerpc/cpu/mpc85xx/p4080_ids.c
index a6ea6af..5c287fb 100644
--- a/arch/powerpc/cpu/mpc85xx/p4080_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p4080_ids.c
@@ -52,9 +52,9 @@ struct liodn_id_table liodn_tbl[] = {
SET_SDHC_LIODN(1, 156),
- SET_PCI_LIODN("fsl,p4080-pcie", 1, 193),
- SET_PCI_LIODN("fsl,p4080-pcie", 2, 194),
- SET_PCI_LIODN("fsl,p4080-pcie", 3, 195),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 1, 193),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 2, 194),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 3, 195),
SET_DMA_LIODN(1, 196),
SET_DMA_LIODN(2, 197),
diff --git a/arch/powerpc/cpu/mpc85xx/p5020_ids.c
b/arch/powerpc/cpu/mpc85xx/p5020_ids.c
index ff57a19..e8c26bf 100644
--- a/arch/powerpc/cpu/mpc85xx/p5020_ids.c
+++ b/arch/powerpc/cpu/mpc85xx/p5020_ids.c
@@ -62,10 +62,10 @@ struct liodn_id_table liodn_tbl[] = {
SET_SATA_LIODN(1, 127),
SET_SATA_LIODN(2, 128),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 1, 193),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 2, 194),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 3, 195),
- SET_PCI_LIODN("fsl,qoriq-pcie-v2.2", 4, 196),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 1, 193),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 2, 194),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 3, 195),
+ SET_PCI_LIODN(CONFIG_SYS_FSL_PCIE_COMPAT, 4, 196),
SET_DMA_LIODN(1, 197),
SET_DMA_LIODN(2, 198),
--
1.7.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] powerdown can't work (mx28)
Dear alex, > Hi: > I find that mx28_powerdown function can't power down mx28, and continue > to load kernel I don't know whether this issue is on your side. My > board is changed frommx28evk. Was mx28_powerdown function tested? Best I think this question was here already. What do you expect that function to do? It won't do anything like ACPI powerdown you know from PC (it's not even possible on the hardware I guess). The function should probably be adjusted and some "for(;;);" added at the end, but that's probably 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] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
On Mon, Jul 23, 2012 at 08:16:12AM +0200, Wolfgang Denk wrote: [snip] > Running a full MAKEALL for all architectures and boards, for all > (> 40) repositories, every 24 hours, requires more CPU and I/O cycles > that we can currently afford. MAKEALL is indeed consuming. But I wanted to follow up here on something I've talked a little about on IRC now. On my local box I've cut the time it takes for MAKEALL -a powerpc down from 60min to 33min by using BUILD_NBUILDS=6 BUILD_NCPUS=1 (on a 6 processor (grep -c processor /proc/cpuinfo)) box. I've seen similar reductions on my just TI parts builds. Not that this solves all of our problems, but it should help. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] i.MX28: Add battery boot components to SPL
Dear Lauri Hintsala, > On 07/25/2012 05:17 PM, Lauri Hintsala wrote: > > Hi Marek, > > > > On 05/02/2012 12:09 AM, Marek Vasut wrote: > >> From: Marek Vasut > >> > >> Signed-off-by: Marek Vasut > >> Cc: Detlev Zundel > >> Cc: Fabio Estevam > >> Cc: Stefano Babic > >> Cc: Wolfgang Denk > >> --- > >> > >> arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 100 > >> > >> +++--- > >> > >> 1 file changed, 92 insertions(+), 8 deletions(-) > > > > This patch increases the power consumption about 250 mW (~50mA @ 5V). I > > think it could be nice to disable LRADC after spl boot if it is not > > really needed. > > This happens only on our machine. The increase is only 25 mW (5mA) on > mx28evk. You tried with latest mainline? Sure it's OK to disable LRADC afterwards, will you submit a patch please? > Lauri 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] net: Improve the speed of netconsole
On Tuesday 24 July 2012 16:11:15 Joe Hershberger wrote:
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
> @@ -131,8 +131,17 @@ static void nc_send_packet(const char *buf, int len)
> }
>
> if (eth->state != ETH_STATE_ACTIVE) {
> - if (eth_init(gd->bd) < 0)
> - return;
> +#ifdef CONFIG_NETCONSOLE_PERSIST_ETH
> + if (net_loop_last_protocol != NETCONS) {
> +#endif
> + if (eth_init(gd->bd) < 0)
> + return;
> +#ifdef CONFIG_NETCONSOLE_PERSIST_ETH
> + net_loop_last_protocol = NETCONS;
> + } else {
> + eth_init_state_only(gd->bd);
> + }
> +#endif
seems to me these pre/post clauses should really get refactored someway. the
ifdef noise is significant here.
so in the header, something like:
static inline int eth_reinit_protocol(int protocol)
{
#ifdef CONFIG_NETCONSOLE_PERSIST_ETH
return protocol != NETCONS;
#else
return 1;
#endif
}
static inline void eth_set_last_protocol(int protocol)
{
#ifdef CONFIG_NETCONSOLE_PERSIST_ETH
net_loop_last_protocol = protocol;
#endif
}
#ifdef CONFIG_NETCONSOLE_PERSIST_ETH
extern enum proto_t net_loop_last_protocol;
#else
# define net_loop_last_protocol -1
#endif
then the source becomes the more manageable:
if (eth_reinit_protocol(net_loop_last_protocol)) {
if (eth_init(gd->bd) < 0)
return;
eth_set_last_protocol(NETCONS);
} else
eth_init_state_only(gd->bd);
> --- a/net/eth.c
> +++ b/net/eth.c
>
> +#ifdef CONFIG_NETCONSOLE_PERSIST_ETH
> +int eth_init_state_only(bd_t *bis)
> +{
> + eth_current->state = ETH_STATE_ACTIVE;
> +
> + return 0;
> +}
> +
> +void eth_halt_state_only(void)
> +{
> + eth_current->state = ETH_STATE_PASSIVE;
> +}
> +#endif
these *really* should be static inlines in the global header. they're so dirt
simple, the overhead of the function call is probably much higher than the
single memory store.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] net/bootp: add VCI support for BOOTP also
Hi Joe,
On Wed, Jul 25, 2012 at 3:29 AM, Joe Hershberger
wrote:
>
> > +#define put_vci(e, str)\
> > + do {\
> > + *e++ = 60; \
>
>
> Please keep the comment on the magic number.
>
Sure.
>
> > + *e++ = sizeof(str); \
>
> Did you mean to change this from strlen() to sizeof()? These are not
> the same thing.
>
Good catch, will change it.
>
> > + memcpy(e, str, sizeof(str));\
> > + e += sizeof(str); \
> > + } while (0)
> > +
> > /*
> > * Initialize BOOTP extension fields in the request.
> > */
> > @@ -435,12 +443,10 @@ static int DhcpExtended(u8 *e, int message_type,
> IPaddr_t ServerID,
> > printf("Invalid pxeuuid: %s\n", uuid);
> > }
> > }
> > +#endif
> >
> > - *e++ = 60; /* Vendor Class Identifier */
> > - vci_strlen = strlen(CONFIG_BOOTP_VCI_STRING);
>
> If you aren't using this anymore, then you should remove size_t
> vci_strlen; from the top of the file.
>
Will move it inside macro.
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Binary file header
Hey everyone, I'm trying to find the structure of the binary file header that's created after the u-boot compilation. For example, I already found several informations about the image header structure, and I know that a file u-boot.im is actually the file u-boot.bin with an extra header of 64bytes. However, I didn't find any information about the u-boot.bin header, and I know that it's present, since I can check some data in string format by opening the file with a text editor. I need this information to allow/block some files to be uploaded by my system. Can anyone help me? Thanks in advance, Thiago ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 4/4] arm/km: use kw_sdram_size_adjust to adjust SDRAM size
From: Holger Brunck Some boards may differ only in the SDRAM size. This function allows to fix the size accordingly and we can use the same u-boot binary for both boards. Signed-off-by: Holger Brunck Signed-off-by: Gerlando Falauto cc: Prafulla Wadaskar cc: Valentin Longchamp --- changes for v4: - add bank parameter to kw_sdram_size_adjust() changes for v3: - new patch board/keymile/km_arm/km_arm.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/board/keymile/km_arm/km_arm.c b/board/keymile/km_arm/km_arm.c index 2b2ca39..ac14a2f 100644 --- a/board/keymile/km_arm/km_arm.c +++ b/board/keymile/km_arm/km_arm.c @@ -250,7 +250,8 @@ int board_early_init_f(void) tmp = readl(KW_GPIO0_BASE + 4); writel(tmp & (~KM_KIRKWOOD_SOFT_I2C_GPIOS) , KW_GPIO0_BASE + 4); #endif - + /* adjust SDRAM size for bank 0 */ + kw_sdram_size_adjust(0); kirkwood_mpp_conf(kwmpp_config, NULL); return 0; } -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/4] kirkwood: implement kw_sdram_size_adjust
Size of the SDRAM chips might differ between any two (otherwise
identical) instances of the same board.
So add a function kw_sdram_size_adjust() which reads out the current
ram size for a given bank, and adjusts the Kirkwood's SDRAM window size
register accordingly.
Signed-off-by: Gerlando Falauto
Signed-off-by: Holger Brunck
cc: Prafulla Wadaskar
cc: Valentin Longchamp
---
changes for v4:
- add bank parameter to kw_sdram_size_adjust()
changes for v3:
- rename dram_size_fixup to kw_sdramsize_adjust and move them to
kirkwood/dram.c
changes for v2:
- rebase to current u-boot-marvell.git master branch
arch/arm/cpu/arm926ejs/kirkwood/dram.c | 11 +++
arch/arm/include/asm/arch-kirkwood/cpu.h |1 +
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
index 5e2f9d8..807894f 100644
--- a/arch/arm/cpu/arm926ejs/kirkwood/dram.c
+++ b/arch/arm/cpu/arm926ejs/kirkwood/dram.c
@@ -97,6 +97,17 @@ u32 kw_sdram_bs(enum memory_bank bank)
return result;
}
+void kw_sdram_size_adjust(enum memory_bank bank)
+{
+ u32 size;
+
+ /* probe currently equipped RAM size */
+ size = get_ram_size((void *)kw_sdram_bar(bank), kw_sdram_bs(bank));
+
+ /* adjust SDRAM window size accordingly */
+ kw_sdram_bs_set(bank, size);
+}
+
#ifndef CONFIG_SYS_BOARD_DRAM_INIT
int dram_init(void)
{
diff --git a/arch/arm/include/asm/arch-kirkwood/cpu.h
b/arch/arm/include/asm/arch-kirkwood/cpu.h
index d28c51a..23783d5 100644
--- a/arch/arm/include/asm/arch-kirkwood/cpu.h
+++ b/arch/arm/include/asm/arch-kirkwood/cpu.h
@@ -159,6 +159,7 @@ void reset_cpu(unsigned long ignored);
unsigned char get_random_hex(void);
unsigned int kw_sdram_bar(enum memory_bank bank);
unsigned int kw_sdram_bs(enum memory_bank bank);
+void kw_sdram_size_adjust(enum memory_bank bank);
int kw_config_adr_windows(void);
void kw_config_gpio(unsigned int gpp0_oe_val, unsigned int gpp1_oe_val,
unsigned int gpp0_oe, unsigned int gpp1_oe);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Make netconsole src and dest ports configurable
On Tuesday 24 July 2012 16:11:05 Joe Hershberger wrote:
> --- a/tools/netconsole
> +++ b/tools/netconsole
>
> +board_in_port=${3:-$board_out_port}
board_in_port=${3:-${board_out_port}}
> +echo Board out port: $board_out_port
> +echo Board in port: $board_in_port
echo "Board out port: ${board_out_port}"
echo "Board in port: ${board_in_port}"
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Make the netconsole buffer size configurable
On Tuesday 24 July 2012 16:10:56 Joe Hershberger wrote:
> --- a/drivers/net/netconsole.c
> +++ b/drivers/net/netconsole.c
>
> -static char input_buffer[512];
> +#ifdef CONFIG_NETCONSOLE_BUFFER_SIZE
> +#define BUFFER_SIZE CONFIG_NETCONSOLE_BUFFER_SIZE
> +#else
> +#define BUFFER_SIZE 512
> +#endif
> +
> +static char input_buffer[BUFFER_SIZE];
#ifndef CONFIG_NETCONSOLE_BUFFER_SIZE
# define CONFIG_NETCONSOLE_BUFFER_SIZE 512
#endif
static char input_buffer[CONFIG_NETCONSOLE_BUFFER_SIZE];
> while (len) {
> - int send_len = min(len, 512);
> + int send_len = min(len, BUFFER_SIZE);
int send_len = min(len, sizeof(input_buffer));
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dts/Makefile: Turn off system-/gcc-specific predefined macros
On Tuesday 24 July 2012 15:38:55 Horst Kronstorfer wrote: > On 07/24/2012 05:28 PM, Mike Frysinger wrote: > > On Tuesday 24 July 2012 06:11:04 Horst Kronstorfer wrote: > >> On 07/19/2012 05:22 AM, Mike Frysinger wrote: > >>> On Friday 13 July 2012 09:03:40 Horst Kronstorfer wrote: > Add '-undef' to DTS_CPPFLAGS to avoid unwanted expansion of dts > content that matches system-specific or gcc-specific predefined > macros. > > Example: A number of PowerPC related *.dts files in the kernel define > a property named 'linux,network-index' which (w/o '-undef') is > expanded to '1,network-index' by the preprocessor because of '#define > linux 1.' > >>> > >>> i think you should use -ansi instead. that's what we use in other > >>> places for the same reason. > >> > >> this would increase the probability of a name clash. > > > > no idea what you're talking about. have you actually looked at the > > output of `gcc -E -dD -ansi` ? > > $ gcc -E -dM -ansi - 229 > $ gcc -E -dM -undef - 2 and ? did you *look* at the output ? they're all of the form __foo__. do any device trees really use __foo__ names ? i don't think so. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-BOOT]: Add support for numonyx spi flash.
Hi,
We have a numonyx spi flash (N25Q128) on my target.
I tried using u-boot stmicro.c driver as numonyx and stmicro have same
manufacturing ID's.
The driver detects M25P128 as below ID table
{
.idcode1 = 0x18,
.page_size = 256,
.pages_per_sector = 1024,
.nr_sectors = 64,
.name = "M25P128",
},
I think this could be because we doesn't have a separate driver to support
numonyx.
But the problem is N25Q128 and M25P128
are identically different in-terms of number of sectors as well
as pages per sector due to this I was unable to program the flash.
So, I edited pages_per_sector and nr_sectors to make my flash read/write
will work.
and also added an N25Q128 ID table above M25P128 keeping M25P128 will not
effect.
Everything is fine up to now.
But I think this process is wired when we have more number of numonyx
flashes which identically same
manufacturer id's that are supported in stmicro.c with differences in
sectors.
I have written a separate driver for numonyx which is identically same as
stmicro with added numonyx
ID tables, so it will not touch any thing on stmicro.c.
The reason I am writing different driver for numonyx because it will be a
bit messy If we keep
on adding extra things(specific to numonyx) to stmicro.c
Please let me know your views, if my suggestion is good I will send the
patch.
If am wrong with my understanding, please send an optimized suggestion.
Regards,
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] i.MX28: Add battery boot components to SPL
On 07/25/2012 05:17 PM, Lauri Hintsala wrote: Hi Marek, On 05/02/2012 12:09 AM, Marek Vasut wrote: From: Marek Vasut Signed-off-by: Marek Vasut Cc: Detlev Zundel Cc: Fabio Estevam Cc: Stefano Babic Cc: Wolfgang Denk --- arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 100 +++--- 1 file changed, 92 insertions(+), 8 deletions(-) This patch increases the power consumption about 250 mW (~50mA @ 5V). I think it could be nice to disable LRADC after spl boot if it is not really needed. This happens only on our machine. The increase is only 25 mW (5mA) on mx28evk. Lauri ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] i.MX28: Add battery boot components to SPL
Hi Marek, On 05/02/2012 12:09 AM, Marek Vasut wrote: From: Marek Vasut Signed-off-by: Marek Vasut Cc: Detlev Zundel Cc: Fabio Estevam Cc: Stefano Babic Cc: Wolfgang Denk --- arch/arm/cpu/arm926ejs/mx28/spl_power_init.c | 100 +++--- 1 file changed, 92 insertions(+), 8 deletions(-) This patch increases the power consumption about 250 mW (~50mA @ 5V). I think it could be nice to disable LRADC after spl boot if it is not really needed. Best regards, Lauri Hintsala ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] GPIO: pca953x: fix spelling in help
Signed-off-by: Laurence Withers --- drivers/gpio/pca953x.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpio/pca953x.c b/drivers/gpio/pca953x.c index 359fdee..64c7797 100644 --- a/drivers/gpio/pca953x.c +++ b/drivers/gpio/pca953x.c @@ -287,7 +287,7 @@ U_BOOT_CMD( " - set pin as output and drive low or high\n" "pca953x invert pin 0|1\n" " - disable/enable polarity inversion for reads\n" - "pca953x intput pin\n" + "pca953x input pin\n" " - set pin as input and read value" ); -- 1.7.2.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] GPIO: pca953x: fix error reporting
Use the standard CMD_RET_* constants to clearly report errors from the
pca953x command. In addition, print error messages when I2C communication
fails.
Signed-off-by: Laurence Withers
---
drivers/gpio/pca953x.c | 49 ++-
1 files changed, 35 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/pca953x.c b/drivers/gpio/pca953x.c
index 64c7797..be13745 100644
--- a/drivers/gpio/pca953x.c
+++ b/drivers/gpio/pca953x.c
@@ -221,7 +221,7 @@ cmd_tbl_t cmd_pca953x[] = {
int do_pca953x(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
static uint8_t chip = CONFIG_SYS_I2C_PCA953X_ADDR;
- int val;
+ int ret = CMD_RET_USAGE, val;
ulong ul_arg2 = 0;
ulong ul_arg3 = 0;
cmd_tbl_t *c;
@@ -232,7 +232,7 @@ int do_pca953x(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
if (!c || !((argc == (c->maxargs)) ||
(((int)c->cmd == PCA953X_CMD_DEVICE) &&
(argc == (c->maxargs - 1) {
- return cmd_usage(cmdtp);
+ return CMD_RET_USAGE;
}
/* arg2 used as chip number or pin number */
@@ -246,32 +246,53 @@ int do_pca953x(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
switch ((int)c->cmd) {
#ifdef CONFIG_CMD_PCA953X_INFO
case PCA953X_CMD_INFO:
- return pca953x_info(chip);
+ ret = pca953x_info(chip);
+ if (ret)
+ ret = CMD_RET_FAILURE;
+ break;
#endif
+
case PCA953X_CMD_DEVICE:
if (argc == 3)
chip = (uint8_t)ul_arg2;
printf("Current device address: 0x%x\n", chip);
- return 0;
+ ret = CMD_RET_SUCCESS;
+ break;
+
case PCA953X_CMD_INPUT:
- pca953x_set_dir(chip, (1 << ul_arg2),
+ ret = pca953x_set_dir(chip, (1 << ul_arg2),
PCA953X_DIR_IN << ul_arg2);
val = (pca953x_get_val(chip) & (1 << ul_arg2)) != 0;
- printf("chip 0x%02x, pin 0x%lx = %d\n", chip, ul_arg2, val);
- return val;
+ if (ret)
+ ret = CMD_RET_FAILURE;
+ else
+ printf("chip 0x%02x, pin 0x%lx = %d\n", chip, ul_arg2,
+ val);
+ break;
+
case PCA953X_CMD_OUTPUT:
- pca953x_set_dir(chip, (1 << ul_arg2),
+ ret = pca953x_set_dir(chip, (1 << ul_arg2),
(PCA953X_DIR_OUT << ul_arg2));
- return pca953x_set_val(chip, (1 << ul_arg2),
- (ul_arg3 << ul_arg2));
+ if (!ret)
+ ret = pca953x_set_val(chip, (1 << ul_arg2),
+ (ul_arg3 << ul_arg2));
+ if (ret)
+ ret = CMD_RET_FAILURE;
+ break;
+
case PCA953X_CMD_INVERT:
- return pca953x_set_pol(chip, (1 << ul_arg2),
+ ret = pca953x_set_pol(chip, (1 << ul_arg2),
(ul_arg3 << ul_arg2));
- default:
- /* We should never get here */
- return 1;
+ if (ret)
+ ret = CMD_RET_FAILURE;
+ break;
}
+
+ if (ret == CMD_RET_FAILURE)
+ eprintf("Error talking to chip at 0x%x\n", chip);
+
+ return ret;
}
U_BOOT_CMD(
--
1.7.2.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC - PatchTrack Specification (revised)
Hi Wolfgang, On Wed, Jul 25, 2012 at 9:00 PM, Wolfgang Denk wrote: > Dear Andy, > > In message <004e01cd6a51$57d5ff70$0781fe50$@p...@sdcsystems.com> you wrote: >> >> I have been and had a look at the specification that you have posted and am >> happy to get my hands dirty helping with implement and test this. > > Thanks in advance. And a big thanks from me too :) Before we 'dig in' and implement it, we really need to make sure that the specification: a) Accurately describes something that will address the current problems we are experiencing in maintaining U-Boot b) Not, as far as we can currently tell, have scalability issues c) Be flexible enough to grow >> I know that a good proportion (possibly even all of it) could be implemented >> in Python but is there a preference or consensus on what would be the best >> language to do it in? > > Speaking for myself, I have no strict preferences. Me either > It may make a lot of sense to look into existing code - much of what > we neeed (mail processing, collecting follow-ups, Acks etc.) is > already availabe in PatchWork - can we re-use this code instead of > re-inventing the wheel? Exactly. As Patchwork is Python, it makes sense to keep going with Python for PatchTrack However, I was thinking that PatchTrack would have a modular design and implementation and that we should not restrict the language that the modules are written in. Although, this may come later. In particular, I can well imagine some of the 'static tests' being implemented as simple shell scripts Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Query on S3C2412
ccng'g to minkyu On 25 July 2012 17:07, Subash Patel wrote: > Hi Chander, > > Do you or Minku or someone in SLSI maintain mainline u-boot for old SoC's > like S3C24XX? > Your answer may be useful to Jose. > > Regards, > Subash > > > On 07/25/2012 04:42 PM, José Miguel Gonçalves wrote: >> >> Hi Subash, >> >> That board that I mentioned in the patch was a Silex SX-560: >> >> >> http://www.silexamerica.com/products/embedded_wireless/intelligent_modules/sx-560.html >> >> You can get the open-source code for it (including u-boot) from here: >> >> http://www.silexamerica.com/opensource/index.html >> >> BTW, I have now switched to this S3C2416 based board: >> >> http://www.armdesigner.com/MINI2416.html >> >> and I'm in the process of updating the u-boot code supplied (a 1.3.4 >> version patched by Samsung for the SMDK2416) to the latest u-boot source >> code. Do you know if Samsung (or someone else) provided a more recent u-boot >> for the SMDK2416 (or any other S3C2416 board)? >> >> Best regards, >> José Gonçalves >> >> >> On 07/25/2012 11:52 AM, Subash Patel wrote: >>> >>> Including even Ben who posted your patch. >>> >>> Regards, >>> Subash >>> >>> On 07/25/2012 04:20 PM, Subash Patel wrote: Hi Jose, I am from Samsung Electronics, SLSI and work in the open source project called Linaro. I find that you have posted a patch to fix booting s3c2412 based board recently, and hence assume that you are using that SoC. I am trying to cleanup some code for these old boards now. Unfortunately my inside- contacts in company do not have any u-boot for this SoC. Although we work on the SMDK boards internally, I will try to fix up u-boot which you may be using for the same. Can you help me to get u-boot, the one you use if publicly available? Regards, Subash >>> >>> >> > -- 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 - PatchTrack Specification (revised)
Dear Andy, In message <004e01cd6a51$57d5ff70$0781fe50$@p...@sdcsystems.com> you wrote: > > I have been and had a look at the specification that you have posted and am > happy to get my hands dirty helping with implement and test this. Thanks in advance. > I know that a good proportion (possibly even all of it) could be implemented > in Python but is there a preference or consensus on what would be the best > language to do it in? Speaking for myself, I have no strict preferences. It may make a lot of sense to look into existing code - much of what we neeed (mail processing, collecting follow-ups, Acks etc.) is already availabe in PatchWork - can we re-use this code instead of re-inventing the wheel? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC - PatchTrack Specification (revised)
Wolfgang wrote... > > A revised version of the spec (sorry, I would have used reply-to but > > something went amiss with gmail and I've lost the original) > > http://www.denx.de/wiki/U-Boot/ToolsPatchTracking updated. I have been and had a look at the specification that you have posted and am happy to get my hands dirty helping with implement and test this. I know that a good proportion (possibly even all of it) could be implemented in Python but is there a preference or consensus on what would be the best language to do it in? Regards, Andy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: Improve the speed of netconsole
On 24/07/2012 22:11, Joe Hershberger wrote: > Previously u-boot would initialize the network interface for every > network operation and then shut it down again. This makes sense for > most operations where the network in not known to be needed soon after > the operation is complete. In the case of netconsole, it will use the > network for every interaction with the shell or every printf. This > means that the network is being reinitialized very often. On many > devices, this intialization is very slow. Hi Joe, agree with you - and in some cases, such as ethernet on USB, netconsole is not yet useful. Which is the status of the ethernet controller before starting the kernel ? Up now we guarantee that the hardware is turned off before kernel takes over. This patch changes this behavior, and I know from the past (really with USB, we have a usb_stop before calling the kernel) that this can be dangerous. Maybe you can add a eth_halt() call into do_bootm(). Second general question is if the behavior of CONFIG_NETCONSOLE_PERSIST_ETH should be always turned on when Netconsole is activated. I mean, your patch maintain a high compatibility with the past, but I suppose that everyone using netconsole likes the new behavior that you are introducing and everyone will turn CONFIG_NETCONSOLE_PERSIST_ETH on. Then we can simply use CONFIG_NETCONSOLE as switch. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: fallback safely when a configuration descriptor is too large
Hi Vincent,
On Tue, Jul 24, 2012 at 6:12 PM, Vincent Palatin wrote:
> When a USB configuration descriptor was larger than our USB buffer
> (512 bytes), we were skipping the full descriptor reading but then we
> were still parsing and using it, triggering memory corruptions.
> Now in that case, it just skips this device enumeration and displays the
> appropriate message to the user, so he can fix the buffer if he wants.
>
> This bug was triggered by some UVC webcams which have very large
> configuration descriptors (e.g. a couple of kB) describing all their
> supported video encodings.
>
> Signed-off-by: Vincent Palatin
Acked-by: Simon Glass
> ---
> common/usb.c | 12 +---
> 1 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/common/usb.c b/common/usb.c
> index 63a11c8..cfa1ad7 100644
> --- a/common/usb.c
> +++ b/common/usb.c
> @@ -485,8 +485,8 @@ int usb_get_configuration_no(struct usb_device *dev,
> tmp = le16_to_cpu(config->wTotalLength);
>
> if (tmp > USB_BUFSIZ) {
> - USB_PRINTF("usb_get_configuration_no: failed to get " \
> - "descriptor - too long: %d\n", tmp);
> + printf("usb_get_configuration_no: failed to get " \
> + "descriptor - too long: %d\n", tmp);
Should this (and the one below) be USB_PRINTF() instead?
> return -1;
> }
>
> @@ -921,7 +921,13 @@ int usb_new_device(struct usb_device *dev)
> le16_to_cpus(&dev->descriptor.idProduct);
> le16_to_cpus(&dev->descriptor.bcdDevice);
> /* only support for one config for now */
> - usb_get_configuration_no(dev, &tmpbuf[0], 0);
> + err = usb_get_configuration_no(dev, &tmpbuf[0], 0);
> + if (err < 0) {
> + printf("usb_new_device: Cannot read configuration, " \
> + "skipping device %04x:%04x\n",
> + dev->descriptor.idVendor, dev->descriptor.idProduct);
> + return -1;
> + }
> usb_parse_config(dev, &tmpbuf[0], 0);
> usb_set_maxpacket(dev);
> /* we set the default configuration here */
> --
> 1.7.7.3
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
