There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEP COM AQUILA use an AM3352/AM3354 processor is
better to rename its board config to use this nami
There seems to be a naming convention for the configuration
files for boards using the same SoC family. This makes
easier to do changes that affect different boards based
on the same SoC.
Since the IGEP COM AQUILA use an AM3352/AM3354 processor is
better to rename its board config to use this nami
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/28/2013 02:19 AM, Masahiro Yamada wrote:
> Hello, Tom.
>
> I noticed this patch does not apply to the current u-boot/master
> because commit 3aa29de0 modified the same part.
> (BTW, I think CONFIG_TPL_PAD_TO is not necessary either and should be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/30/2013 12:50 AM, Sricharan R wrote:
> Hi Tom,
>
> On Friday 23 August 2013 09:56 PM, Tom Rini wrote:
>> Test on Beaglebone white over cpsw, usb ether and SD card (read and
>> write), performance increased, crc32 of data matches.
>>
>> Signed-of
On Fri, Aug 30, 2013 at 04:28:41PM -0400, Tom Rini wrote:
> We may need to access the PMIC code in SPL, when we have power set.
>
> Signed-off-by: Tom Rini
Bah, forgot to pass --subject-prefix 'PATCH v4' to the whole series...
--
Tom
signature.asc
Description: Digital signature
___
On Fri, Aug 30, 2013 at 05:07:17PM -0400, Tom Rini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/30/2013 12:50 AM, Sricharan R wrote:
> > Hi Tom,
> >
> > On Friday 23 August 2013 09:56 PM, Tom Rini wrote:
> >> Test on Beaglebone white over cpsw, usb ether and SD card (read a
Add a am33xx_spl_board_init (and enable the PMICs) that we may see,
depending on the board we are running on. In all cases, we see if we
can rely on the efuse_sma register to tell us the maximum speed. In the
case of Beaglebone White, we need to make sure we are on AC power, and
are on later than
From: Greg Guyotte
Add a driver for the TPS65217 PMIC that is found in the Beaglebone
family of boards.
Signed-off-by: Greg Guyotte
[trini: Split and rework Greg's changes into new drivers/power
framework]
Signed-off-by: Tom Rini
---
Changes in v4:
- Use enum for registers
Changes in v2:
- A
From: "Philip, Avinash"
Add a driver for the TPS65910 PMIC that is found in the AM335x GP EVM,
AM335x EVM SK and others.
Signed-off-by: Philip, Avinash
[trini: Split and rework Avinash's changes into new drivers/power
framework]
Signed-off-by: Tom Rini
---
Changes in v4:
- Use enum for regist
Starting with PG2.1 we have a register in the CONTROL_MODULE that is set
with the package type and maximum supported frequency. Add this, and
the relevant mask/values.
Signed-off-by: Tom Rini
---
arch/arm/include/asm/arch-am33xx/cpu.h | 12
1 file changed, 12 insertions(+)
diff
We may need to access the PMIC code in SPL, when we have power set.
Signed-off-by: Tom Rini
---
spl/Makefile |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/spl/Makefile b/spl/Makefile
index 339e5e8..65615cb 100644
--- a/spl/Makefile
+++ b/spl/Makefile
@@ -87,7 +87,8 @@
We need to allow for a further call-out in spl_board_init. Call this
am33xx_spl_board_init and add a __weak version. This function may be
used to scale the MPU frequency up, depending on board needs.
Signed-off-by: Tom Rini
---
Changes in v2:
- Move am33xx_spl_board_init to am33xx/board.c from
On Fri, Aug 30, 2013 at 06:44:48AM +0200, Heiko Schocher wrote:
> Hello Tom,
>
> Am 29.08.2013 16:05, schrieb Tom Rini:
> >On Mon, Aug 19, 2013 at 04:48:04PM +0200, Heiko Schocher wrote:
> >
> >>- add omap24xx driver to new multibus/multiadpater support
> >>- adapted all config files, which uses t
On Fri, Aug 30, 2013 at 10:00 AM, Simon Glass wrote:
> Correct the following warnings found with sandbox when compression
> is enabled.
>
> cmd_bootm.c: In function 'bootm_load_os':
> cmd_bootm.c:443:11: warning: passing argument 4 of 'lzop_decompress' from
> incompatible pointer type [enabled by
On 23 August 2013 04:23, Marek Vasut 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 DA
Correct the following warnings found with sandbox when compression
is enabled.
cmd_bootm.c: In function 'bootm_load_os':
cmd_bootm.c:443:11: warning: passing argument 4 of 'lzop_decompress' from
incompatible pointer type [enabled by default]
/usr/local/google/c/cosarm/src/third_party/u-boot/files
Hi Tapani,
On 30/08/2013 07:07, Tapani Utriainen wrote:
>
> Stefano,
>
> Thank you for reviewing this patch, and for the constructive comments.
> Most of your comments are taken on board, and we will re-submit updated
> patches
> in the near future.
>
> On some things we probably need some
On Fri, Aug 30, 2013 at 5:07 AM, Shengzhou Liu
wrote:
> #ifdef CONFIG_SYS_I2C_EEPROM_NXID
> +/* some boards with non-256-bytes EEPROM have special define */
> +/* for MAX_NUM_PORTS in board-specific file */
> +#ifndef MAX_NUM_PORTS
> #define MAX_NUM_PORTS 23
> +#endif
> #define NXID_VERSION
Hi Tapani,
On 08/29/2013 10:07 PM, Tapani Utriainen wrote:
Stefano,
Thank you for reviewing this patch, and for the constructive comments.
Most of your comments are taken on board, and we will re-submit updated patches
in the near future.
On some things we probably need some clarification, se
On Mon, Jul 6, 2009 at 10:11 AM, Kumar Gala wrote:
>
> #ifdef CONFIG_SYS_I2C_EEPROM_NXID
> /* Is this a valid NXID EEPROM? */
> -#define is_valid (*((u32 *)e.id) == (('N' << 24) | ('X' << 16) | ('I' << 8)
> | 'D'))
> +#define is_valid ((e.id[0] == 'N') || (e.id[1] == 'X') || \
> +
On 08/30/2013 06:04 AM, Liu Shengzhou-B36685 wrote:
>> Actually, the 23 should be changed to 31. York, this patch needs to be
>> applied: http://patchwork.ozlabs.org/patch/170753/
>
> According to AN3638, it should be 30 rather than 31 for 256-bytes EEPROM.
Are you talking about the C struct?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/30/2013 12:44 AM, Heiko Schocher wrote:
> Hello Tom,
>
> Am 29.08.2013 16:05, schrieb Tom Rini:
>> On Mon, Aug 19, 2013 at 04:48:04PM +0200, Heiko Schocher wrote:
>>
>>> - add omap24xx driver to new multibus/multiadpater support
>>> - adapted al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/30/2013 12:48 AM, Heiko Schocher wrote:
> - add omap24xx driver to new multibus/multiadpater support
> - adapted all config files, which uses this driver
>
> Tested on the am335x based siemens boards rut, dxr2 and pxm2
> posted here:
> http://pa
Some boards use System EEPROM with 128-bytes instead of 256-bytes.
Since we regard 256-bytes EEPROM as standard EEPROM with default
value for MAX_NUM_PORTS. For those non-256-bytes EEPROM, we can
redefine MAX_NUM_PORTS in board-specific file to override the
default MAX_NUM_PORTS.
This patch doesn'
> -Original Message-
> From: Timur Tabi [mailto:ti...@tabi.org]
> Sent: Thursday, August 29, 2013 11:09 PM
> To: Liu Shengzhou-B36685
> Cc: U-Boot Mailing List; sun york-R58495
> Subject: Re: [U-Boot] [PATCH] powerpc/eeprom: update MAX_NUM_PORTS to fix
> program failure
>
> Actually, the
beaglebone board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch adds support for using
'NAND' cape (expansion board) with Beaglebone white/
http://beagleboardtoys.info/index.php?title=BeagleBone_Memory_Expansion
http://beagleboardt
- add omap24xx driver to new multibus/multiadpater support
- adapted all config files, which uses this driver
Tested on the am335x based siemens boards rut, dxr2 and pxm2
posted here:
http://patchwork.ozlabs.org/patch/263211/
Signed-off-by: Heiko Schocher
Cc: Tom Rini
Cc: Lars Poeschel
Cc: Ste
27 matches
Mail list logo
