Hello Wolfgang
> In message <1384830117-25345-1-git-send-email-yamad...@jp.panasonic.com> you
> wrote:
> > Before this commit, common/cmd_test.c defined
> > _STDBOOL_H in order to avoid including .
> > But this work-around is not a good idea.
>
> Actually it is a good idea, as it attempts to be
You need to code a serial driver protocol. At pc end .you using putty
在 2013-11-19 PM3:13，"tvpatel12" 写道：
> Hi,
> I am working with Uboot only. there is no any kernel or OS. I am running
> program only dependent on U-boot. It stores result in RAM. Now, i want to
> transfer that data to my host mac
Hi,
I am working with Uboot only. there is no any kernel or OS. I am running
program only dependent on U-boot. It stores result in RAM. Now, i want to
transfer that data to my host machine. My development board is connected to
host PC via serial console.
Pleas help...
--
View this message in con
Dear Heiko,
In message <528ae93d.2080...@denx.de> you wrote:
>
> - Maybe a cmdline interface to change the state of a patch, so I do not
>need to open a webbrowser (not necessary, would just nice ;-)
This can be done using existing tools. "pwclient update" can be used
to update the status.
Dear Masahiro Yamada,
In message <1384834977-10536-1-git-send-email-yamad...@jp.panasonic.com> you
wrote:
> Before this commit, U-Boot included
> in order to define bool, true and false.
...
> This commit changes header files to define bool, true and false
> in the same way as Linux Kernel does.
Dear Masahiro Yamada,
In message <1384830117-25345-1-git-send-email-yamad...@jp.panasonic.com> you
wrote:
> Before this commit, common/cmd_test.c defined
> _STDBOOL_H in order to avoid including .
> But this work-around is not a good idea.
Actually it is a good idea, as it attempts to be indepen
Hi Masahiro Yamada,
On Tue, Nov 19, 2013 at 4:59 PM, Masahiro Yamada
wrote:
> Hello Graeme
>
>
> > Why would hacking /include/linux/stddef.h and /include/linux/types.h be
> > preferable?
>
> The reason is this:
> > > Personally, I prefer (2) to (1) because
> > > - we don't need to tweak common
Ping..
On 19 October 2013 12:19, Inderpal Singh wrote:
> From: Chander Kashyap
>
> Arndale board has AX88760, which is USB 2.0 Hub & USB 2.0 Ethernet Combo
> controller, connected to HSIC Phy of USB host controller via USB3503 hub.
>
> This patchset add support for this usb ethernet controllor.
Hello Graeme
> Why would hacking /include/linux/stddef.h and /include/linux/types.h be
> preferable?
The reason is this:
> > Personally, I prefer (2) to (1) because
> > - we don't need to tweak common/cmd_test.c any more
> > - we can reduce the conflict if we have a plan to update
> >
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
OMAP NAND drivers support various ecc-schemes like (HAM1, BCH4, BCH8..)
And, each ecc-scheme usually has 2 implementations
- HAM1_HW or BCHx_HW (using in-build h/w engine for all computation)
- HAM1_SW or BCHx_HW_DETECTION_SW) (using software library for some
computation)
This patch series is
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
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 Masahiro Yamada,
Why would hacking /include/linux/stddef.h and /include/linux/types.h be
preferable?
Regards,
Graeme
On Tue, Nov 19, 2013 at 3:37 PM, Masahiro Yamada
wrote:
> Hi.
>
> I posted v2 of this patch
> http://patchwork.ozlabs.org/patch/292258/
>
>
> I think both of two solutions w
Hello Aaron,
Am 19.11.2013 05:18, schrieb Aaron Williams:
Hi all,
On one of our new boards we have both a SPI (M9256-W) and I2C (24lc256) EEPROM.
I have run into a couple of issues. First of all, it looks like the eeprom
command can only handle one EEPROM device. It would be useful if multipl
Hi.
I posted v2 of this patch
http://patchwork.ozlabs.org/patch/292258/
I think both of two solutions work.
(1) include in common/cmd_test.c
but undef true and false.
http://patchwork.ozlabs.org/patch/292247/
(2) Do not include and
define true and false with enum.
h
Hi Stefano
On Mon, Nov 18, 2013 at 1:51 PM, Stefano Babic wrote:
> Hi Giuseppe,
>
> On 15/11/2013 17:42, Giuseppe Pagano wrote:
>> Add Ethernet and networking support on uDoo board (FEC +phy Micrel KSZ9031).
>> Ethernet speed is currently limited to 10/100Mbps.
>>
>> Signed-off-by: Giuseppe Pagan
Hello Tom,
Am 18.11.2013 17:00, schrieb Tom Rini:
On Mon, Nov 18, 2013 at 11:07:59AM +1100, Graeme Russ wrote:
Hi All,
You do all realise that we are going about this, to use some British
vernacular, arse-about-tit
Everyone agrees that the current U-Boot review workflow 'has issues' (and
has
Never mind about the multiple devices, it looks like that is supported.
My problem is still that only either I2C or SPI are supported and not both.
-Aaron
On 11/18/2013 08:18 PM, Aaron Williams wrote:
Hi all,
On one of our new boards we have both a SPI (M9256-W) and I2C
(24lc256) EEPROM. I h
Before this commit, U-Boot included
in order to define bool, true and false.
The header of gcc generally defines
them as macros as follows:
#define bool_Bool
#define true1
#define false 0
But this gave a bad imapct on common/cmd_test.c,
which implements "true" and "false" comma
Hi all,
On one of our new boards we have both a SPI (M9256-W) and I2C (24lc256)
EEPROM. I have run into a couple of issues. First of all, it looks like
the eeprom command can only handle one EEPROM device. It would be useful
if multiple devices could be supported.
Another issue I ran into is
Hi Stefano,
On 11/18/2013 03:57 AM, Stefano Babic wrote:
Hi Eric,
On 17/11/2013 18:17, Eric Nelson wrote:
Since the nitrogen6x board file auto-detects Nitrogen6x and
SABRE Lite boards, override set_board_name to produce one
of two values for board_name.
Signed-off-by: Eric Nelson
---
board
Hi Stefano,
On 11/18/2013 03:42 AM, Stefano Babic wrote:
Hi Eric,
On 17/11/2013 18:17, Eric Nelson wrote:
Signed-off-by: Eric Nelson
---
This patch is new in V3
arch/arm/include/asm/arch-mx5/sys_proto.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-mx5/s
FYI:
This patch is related with the discussion in the thread:
http://patchwork.ozlabs.org/patch/292011/
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hello Wolfgang, Tom.
> > Currently U-boot defins bool type by including
> > rather than defining directly.
> > But it does not work for some cross compilers.
>
> Can you explain why this fails?
At first, I have to admit that I misunderstood the reason of the error.
It turned out that this is
Before this commit, common/cmd_test.c defined
_STDBOOL_H in order to avoid including .
But this work-around is not a good idea.
Blackfin header file
arch/blackfin/include/asm/blackfin_local.h
uses bool type here:
extern bool bfin_os_log_check(void);
This means Blackfin boards which define CONFI
Many thanks.
于 2013/11/18 20:04, Pantelis Antoniou 写道:
Hi Zhang,
I'm on travel yet again. Will be back Monday and I'll put my reviewing hat on.
Regards
-- Pantelis
On Nov 18, 2013, at 9:32 AM, Zhang Haijun wrote:
Oh, Sorry.
I mean http://patchwork.ozlabs.org/bundle/b42677/Need%20review/
Hi
On Mon, Nov 18, 2013 at 5:09 PM, Michael Trimarchi
wrote:
> Hi Tom
>
> On Mon, Nov 18, 2013 at 5:06 PM, Tom Rini wrote:
>> On Mon, Nov 18, 2013 at 04:58:33PM +0100, Michael Trimarchi wrote:
>>> Hi Tom
>>>
>>> On Mon, Nov 18, 2013 at 4:37 PM, Tom Rini wrote:
>>> > On Mon, Nov 18, 2013 at 03:0
Make PowerPC specific code conditional so ARM SoCs can reuse
this driver. Add DDR3 driver for ARM.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Replace macro CONFIG_SYS_FSL_DDR_ARM_GEN3 with CONFIG_SYS_FSL_DDRC_ARM_GEN3
Updated README
README |3 +
Fix ccsr_ddr structure to avoid using typedef. Combine DDR2 and DDR3
structure for 83xx, 85xx and 86xx.
Signed-off-by: York Sun
---
Change log
v3: Split again, as review feedback requested
v2: Merge to "Driver/DDR: Moving Freescale DDR driver to a common driver"
arch/powerpc/cpu/mpc83xx/ecc.c
Some DDR registers' fields have expanded to accommodate larger values.
These changes are backward compatible. Some fields are removed for newer
DDR controllers. Writing to those fields are safely ignored.
TIMING_CFG_2 register is fixed. Additive latency is added to RD_TO_PRE
automatically. It was
The DRAM base has been zero for Power SoCs. It could be non-zero
for ARM SoCs. Use a macro instead of hard-coding to zero.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: no change since v1
drivers/ddr/fsl/main.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/misc
and fix the header file includes.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Move to driver/misc instead of driver/mtd
arch/powerpc/cpu/mpc85
The DRAM base has been zero for Power SoCs. It could be non-zero
for ARM SoCs. Use a macro instead of hard-coding to zero.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: no change since v1
drivers/ddr/fsl/main.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --
Make PowerPC specific code conditional so ARM SoCs can reuse
this driver. Add DDR3 driver for ARM.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Replace macro CONFIG_SYS_FSL_DDR_ARM_GEN3 with CONFIG_SYS_FSL_DDRC_ARM_GEN3
Updated README
README |3 +
Fix ccsr_ddr structure to avoid using typedef. Combine DDR2 and DDR3
structure for 83xx, 85xx and 86xx.
Signed-off-by: York Sun
---
Change log
v3: Split again, as review feedback requested
v2: Merge to "Driver/DDR: Moving Freescale DDR driver to a common driver"
arch/powerpc/cpu/mpc83xx/ecc.c
Freescale IFC controller has been used for mpc8xxx. It will be used
for ARM-based SoC as well. This patch moves the driver to driver/misc
and fix the header file includes.
Signed-off-by: York Sun
---
Change log
v3: no change
v2: Move to driver/misc instead of driver/mtd
arch/powerpc/cpu/mpc85
Some DDR registers' fields have expanded to accommodate larger values.
These changes are backward compatible. Some fields are removed for newer
DDR controllers. Writing to those fields are safely ignored.
TIMING_CFG_2 register is fixed. Additive latency is added to RD_TO_PRE
automatically. It was
Hi,
On Thu, Nov 7, 2013 at 4:16 PM, Tom Rini wrote:
>
> It's an open question on if TI81xx needs these set or was simply also
> setting them for historical reasons (and in turn was inherited by am335x).
>
Based on Matt's test TI814x looks ok. I recall putting this code there
for PG1.0 of TI8168
On Mon, Nov 4, 2013 at 1:27 AM, Hui Liu wrote:
>> -Original Message-
>> From: Fabio Estevam [mailto:feste...@gmail.com]
>> Sent: Friday, November 01, 2013 10:19 PM
>> To: Otavio Salvador
>> Cc: U-Boot Mailing List; Estevam Fabio-R49496; Liu Hui-R64343
>> Subject: Re: [U-Boot] [PATCH 1/5] m
Hi Stefano,
On Mon, 2013-11-18 at 16:51 +0100, Stefano Babic wrote:
> Hi Giuseppe,
>
> On 15/11/2013 17:42, Giuseppe Pagano wrote:
> > Add Ethernet and networking support on uDoo board (FEC +phy Micrel KSZ9031).
> > Ethernet speed is currently limited to 10/100Mbps.
> >
> > Signed-off-by: Giusep
Tom Rini writes:
> On Mon, Nov 18, 2013 at 05:28:56PM +0100, Wolfgang Denk wrote:
>> Dear Masahiro Yamada,
>>
>> In message <1384770105-32364-1-git-send-email-yamad...@jp.panasonic.com> you
>> wrote:
>> > Currently U-boot defins bool type by including
>> > rather than defining directly.
>> > B
On Mon, Nov 18, 2013 at 05:28:56PM +0100, Wolfgang Denk wrote:
> Dear Masahiro Yamada,
>
> In message <1384770105-32364-1-git-send-email-yamad...@jp.panasonic.com> you
> wrote:
> > Currently U-boot defins bool type by including
> > rather than defining directly.
> > But it does not work for some
On Mon, Nov 18, 2013 at 05:13:39PM +0100, Wolfgang Denk wrote:
> Dear Michal Suchanek,
>
> In message
> you
> wrote:
> >
> > > Yes, I guess I can download the patch and process it then, and then
> > > switch tools again to type a comment in an unwieldy and unchangable
> > > environment.
> >
>
Dear Masahiro Yamada,
In message <1384770105-32364-1-git-send-email-yamad...@jp.panasonic.com> you
wrote:
> Currently U-boot defins bool type by including
> rather than defining directly.
> But it does not work for some cross compilers.
Can you explain why this fails?
AFAICT, is a compiler pr
Dear Michal Suchanek,
In message
you wrote:
>
> > Yes, I guess I can download the patch and process it then, and then
> > switch tools again to type a comment in an unwieldy and unchangable
> > environment.
>
> You need not download the patches one by one.
> You can fetch the gerrit branches in
Hi Tom
On Mon, Nov 18, 2013 at 5:06 PM, Tom Rini wrote:
> On Mon, Nov 18, 2013 at 04:58:33PM +0100, Michael Trimarchi wrote:
>> Hi Tom
>>
>> On Mon, Nov 18, 2013 at 4:37 PM, Tom Rini wrote:
>> > On Mon, Nov 18, 2013 at 03:06:21PM +0100, Michael Trimarchi wrote:
>> >> This patch add the OMAP34XX_
On Mon, Nov 18, 2013 at 04:58:33PM +0100, Michael Trimarchi wrote:
> Hi Tom
>
> On Mon, Nov 18, 2013 at 4:37 PM, Tom Rini wrote:
> > On Mon, Nov 18, 2013 at 03:06:21PM +0100, Michael Trimarchi wrote:
> >> This patch add the OMAP34XX_UART4 memory address
> >>
> >> Signed-off-by: Michael Trimarchi
On Mon, Nov 18, 2013 at 11:07:59AM +1100, Graeme Russ wrote:
> Hi All,
>
> You do all realise that we are going about this, to use some British
> vernacular, arse-about-tit
>
> Everyone agrees that the current U-Boot review workflow 'has issues' (and
> has had issues for quite some time). The fir
Hi Tom
On Mon, Nov 18, 2013 at 4:37 PM, Tom Rini wrote:
> On Mon, Nov 18, 2013 at 03:06:21PM +0100, Michael Trimarchi wrote:
>> This patch add the OMAP34XX_UART4 memory address
>>
>> Signed-off-by: Michael Trimarchi
>> ---
>> arch/arm/include/asm/arch-omap3/omap3.h | 1 +
>> 1 file changed, 1 i
Hi Giuseppe,
On 15/11/2013 17:42, Giuseppe Pagano wrote:
> Add Ethernet and networking support on uDoo board (FEC +phy Micrel KSZ9031).
> Ethernet speed is currently limited to 10/100Mbps.
>
> Signed-off-by: Giuseppe Pagano
> Tested-by: Fabio Estevam
> CC: Stefano Babic
> CC: Fabio Estevam
>
On Mon, Nov 18, 2013 at 03:06:21PM +0100, Michael Trimarchi wrote:
> This patch add the OMAP34XX_UART4 memory address
>
> Signed-off-by: Michael Trimarchi
> ---
> arch/arm/include/asm/arch-omap3/omap3.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/include/asm/arch-omap3/oma
Signed-off-by: Tom Rini
---
include/configs/am335x_evm.h |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index f35ed6f..a1a5096 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
This patch add the OMAP34XX_UART4 memory address
Signed-off-by: Michael Trimarchi
---
arch/arm/include/asm/arch-omap3/omap3.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/arch-omap3/omap3.h
b/arch/arm/include/asm/arch-omap3/omap3.h
index 7fb549a..65a5995 100644
--- a
On 11/18/2013 02:32 AM, Stefano Babic wrote:
Hi Eric,
On 14/11/2013 22:28, Eric Nelson wrote:
I dont mind either way, but just an idea for discussion:
What do you say to implementing the DRAM controller programming in
SPL? That
way, we can even do proper DRAM calibration on boot and other such
Enable clocks for the peripherals only if they are used
Signed-off-by: Michael Trimarchi
---
arch/arm/cpu/armv7/omap3/clock.c| 2 --
arch/arm/include/asm/arch-omap3/clock.h | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap3/clock.c b/arch/arm/cpu/armv7/omap3/c
out status of stack support
>> in mainline gcc.
>
> Well, why is the assembler part failing? And what is the toolchain
> people should use here?
>
That's not question to me but to our toolchain guys what it is missing
in the mainline gcc. I have sent them an email. Will see what
> From: matti kaasinen [matti.kaasi...@gmail.com]
[...]
> You mentioned, that OMAP_ECC_BCH8_CODE_HW mode and
> ecc.bytes=14 has to be used. I suppose that at least the
> former option requires kernel patching like explained in
> http://processors.wiki.ti.com/index.php/AM35x-OMAP35x
> PSP_04.02.00.
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
BCH8_ECC scheme implemented in omap_gpmc.c driver has following favours
+---+-+-+
|ECC Scheme | ECC Calculation | Error Detection |
+---+-+-+
|OMAP
This patch adds new CONFIG_NAND_OMAP_ECCSCHEME, replacing other distributed
CONFIG_xx used for selecting NAND ecc-schemes.
This patch aims at solving following issues.
1) Currently ecc-scheme is tied to SoC platform, which prevents user to select
other ecc-schemes also supported in hardware. li
ELM hardware engine which is used for ECC error detection, is present on all
latest OMAP SoC (like OMAP4xxx, OMAP5xxx, DRA7xxx, AM33xx, AM43xx). Thus ELM
driver should be moved to common drivers/mtd/nand/ folder so that all SoC
having on-chip ELM hardware engine can re-use it.
This patch has follow
*changes in v10*
[PATCH 1/4] re-generated patche using 'git format-patch -M -C' to detect renames
[PATCH 2/4] removed #ifdef while including omap_elm.h header in omap_gpmc.c
[PATCH 3/4] and [PATCH 4/4]
*changes in v9*
(Important) As this patch series was becoming bulky and had many un-related
pa
The SPDX tag conversion ate part of this file, put things back to the
way they should be.
Signed-off-by: Tom Rini
---
arch/sparc/cpu/leon3/start.S | 66 +++---
1 file changed, 37 insertions(+), 29 deletions(-)
diff --git a/arch/sparc/cpu/leon3/start.S b/arc
On Tue, Nov 12, 2013 at 04:37:34PM +0100, Michal Simek wrote:
> On 11/12/2013 02:46 PM, Rob Herring wrote:
> > On 11/12/2013 06:32 AM, Michal Simek wrote:
> >> Hi Masahiro,
> >>
> >> On 11/12/2013 10:04 AM, Masahiro Yamada wrote:
> >>> Hello Michal
> >>>
> >>>
> This should be fixed by this pa
Hi Zhang,
I'm on travel yet again. Will be back Monday and I'll put my reviewing hat on.
Regards
-- Pantelis
On Nov 18, 2013, at 9:32 AM, Zhang Haijun wrote:
> Oh, Sorry.
>
> I mean http://patchwork.ozlabs.org/bundle/b42677/Need%20review/ .
>
>
> 于 2013/11/18 16:09, Jaehoon Chung 写道:
>> Hi
Hi,
Commit fe1378a - "ARM: use r9 for gd" - broke the ABI for users of the
U-Boot API on ARM. Users I am aware of are GRUB and the FreeBSD loader.
Since I only spotted this on Saturday, this code is well and truly in
the wild, so any users of the API will need to preserve both r8 and r9
on syscall
From: Sonic Zhang
Use default GPIO operations.
Signed-off-by: Sonic Zhang
---
include/configs/bf533-stamp.h | 29 ++---
1 file changed, 2 insertions(+), 27 deletions(-)
diff --git a/include/configs/bf533-stamp.h b/include/configs/bf533-stamp.h
index a22c868..f5b9658 10
Hi Eric,
On 14/11/2013 00:36, Eric Nelson wrote:
> This allows the use of either or both declarations from
> the files mx6q_pins.h and mx6dl_pins.h.
>
> All board files should include
> with one of the following defined in boards.cfg
> MX6Q - for boards targeting i.MX6Q or i.MX6D
> MX6
Hi Eric,
On 17/11/2013 18:17, Eric Nelson wrote:
> Since the nitrogen6x board file auto-detects Nitrogen6x and
> SABRE Lite boards, override set_board_name to produce one
> of two values for board_name.
>
> Signed-off-by: Eric Nelson
> ---
> board/boundary/nitrogen6x/nitrogen6x.c | 14 +
On 11/18/2013 11:50 AM, Masahiro Yamada wrote:
> Hello Michal
>
>
Which toolchain do you use?
>>>
>>>
>>> Microblaze crosstools I use is available at:
>>> http://dev.gentoo.org/~vapier/u-boot/microblaze.tar.xz
>>
>> Not sure if Mike maintains this toolchain.
>
> Stefan Roses told me about t
Hello Michal
> >> Which toolchain do you use?
> >
> >
> > Microblaze crosstools I use is available at:
> > http://dev.gentoo.org/~vapier/u-boot/microblaze.tar.xz
>
> Not sure if Mike maintains this toolchain.
Stefan Roses told me about this pre-built cross tool in a thread:
http://u-boot.1091
Hi Eric,
On 17/11/2013 18:17, Eric Nelson wrote:
> Signed-off-by: Eric Nelson
> ---
> This patch is new in V3
>
> arch/arm/include/asm/arch-mx5/sys_proto.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/include/asm/arch-mx5/sys_proto.h
> b/arch/arm/include/asm/arch-mx5/
Currently U-boot defins bool type by including
rather than defining directly.
But it does not work for some cross compilers.
This commit changes header files to define
bool, true, false in the same way as Linux Kernel does.
Signed-off-by: Masahiro Yamada
---
Refer to include/linux/types.h and
bHi Heiko,
On Mon, Nov 18, 2013 at 3:49 PM, Heiko Schocher wrote:
> Hello Sonic Zhang,
>
> Am 18.11.2013 08:12, schrieb Sonic Zhang:
>
>> From: Sonic Zhang
>>
>> Signed-off-by: Sonic Zhang
>> ---
>> include/configs/bf533-stamp.h | 48
>> +--
>> 1 file ch
Hi Chao,
On 18/11/2013 10:26, Chao Fu wrote:
> Dear Stefano
> Excuse me, I could not understand your mean absolutely clear.
> I have tested all the four patches on Coldfire platforms.
I have not tested at all and I can be wrong - so I try to be more clear.
It is clear that after applying all p
Dear Stefano
Excuse me, I could not understand your mean absolutely clear.
I have tested all the four patches on Coldfire platforms.
Because only DSPI module is re-use on the two platforms , Coldfire is earlier,
Only change config name of DSPI.
Do you mean I should rename other modules config n
On 11/14/2013 01:37 AM, Masahiro Yamada wrote:
> Hello Michal.
>
This should be fixed by this patch - at least for microblaze.
commit 65ba7add0d609bbd035b8d42fafdaf428ac24751
Author: Rob Herring
Date: Fri Nov 8 08:40:43 2013 -0600
time: add weak annotation
On 17 November 2013 20:31, Wolfgang Denk wrote:
> Dear Tom,
>
> In message <20131116013913.GN420@bill-the-cat> you wrote:
>>
>> > Here is my key problem. I cannot even figure out what to do with this
>> > page. I cannot display it in a format I am used to, not can I
>> > process it in a way I'm
Hi Eric,
On 14/11/2013 22:28, Eric Nelson wrote:
>> I dont mind either way, but just an idea for discussion:
>>
>> What do you say to implementing the DRAM controller programming in
>> SPL? That
>> way, we can even do proper DRAM calibration on boot and other such
>> nice things.
>> And we'd also
Hi Heiko,
On 11/18/2013 03:07 PM, Heiko Schocher wrote:
add common phy reset code into a common function.
Signed-off-by: Heiko Schocher
Cc: Andreas Bießmann
Cc: Bo Shen
Cc: Jens Scharsig
Cc: Sergey Lapin
Cc: Stelian Pop
Cc: Albin Tonnerre
Cc: Eric Benard
Cc: Markus Hubig
---
- changes
Hello Jens,
Am 18.11.2013 10:00, schrieb e...@bus-elektronik.de:
Am 2013-11-18 08:07, schrieb Heiko Schocher:
add common phy reset code into a common function.
Signed-off-by: Heiko Schocher
Cc: Andreas Bießmann
Cc: Bo Shen
Cc: Jens Scharsig
Cc: Sergey Lapin
Cc: Stelian Pop
Cc: Albin Tonnerre
C
Am 2013-11-18 08:07, schrieb Heiko Schocher:
> add common phy reset code into a common function.
>
> Signed-off-by: Heiko Schocher
> Cc: Andreas Bießmann
> Cc: Bo Shen
> Cc: Jens Scharsig
> Cc: Sergey Lapin
> Cc: Stelian Pop
> Cc: Albin Tonnerre
> Cc: Eric Benard
> Cc: Markus Hubig
>
> -
Hi Chao,
On 18/11/2013 07:34, Chao Fu wrote:
> From: Chao Fu
>
> Freescale DSPI module is used on both the ColdFire platform and the ARM
> platform. There is patch-set to make the driver re-used by both platforms.
> Some files and macro were changed accordingly, this patch follow those
> changes
Hi Chao,
On 18/11/2013 07:34, Chao Fu wrote:
> From: Chao Fu
>
> This patch enable the DSPI moudle on VF610 platform with following udpate:
> Add get_dspi_clk() function and enable DPSI clock gate.
> Add DSPI iomux definition and set the iomux for DSPI.
> Add the SPI configuration for the vf610t
Hi Chao,
On 18/11/2013 07:34, Chao Fu wrote:
> From: Chao Fu
>
> Freescale DSPI module is used on both the ColdFire platform and the ARM
> platform. The original DSPI driver is written for ColdFire platform only,
> this patch
> rewrite the driver to make it be used across the platforms. The rew
From: Chao Fu
AT26DF081 is used on vf610twr board through the DSPI bus,
this patch add AT26DF081 into the spi flash params table.
Signed-off-by: Chao Fu
---
drivers/mtd/spi/sf_probe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
in
From: Chao Fu
Freescale DSPI module is used on both the ColdFire platform and the ARM
platform. There is patch-set to make the driver re-used by both platforms.
Some files and macro were changed accordingly, this patch follow those
changes to update the macro and include file for some ColdFire bo
Oh, Sorry.
I mean http://patchwork.ozlabs.org/bundle/b42677/Need%20review/ .
于 2013/11/18 16:09, Jaehoon Chung 写道:
Hi Zhang,
I known this patch have been merged at u-boot-mmc repository.
Best Regards,
Jaehoon Chung
On 11/18/2013 02:16 PM, Zhang Haijun wrote:
Hi, all
Who could help review
Hi Zhang,
I known this patch have been merged at u-boot-mmc repository.
Best Regards,
Jaehoon Chung
On 11/18/2013 02:16 PM, Zhang Haijun wrote:
> Hi, all
>
> Who could help review this patch set?
>
> Thanks in advance.
>
> 于 2013/10/31 15:51, Pantelis Antoniou 写道:
>> Hi Haijun,
>>
>> On Oct 3
91 matches
Mail list logo
