Hello Heiko,
On 1 October 2013 11:35, Heiko Schocher wrote:
> Hello Naveen,
>
> Am 30.09.2013 12:03, schrieb Naveen Krishna Ch:
>
>> Helo Heiko,
>>
>> Thanks for timely reply.
>>
>> On 30 September 2013 13:35, Heiko Schocher wrote:
>>>
>>> Hello Naveen,
>>>
>>> Am 30.09.2013 08:58, schrieb Navee
Hello Tom,
please pull from u-boot-i2c.git
The following changes since commit 6b40852da5c8dd710f9d61204a3c6a3c9d22:
Sound: MAX98095: Support I2S0 channel (2013-09-24 09:10:33 -0400)
are available in the git repository at:
git://git.denx.de/u-boot-i2c.git master
for you to fetch chang
Hello Naveen,
Am 01.10.2013 08:19, schrieb Naveen Krishna Ch:
Hello Heiko,
On 1 October 2013 11:35, Heiko Schocher wrote:
Hello Naveen,
Am 30.09.2013 12:03, schrieb Naveen Krishna Ch:
Helo Heiko,
Thanks for timely reply.
On 30 September 2013 13:35, Heiko Schocher wrote:
Hello Naveen,
Hello Naveen,
Am 30.09.2013 12:03, schrieb Naveen Krishna Ch:
Helo Heiko,
Thanks for timely reply.
On 30 September 2013 13:35, Heiko Schocher wrote:
Hello Naveen,
Am 30.09.2013 08:58, schrieb Naveen Krishna Chatradhi:
This patchset fixes few bugs in the existing s3c24x0.c code (standard i
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-
> Dear pshambhu,
>
> In message <1380547665536-164381.p...@n7.nabble.com> you wrote:
> >
> > As per previous posting i got to know that, there will be only one reset
> > entry point, can't i have the another entry point in it.
>
> You can talk
On Mon, Sep 30, 2013 at 7:11 PM, Rob Herring wrote:
> From: Rob Herring
>
> The definitions for CONFIG_SYS_PROMPT are varied with little reason other
> than to display the board name. Over half the definitions are "==> ", so
> make this the default. The rest of the boards remain unchanged to avoi
On Mon, 2013-09-09 at 20:54 -0500, Scott Wood wrote:
> It seems the problem is that when rela is used, the linker *only* puts
> the symbol in the rela struct. The value in the data section itself is
> zero, which means we can't run without relocation even if the address
> hasn't changed.
>
> Unle
On Mon, Sep 30, 2013 at 7:04 PM, York Sun wrote:
>
> struct ccsr_ddr __iomem *ddr = (void *) CONFIG_FOO_ADDR;
> struct ccsr_ddr __iomem *ddr =
> (struct ccsr_ddr __iomem *) CONFIG_FOO_ADDR;
>
> You have told me the second format is preferred. I have been using this
> format since. But in p
Kim, et al.,
I know I have asked this before. Pardon me as I don't consider myself a
savy programmer.
I am cleaning up the DDR driver for mpc83xx, mpc85xx and mpc86xx. The
question is the accetable formats of declaring and initializing variable
at the same time. The variables are the ccsr registe
On Mon, 2013-09-30 at 12:44 +0300, Claudiu Manoil wrote:
> +static RTXBD rtx __aligned(8);
> +#define RXBD(i) rtx.rxbd[i]
> +#define TXBD(i) rtx.txbd[i]
> +#define GET_BD_STAT(T, i) be16_to_cpu((__force __be16)T##BD(i).status)
> +#define SET_BD_STAT(T, i, v) T##BD(i).status = (__force __u16)cpu_to_
From: Fabio Estevam
setup_wdog macro is not used anywhere, so just remove it.
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/armv7/mx5/lowlevel_init.S | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index
Thierry,
> -Original Message-
> From: Thierry Reding [mailto:thierry.red...@gmail.com]
> Sent: Monday, September 23, 2013 1:08 PM
> To: Tom Warren
> Cc: u-boot@lists.denx.de
> Subject: [PATCH v2 2/2] Tegra114: Do not program CPCON field for PLLX
>
> PLLX no longer has the CPCON field on T
Thierry,
> -Original Message-
> From: Thierry Reding [mailto:thierry.red...@gmail.com]
> Sent: Monday, September 23, 2013 2:53 AM
> To: Tom Warren
> Cc: u-boot@lists.denx.de
> Subject: [PATCH] Change maintainer for Avionic Design boards
>
> I no longer work for Avionic Design and don't ha
Dear pshambhu,
In message <1380547665536-164381.p...@n7.nabble.com> you wrote:
>
> As per previous posting i got to know that, there will be only one reset
> entry point, can't i have the another entry point in it.
You can talk to your chip vendor to provide you with some kind of
logic to detect
On 09/30/2013 08:55 PM, Jagan Teki wrote:
I think print is now required to be a function, so print(result). We
may need to adjust the code...
Does this print func chage with new python versions?
yes, since python 3 it needs brackets.
If we fix this, is it compatible for lower versions?
jero
On Tue, Oct 1, 2013 at 12:00 AM, Jeroen Hofstee wrote:
> On 09/30/2013 08:09 PM, Jagan Teki wrote:
>>
>> On Mon, Sep 30, 2013 at 11:12 PM, Simon Glass wrote:
>>>
>>> Hi Jagan,
>>>
>>> On Sat, Sep 28, 2013 at 11:29 AM, Jagan Teki
>>> wrote:
Can any one encounter this! looks like some is
TI81xx (TI816x, TI814x, TI813x) family of devices include in-built
GPMC and ELM hardware controllers which have the capability to support:
- x8 and x16 parallel NAND, NOR flash devices.
- generation and error detection of Hamming and BCH ECC schemes.
This patch enables support for detection and bo
ti814x_evm has on-board socket for using Micron (MT29Fxx) family of
NAND devices to GPMC interface. This patch
- adds NAND related pin-mux configuration for same
- adds #defines for NAND partitions to TI814x configs
- enables support for NAND in TI814x configs
Signed-off-by: Pekon Gupta
---
boar
Hi Stefan,
> From: Stefan Roese [mailto:s...@denx.de]
> > On 30.09.2013 16:13, Pekon Gupta wrote:
> > BCH8_ECC scheme implemented in omap_gpmc.c driver has following
> favours
> > +---+-+-+
> > |ECC Scheme | EC
On 09/30/2013 08:09 PM, Jagan Teki wrote:
On Mon, Sep 30, 2013 at 11:12 PM, Simon Glass wrote:
Hi Jagan,
On Sat, Sep 28, 2013 at 11:29 AM, Jagan Teki wrote:
Can any one encounter this! looks like some issue on python setup?
$ ./tools/buildman/buildman -b master
File "./tools/buildman/bui
beaglebone board can be connected to expansion boards to add devices to them.
These expansion boards are called 'capes'. This patch updates pin-mux for
'NAND' cape which can be used with beaglebone LT (white).
Further information and datasheets of this NAND cape can be found at:
- http://beagleboar
GPMC controller is common IP to interface with both NAND and NOR flash devices.
Also, it supports max 8 chip-selects, which can be independently connected to
any of the devices.
But ROM code expects the boot-device to be connected to only chip-select[0].
Thus to resolve conflict between NOR and NAN
From: Matthieu CASTET
This patch is modified version from following linux patch
http://lists.infradead.org/pipermail/linux-mtd/2012-November/044803.html
So retaining the authorship to Matthieu CASTET
*Modifications from original patch*
(1) use CONFIG_SYS_NAND_ONFI_DETECTION instead of (chip->op
NAND driver needs to know bus-width of the connected NAND device, in order to
perform proper I/O and initialize itself. Currently there is no CONFIG option
to provide this information to NAND driver.
- SPL NAND driver does not have framework to parse ONFI parameter page.
- NAND drivers which cannot
*changes in v2*
[PATCH 1/4]:
- dropped NAND_BUSWIDTH_AUTO, instead using
CONFIG_SYS_NAND_ONFI_DETECTION
- added check in nand_flash_detect_onfi() for x8 mode
[PATCH 2/4]: (new) Adds CONFIG_SYS_NAND_DEVICE_WIDTH
- updated for auto-detection of bus-width in non-SPL and ONFI_
On Mon, Sep 30, 2013 at 11:12 PM, Simon Glass wrote:
> Hi Jagan,
>
> On Sat, Sep 28, 2013 at 11:29 AM, Jagan Teki wrote:
>> Can any one encounter this! looks like some issue on python setup?
>>
>> $ ./tools/buildman/buildman -b master
>> File "./tools/buildman/buildman", line 42
>> print re
Hi Stefan,
> From: Stefan Roese [mailto:s...@denx.de]
> > On 30.09.2013 16:13, Pekon Gupta wrote:
> > BCH8_ECC scheme implemented in omap_gpmc.c driver has following
> favours
> > +---+-+-+
> > |ECC Scheme | EC
Hi all,
has anyone made such a port in the path that is now readily available for
reuse?
I wished to have it running as the second stage boot loader, but it is not
yet available I might need to fall back to the TI UBL.
I would be happier to use SPL, but I would not probably have the required
tim
Hi Jagan,
On Sat, Sep 28, 2013 at 11:29 AM, Jagan Teki wrote:
> Can any one encounter this! looks like some issue on python setup?
>
> $ ./tools/buildman/buildman -b master
> File "./tools/buildman/buildman", line 42
> print result
>^
> SyntaxError: invalid syntax
>
> Let me
Enable L2 cache for improving the system performance.
Signed-off-by: Fabio Estevam
---
arch/arm/cpu/armv7/mx5/lowlevel_init.S | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/mx5/lowlevel_init.S
b/arch/arm/cpu/armv7/mx5/lowlevel_init.S
index fc7c767..e4cd85c 100644
-
On 09/29/2013 08:47 PM, Jain Priyanka-B32167 wrote:
> Thanks York,
>
> Please update Maintainers name from "Naveen Burmi
> " to "Poonam Aggrwal
> " in boards.cfg file.
>
Please include this change in next patch you will submit for T1040QDS.
York
___
Hi Pekon,
On 30.09.2013 16:13, Pekon Gupta wrote:
> BCH8_ECC scheme implemented in omap_gpmc.c driver has following favours
> +---+-+-+
> |ECC Scheme | ECC Calculation | Error Detection |
> +---
NAND boot mode on AM335x EVM has been verified, and steps
to use it has been documented and update in this README
Signed-off-by: Pekon Gupta
Acked-by: Peter Korsgaard
Acked-by: Tom Rini
---
board/ti/am335x/README | 53 ++
1 file changed, 36 inser
chip->ecc.correct() is used for detecting and correcting bit-flips during read
operations. In omap-nand driver it implemented as:
(a) omap_correct_data(): for h/w based ECC_HAM1 scheme
(b) omap_correct_data_bch() + CONFIG_NAND_OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
for ECC_BCH8 scheme using GPM
chip->ecc.hwctl() is used for preparing the H/W controller before read/write
NAND accesses (like assigning data-buf, enabling ECC scheme configs, etc.)
Though all ECC schemes in OMAP NAND driver use GPMC controller for generating
ECC syndrome (for both Read/Write accesses). But but in current code
BCH8_ECC scheme implemented in omap_gpmc.c driver has following favours
+---+-+-+
|ECC Scheme | ECC Calculation | Error Detection |
+---+-+-+
|OMAP
*changes in v7*
[PATCH 1/5]
- omap_gpmc.c: fix: free bytes in OOB (ecclayout->oobfree[0].length)
- omap_gpmc.c: cleanup: redundant code added in previous patch versions
- am335x_evm.h: cleanup: redundant code added in previous patch versions
- tricorder.h: fix: CONFI
chip->ecc.calculate() is used for calculating and fetching of ECC syndrome by
processing the data passed during Read/Write accesses.
All H/W based ECC schemes use GPMC controller to calculate ECC syndrome.
But each BCHx_ECC scheme has its own implemetation of post-processing and
fetching ECC syndr
Hi,
I am a new-bee for the u-boot environment, and i am trying to
implement/customize the u-boot code for Dual boot loading from the flash.
U-boot1 will be the primary Image and U-boot2 will be the Fallback image /
backup image. For any situation if my primary image gets corrupted while
upda
Add initial Colibri VF50 support based off Freescale's implementation
for the Vybrid Tower System TWR-VF65GS10:
- New machine ID.
- Default UART_A on SCI0.
- FEC1 only.
- Enabled command line editing.
- PLL5 based RMII clocking (e.g. no external crystal).
- UART_A and UART_C I/O muxing.
Tested on
Add UART0 aka SCI0 TX/RX iomux definitions.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/arch/arm/include/asm/arch-vf610/iomux-vf610.h
index e315fe4..a6f7
From: Marcel Ziswiler
Add secondary RMII1 iomux definitions now with correct mux_ctrl_ofs as
well.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h |9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-vf610.h
b/a
Get rid of double VF610_PAD_DDR_A15__DDR_A_15 iomux configuration.
Signed-off-by: Marcel Ziswiler
---
board/freescale/vf610twr/vf610twr.c |1 -
1 file changed, 1 deletion(-)
diff --git a/board/freescale/vf610twr/vf610twr.c
b/board/freescale/vf610twr/vf610twr.c
index 699ea7f..4ee74c0 100644
Get rid of obsolete CONFIG_SYS_UART_PORT configuration option.
Signed-off-by: Marcel Ziswiler
---
include/configs/vf610twr.h |1 -
1 file changed, 1 deletion(-)
diff --git a/include/configs/vf610twr.h b/include/configs/vf610twr.h
index 5a7a066..432a69d 100644
--- a/include/configs/vf610twr.
Add ANADIG PLL5 control definitions required for Ethernet RMII clock
configuration.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/crm_regs.h |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf6
Add VF610_PAD_PTA6__RMII0_CLKOUT iomux definition eventually required
for internal (e.g. crystal-less) Ethernet clocking.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/iomux-vf610.h |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/arch-vf610/iomux-
From: Marcel Ziswiler
Rename all the reserved fields using a memory offset based scheme.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/crm_regs.h | 54 ++--
1 file changed, 27 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/arch-
Add secondary Ethernet MAC RMII1 base address definition in preparation
of potential secondary only board configurations.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/imx-regs.h |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/arch-vf610/imx-regs.
The anadig_reg structure started at the wrong offset (fixed by adding
resvA[4]), was missing some reserved field required for alignment
purpose (resvB[3] between pll4_denom and pll6_ctrl) and further
contained too short a reserved field causing further miss-alignment
(resv10[7]).
Discovered and te
This patch series addresses several fixes and enhancements for the
vybrid tower.
Tested on a TWR-VF65GS10 Rev G.
Changes v2:
- Memory offset based reserved ANADIG field naming scheme.
- Fixed mux_ctrl_ofs in secondary RMII1 iomux definitions.
Marcel Ziswiler (10):
arm: vf610: fix anadig regist
Add CCM_CCGR0_UART0_CTRL_MASK clock definition for UART0 aka SCI0.
Signed-off-by: Marcel Ziswiler
---
arch/arm/include/asm/arch-vf610/crm_regs.h |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/arch-vf610/crm_regs.h
b/arch/arm/include/asm/arch-vf610/crm_regs.h
index 2
Hi Fabio,
On Monday, September 30, 2013 3:32:39 AM, Fabio Estevam wrote:
> On Sun, Sep 29, 2013 at 7:24 PM, Otavio Salvador
> wrote:
>
> > I sent the patch to fix this adding the flag to the GPIO pins.
> >
> > I tested it and it works fine indeed. The patch is awaiting for
> > approval as it is
Add callbacks to set up DP-HPD, backlight and LCD power
on SMDK5420.
Signed-off-by: Ajay Kumar
---
board/samsung/smdk5420/smdk5420.c | 118 +++---
1 file changed, 34 insertions(+), 84 deletions(-)
diff --git a/board/samsung/smdk5420/smdk5420.c
b/board/samsung/sm
On Exynos5420, the FIMD sysmmus are in "on state" by default.
We have to disable them in order to make FIMD DMA work.
This patch adds the required framework to exynos_fimd driver
to disable FIMD sysmmu on Exynos5420.
Signed-off-by: Ajay Kumar
---
arch/arm/dts/exynos5420.dtsi | 5
RPLL is needed to drive the LCD panel on Exynos5420 based boards.
Signed-off-by: Ajay Kumar
---
arch/arm/cpu/armv7/exynos/clock_init.h | 3 +++
arch/arm/cpu/armv7/exynos/clock_init_exynos5.c | 13 +
2 files changed, 16 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/cl
Enable FIMD and DP drivers on SMDK5420 so that we get to
see the LCD console on eDP panel.
Signed-off-by: Ajay Kumar
---
include/configs/smdk5420.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h
index 447f8e5..cc9c424 100644
--
Add get_lcd_clk and set_lcd_clk callbacks for Exynos5420 needed by
exynos video driver.
Also, configure ACLK_400_DISP1 as the parent for MUX_ACLK_400_DISP1_SUB_SEL.
Signed-off-by: Ajay Kumar
---
arch/arm/cpu/armv7/exynos/clock.c | 74 +--
arch/arm/cpu/armv7/ex
This patchset adds support for FIMD and DP on SMDK5420.
This patchset has dependency on Rajeshwari's base patchset:
[V4] EXYNOS5420: Add SMDK5420 board support
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/170582
Also, for testing we need Naveen's i2c patchset aswell:
i2c: improve s3c2
Previously, we used to statically assign values for vl_col, vl_row and
vl_bpix using #defines like LCD_XRES, LCD_YRES and LCD_COLOR16.
Introducing the function exynos_lcd_early_init() would take care of this
assignment on the fly by parsing FIMD DT properties, thereby allowing us
to remove LCD_XRE
Currently the driver clears WCR_SRS bit when enabling
the watchdog and this causes a software reset. Do not
clear WCR_SRS.
Signed-off-by: Anatolij Gustschin
---
drivers/watchdog/imx_watchdog.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/watchdog/imx_watchdog.
Hi Stefano,
On Mon, 30 Sep 2013 07:41:46 +0200
Stefano Babic wrote:
...
> Can you resend the patch in the usual way to ML for including into
> mainline ?
yes, I can resend it.
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lis
Helo Heiko,
Thanks for timely reply.
On 30 September 2013 13:35, Heiko Schocher wrote:
> Hello Naveen,
>
> Am 30.09.2013 08:58, schrieb Naveen Krishna Chatradhi:
>
>> This patchset fixes few bugs in the existing s3c24x0.c code (standard i2c)
>> and add support for High-speed i2c bus controller a
There are several implementation issues for tsec_mcast_addr()
addressed by this patch:
* unmanaged, not portable r/w access to registers; fixed with
setbits_be32()/ clrbits_be32()
* use of volatile pointers
* unnecessary forced cast to u8 for the ether_crc() result
* removed redundant parens
* corr
Fix bufPtr and the rxIdx/ txIdx occurrences to
solve the related checkpatch warnings for the
coming patches.
Signed-off-by: Claudiu Manoil
---
drivers/net/tsec.c | 60 +++---
include/tsec.h | 4 ++--
2 files changed, 32 insertions(+), 32 delet
Currently, the buffer descriptor (BD) fields cannot be
correctly accessed by a little endian processor. This
patch fixes the issue by making the access of BDs to be
portable among different cpu architectures.
Use portable data types for the Rx/Tx buffer descriptor
fields. Add macro accessors to
Fix the 32-bit memory access that is not "endianess safe",
i.e. not giving the desired byte layout for LE cpus:
tempval = *((uint *) (tmpbuf + 4)), where 'char tmpbuf[]'.
Free the stack from rendundant local vars:
tmpbuf[] and i.
Use a portable type (u32) for the 32bit tsec register value
holder:
Use cross arch portable u32 instead of uint for the
tsec registers. Remove the typedefs for the register
struct definitions in the process. Fix long lines.
Signed-off-by: Claudiu Manoil
---
drivers/net/tsec.c | 2 +-
include/tsec.h | 278 ++
Remove tsec_t typedef. Define macros as getters of
tsec and mdio register memory regions, for consistent
initialization of various 'regs' fields and also to
manage overly long initialization lines.
Use the __iomem address space marker to address sparse
warnings in tsec.c where IO accessors are use
Though the first 3 patches fix tsec's driver mcast() instance primarily,
the fix from net.h was propagated to other drivers too, as appropriate.
Notably, these fixes also end up in removal of some unwanted global
static vars from the tsec driver.
The rest of the patches are driver portability fixes
Add the __iomem address space marker for the tsec pointers
to struct tsec_mii_mng memory mapped register regions.
This solves the sparse warnings for mixig normal pointers with
__iomem pointers for tsec. E.g.:
fsl_mdio.c:34:19: warning: incorrect type in argument 1 (different
address spaces)
fsl_m
Access to privlist[1] (hardcoded referece to the 2nd tsec's
priv area) is neither correct nor does it make sense in the
current context. Each tsec dev has access to its own priv
instance only, and hence to its own set of group address
registers (GADDR) to filter multicast addresses.
This fix lead
This fixes the following compiler warnings when activating
CONFIG_MCAST_TFTP:
tsec.c: In function 'tsec_mcast_addr':
tsec.c:130:2: warning: passing argument 2 of 'ether_crc' makes pointer
from integer without a cast [enabled by default]
In file included from /work/u-boot-net/include/common.h:874:0
Hi,
Has anyone looked at a way of implementing get_timer for PowerPC without
using interrupts.
We appear to be having a problem with common/usb_hub.c where
occasionally (1 in ~150 reboots) we seem to get stuck in the do/while
loop in usb_hub_configure. It looks like this should timeout but becaus
Hello Stephen
> > This patch moves Tegra specific directory entries
> > from the toplevel Makefile and spl/Makefile
> > to arch/arm/cpu/*/Makefile using Kbuild descending feature.
>
> That sounds more like a "move" than a "delete", so the patch subject
> sounds misleading...
You are right.
I pos
ping!
On 09/16/13 21:49, Igor Grinberg wrote:
> Two more adjustments before porting more Compulab boards to mainline U-Boot.
> Move the eeprom code which can be used (and is suitable) by multiple Compulab
> boards to a common location.
> Move the display initialization code which can be used by mu
On 09/22/2013 07:56 AM, Wang Huan-B18965 wrote:
-Original Message-
From: Marcel Ziswiler [mailto:mar...@ziswiler.com]
Sent: Tuesday, September 17, 2013 6:45 PM
To: u-boot@lists.denx.de
Cc: Wang Huan-B18965; Marcel Ziswiler
Subject: [PATCH 08/10] arm: vf610: add rmii1 iomux definitions
Ad
This patch tweaks scripts/Makefile.build to allow
the build system to descend into subdirectories like Kbuild.
To use this feature, use "obj-y += foo/" syntax.
Example:
obj-$(CONFIG_FOO) += foo/
Signed-off-by: Masahiro Yamada
Cc: Simon Glass
---
Changes for v3:
- No change
Changes for
This commit moves some drivers subdirectory entry
from the toplevel Makefile to drivers/Makefile
using Kbuild descending feature.
Signed-off-by: Masahiro Yamada
---
Changes for v3:
- No change
Changes for v2:
- refactor also drivers/pcmcia and drivers/rtc
Makefile |
This commit moves some subdirectories of fs
from the toplevel Makefile to fs/Makefile
using Kbuild descending feature.
Signed-off-by: Masahiro Yamada
---
Changes for v3:
- No change
Changes for v2:
- No change
Makefile| 12 +---
fs/Makefile | 11 +++
2 files changed,
This patch moves S5PC, EXYNOS specific directory entries
from the toplevel Makefile to arch/arm/cpu/armv7/Makefile
using Kbuild descending feature.
Signed-off-by: Masahiro Yamada
Cc: Minkyu Kang
---
Changes for v3:
- Fix misleading commit subject (No change in body)
Changes for v2:
- No ch
Note:
Update for v3 is the only patch subjects.
The patch body is the same as v2.
I have been just wondering why the U-Boot top Makefile is so dirty.
It is sprinkled with SoC-specific code as follows:
ifneq ($(CONFIG_OMAP_COMMON),)
LIBS-y += $(CPUDIR)/omap-common/libomap-common.o
This patch moves OMAP specific directory entries
from the toplevel Makefile and spl/Makefile
to arch/arm/cpu/armv7/Makefile using Kbuild descending feature.
Signed-off-by: Masahiro Yamada
Cc: Tom Rini
---
Changes for v3:
- Fix misleading commit subject (No change in body)
Changes for v2:
-
This patch moves Tegra specific directory entries
from the toplevel Makefile and spl/Makefile
to arch/arm/cpu/*/Makefile using Kbuild descending feature.
Signed-off-by: Masahiro Yamada
Cc: Tom Warren
---
Changes for v3:
- Fix misleading commit subject (No change in body)
Changes for v2:
-
On 09/17/2013 03:27 PM, Otavio Salvador wrote:
I agree with the way to fix it but it is a little bit hard to get it
is a 'reserved'; we used reserved_ to make it more explicit.
Take a look at
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mxs/regs-power-mx28.h;h=9528e3ce9ad
Hello Naveen,
Am 30.09.2013 08:58, schrieb Naveen Krishna Chatradhi:
This patchset fixes few bugs in the existing s3c24x0.c code (standard i2c)
and add support for High-speed i2c bus controller available on Exynos5 SoCs
from Samsung.
Exynos5250 channels [0 ~ 3] can configured for I2C contoller
Hello Jeroen,
> diff --git a/config.mk b/config.mk
> index 48913f6..177f685 100644
> --- a/config.mk
> +++ b/config.mk
> @@ -117,7 +117,7 @@ CC_TEST_OFILE :=
> $(OBJTREE)/include/generated/cc_test_file.o
> -include $(CC_OPTIONS_CACHE_FILE)
>
> cc-option-sys = $(shell mkdir -p $(dir $(CC_TEST
Am 13.09.2013 19:28, schrieb Michael Trimarchi:
> Hi
> I don't understand you can decrypt it after load. Why just verify the
> signature?
>
> Michael
>
This is a proof-of-concept for a technique, which involves
de-/encrypting the u-boot.img with a key derived from a hardware
fingerprint. This is
Hi Albert,
so if I get you right the workflow for payload authentication is the
following:
Encryption process:
1. Create hash value H for u-boot.img
2. Encrypt the hash value H with secret K to get encrypted hash values H_enc
3. Store H_enc
Decryption process:
1. Read H_enc
2. Decrypt H_enc us
From: Lars Poeschel
Since 2bf36ac638ab2db9f0295aa47064976eeebf80c1 the BD ram address is
not hardcoded inside cpsw driver any more. Platforms have to supply
their bd_ram_ofs in the platform data to the driver. This commit does
this for pcm051 and igep0033 boards.
Tested-by: Enric Balletbo i Serr
From: Lars Poeschel
I compiled and tried v2013.10-rc2 on pcm051 and it fails booting over
tftp. I could bisect 2bf36ac638ab2db9f0295aa47064976eeebf80c1 as the
cause of the problem. It moves bd_ram_ofs from the cpsw driver to the
board files. Adding the bd_ram_ofs to the board file of pcm051 fixes
From: Simon Glass
At present the i2c ports are enumerated in a strange way - the
fdtdec_find_aliases_for_id() function is used, but then the ID returned
is ignored and the ports are renumbered. The effect is the same provided
that the device tree has the ports in the same order, or uses aliases,
Add support for hsi2c controller available on exynos5420.
Note: driver currently supports only fast speed mode 100kbps
Change-Id: I02555b1dc8f4ac21c50aa5158179768563c92f43
Signed-off-by: Naveen Krishna Chatradhi
Signed-off-by: R. Chandrasekar
---
drivers/i2c/s3c24x0_i2c.c | 612 ++
The Exynos5 i2c driver does not handle NACKs properly. This change:
- fixes the NACK processing problem (do not continue transaction if
address cycle was NACKed)
- eliminates a fair amount of duplicate code
Signed-off-by: Vadim Bendebury
Reviewed-by: Simon Glass
Signed-off-by: Naveen Krishna
This enables CONFIG_SYS_I2C on Samsung, updating existing s3c24x0
i2c driver to support this.
Note: Not for merge, Just for review and suggestions.
Signed-off-by: Naveen Krishna Chatradhi
---
drivers/i2c/Makefile |2 +-
drivers/i2c/s3c24x0_i2c.c | 156 +++--
This patchset fixes few bugs in the existing s3c24x0.c code (standard i2c)
and add support for High-speed i2c bus controller available on Exynos5 SoCs
from Samsung.
Exynos5250 channels [0 ~ 3] can configured for I2C contoller or
new HSI2C controller
channels [3 ~ 7] are stand
95 matches
Mail list logo
