Dear Graeme Russ,
In message <4cdf36e3.7060...@gmail.com> you wrote:
>
> board_early_init_f() is (in most cases) the very first entry in the
> init_sequence[]
Right.
> So if global data is defined on the stack in board_init_f() and copied to
> the heap at the end of board_init_f() we should be O
Dear Reinhard Meyer,
In message <4cdf6070.20...@emk-elektronik.de> you wrote:
> Dear Wolfgang Denk,
> > Yes, and this is correct. board_init_f != board_early_init_f
>
> To make it crystal clear now:
>
> void board_init_f (ulong bootflag)
That's not crystal clear at all. Until now, you've been
Le 14/11/2010 06:48, Graeme Russ a écrit :
> Is there any reason the other arches could not implement an inline function
> as well? ARM for example:
>
> -#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
There is no way to set aside a register in ARM code for applicative
Dear Jason Liu,
In message <1289705187-11350-1-git-send-email-r64...@freescale.com> you wrote:
> The patch is to support getting FEC MAC address from fuse bank.
>
> Signed-off-by: Jason Liu
Please add the i.MX custodian on Cc:
> diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
> b/arch/
On 14/11/10 20:04, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4cdf36e3.7060...@gmail.com> you wrote:
>>
>> board_early_init_f() is (in most cases) the very first entry in the
>> init_sequence[]
>
> Right.
>
>> So if global data is defined on the stack in board_init_f() and copied t
Dear Albert ARIBAUD,
In message <4cdfa8e9.3050...@free.fr> you wrote:
>
> > Is there any reason the other arches could not implement an inline function
> > as well? ARM for example:
> >
> > -#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r8")
>
> There is no way to set asid
Le 14/11/2010 11:30, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cdfa8e9.3050...@free.fr> you wrote:
>>
>>> Is there any reason the other arches could not implement an inline function
>>> as well? ARM for example:
>>>
>>> -#define DECLARE_GLOBAL_DATA_PTR register volatile gd
在 2010-11-13六的 10:24 -0600,Kumar Gala写道:
> On Nov 12, 2010, at 9:43 PM, terry wrote:
>
> >>>
> >>> by the way,I cann't find the prototype of malloc in the whole project,it
> >>> seems that it is encapsulated in some libs.
> >>
> >> It's in common/malloc.c. There's weird preprocessor renaming go
Dear Wolfgang Denk,
To make it crystal clear now, and put the complete context:
That simple change would rid us of all alignment concerns:
Setting stack to end of initial storage will certainly
be aligned, and the auto_gd will be aligned as the
toolchain deems necessary.
We would not need GENERA
On 11/13/2010 11:48 AM, Wolfgang Denk wrote:
>
> Entry to MAINTAINERS missing.
I forget always to update the MAINTAINERS file, thanks...
> What's that for? Seems unused...
You are right - dropped !
Best regards,
Stefano Babic
--
==
This board uses the OMAP-L138 SOM stacked on a
custom baseboard. It supports SPI Flash, Ethernet
with RMII.
Signed-off-by: Stefano Babic
---
Changes since V1:
- Add entry to MAINTAINERS file (Wolfgang Denk)
- Removed unused DEF_BOOTM in config file (Wolfgang Denk)
MAINTAINERS
Dear Albert ARIBAUD,
In message <4cdfd1ae.1070...@free.fr> you wrote:
>
> >> There is no way to set aside a register in ARM code for applicative
> >> purposes.
>
> > What exactly do you mean by that?
>
> Use of the 16 ARM registers r0 to r15 in C code is governed by ABIs; we
> use the one known as
On Sat, 2010-11-13 at 23:53 +0100, Wolfgang Denk wrote:
> Dear Kumar,
>
> In message <1288297499-21417-1-git-send-email-pty...@xes-inc.com> Peter Tyser
> wrote:
> > Previously fsl_pci_init_port() always assumed that a port was a PCIe
> > port and would incorrectly print messages for a PCI port su
On 11/11/2010 12:37 PM, Xiangfu Liu wrote:
> From: Xiangfu Liu
If possible, please describe what Jz4740 SoC is, an overview of JzRISC
processor, where this patch is from or where to get the original work,
and so on.
It also would be nice we could have Signed-off-by: or Acked-by: from
Ingenic peo
That removes the need to reserve memory above the stack
and also removes the need for GENERATED_GBL_DATA_SIZE.
Alignment is automatically "right" provided stack is
aligned.
Signed-off-by: Reinhard Meyer
---
arch/arm/lib/board.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff
Signed-off-by: Reinhard Meyer
---
include/configs/top9000.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/include/configs/top9000.h b/include/configs/top9000.h
index 1533a63..4606146 100644
--- a/include/configs/top9000.h
+++ b/include/configs/top9000.h
@@ -172,8 +172
This allows -after reimplementation of board_mmc_init() function- to set up the
base address of the eSDHC controller at runtime. This is useful on iMX515 board
I have, where there are two controllers and on different revisions of the board,
only one of them is used. The board revision can be detect
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Dear Reinhard Meyer,
In message <1289750861-23050-1-git-send-email-u-b...@emk-elektronik.de> you
wrote:
> That removes the need to reserve memory above the stack
> and also removes the need for GENERATED_GBL_DATA_SIZE.
> Alignment is automatically "right" provided stack is
> aligned.
>
> Signed-
Dear Reinhard Meyer,
In message <1289750886-23092-1-git-send-email-u-b...@emk-elektronik.de> you
wrote:
> Signed-off-by: Reinhard Meyer
> ---
> include/configs/top9000.h |3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/top9000.h b/include/configs/
Dear Reinhard Meyer,
and - do they compile? Do they work?
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...@d
On Sunday 14 November 2010 17:01:02 Marek Vasut wrote:
> This allows -after reimplementation of board_mmc_init() function- to set up
> the base address of the eSDHC controller at runtime. This is useful on
> iMX515 board I have, where there are two controllers and on different
> revisions of the bo
Dear Marek Vasut,
In message <201011141735.30504.marek.va...@gmail.com> you wrote:
> On Sunday 14 November 2010 17:01:02 Marek Vasut wrote:
> > This allows -after reimplementation of board_mmc_init() function- to set up
> > the base address of the eSDHC controller at runtime. This is useful on
> >
On 11/14/2010 04:26 AM, Jason Liu wrote:
> The patch is to support getting FEC MAC address from fuse bank.
>
> Signed-off-by: Jason Liu
>
Hi Jason,
> ---
> Changes for v2:
> - correct the mac address byte order according to review comments
> - add memset(edev, 0. sizeof(*edev)) when do fec
On Sunday 14 November 2010 17:59:09 Wolfgang Denk wrote:
> Dear Marek Vasut,
>
> In message <201011141735.30504.marek.va...@gmail.com> you wrote:
> > On Sunday 14 November 2010 17:01:02 Marek Vasut wrote:
> > > This allows -after reimplementation of board_mmc_init() function- to
> > > set up the b
On 11/14/2010 06:01 PM, Marek Vasut wrote:
> Hi Wolfgang,
>
> it means Stefano explained to me he already tried pushing in such a patch and
> the patch was rejected. Therefore, I assume you should ignore this patch.
To complete the explanation: there is already a way to make address
configurabl
Le 14/11/2010 16:01, Wolfgang Denk a écrit :
> This is perfectly OK, as we don't have to interface in any way with
> any strictly EABI conforming code - we are working in a completely
> controlled environment and can adjust rules as needed.
Alright, then I think we should document how we comply,
Dear Albert ARIBAUD,
In message <4ce0221a.7030...@free.fr> you wrote:
>
> Alright, then I think we should document how we comply, or do not
> comply, with GNU EABI / AAPCS (maybe a README.arm that people could read
Register use is documented in the top level README.
> up) -- and I think if there
Dear Albert ARIBAUD,
In message <4ce0221a.7030...@free.fr> you wrote:
>
> Alright, then I think we should document how we comply, or do not
> comply, with GNU EABI / AAPCS (maybe a README.arm that people could read
> up) -- and I think if there is a way to access GD both before and after
> reloca
Le 14/11/2010 20:06, Wolfgang Denk a écrit :
>> Alright, then I think we should document how we comply, or do not
>> comply, with GNU EABI / AAPCS (maybe a README.arm that people could read
>
> Register use is documented in the top level README.
My bad: I'd missed that one because I always go stra
On 15/11/10 06:23, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <4ce0221a.7030...@free.fr> you wrote:
>>
>> Alright, then I think we should document how we comply, or do not
>> comply, with GNU EABI / AAPCS (maybe a README.arm that people could read
>> up) -- and I think if there is
On 15/11/10 00:46, Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>
> To make it crystal clear now, and put the complete context:
>
> That simple change would rid us of all alignment concerns:
> Setting stack to end of initial storage will certainly
> be aligned, and the auto_gd will be aligned as t
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> and - do they compile? Do they work?
Compile and work on top9000 = at91sam9xe = arm926ejs.
Since no tricks are used anymore, it is very likely
this will work on all other ARM variants or even on all
architectures with a similar GLOBAL_DATA method.
I
On 14/11/10 21:21, Graeme Russ wrote:
> On 14/11/10 20:04, Wolfgang Denk wrote:
>> Dear Graeme Russ,
>>
>> In message <4cdf36e3.7060...@gmail.com> you wrote:
>>>
> Why don't we just change board_init_f(ulong bootflag) to board_init_f(gd_t
> *gd)? avr would need a slight mod to add board_type to gd
Dear Albert ARIBAUD,
In message <4ce0388e.2070...@free.fr> you wrote:
>
> > Register use is documented in the top level README.
>
> My bad: I'd missed that one because I always go straight to the doc/
> directory for documentation of this kind -- the root README I never read
> apart from the first
Le 14/11/2010 20:34, Graeme Russ a écrit :
> On 15/11/10 06:23, Wolfgang Denk wrote:
>> Dear Albert ARIBAUD,
>>
>> In message<4ce0221a.7030...@free.fr> you wrote:
>>>
>>> Alright, then I think we should document how we comply, or do not
>>> comply, with GNU EABI / AAPCS (maybe a README.arm that pe
Le 14/11/2010 20:55, Wolfgang Denk a écrit :
> Actually situation might be differenton ARM. I just did quick and
> ditry test for the TX25 board:
>
> [...]
>
> The global pointer method saves a total of 152 bytes here
> (156 in .text saved, but 4 in .data needed).
>
> OK, this is not eve
Dear Graeme Russ,
> On 15/11/10 00:46, Reinhard Meyer wrote:
>> Dear Wolfgang Denk,
>>
>> To make it crystal clear now, and put the complete context:
>>
>> That simple change would rid us of all alignment concerns:
>> Setting stack to end of initial storage will certainly
>> be aligned, and the aut
Le 14/11/2010 20:42, Reinhard Meyer a écrit :
> 1. I am quite sure that in arm/lib/board.c
> __asm__ __volatile__("": : :"memory");
> was never needed and definitely is not needed anymore.
> Can anyone shed some light on why this was added?
> Probably just copied from other architectures where som
Dear Albert ARIBAUD,
> Le 14/11/2010 20:42, Reinhard Meyer a écrit :
>
>> 1. I am quite sure that in arm/lib/board.c
>> __asm__ __volatile__("": : :"memory");
>> was never needed and definitely is not needed anymore.
>> Can anyone shed some light on why this was added?
>> Probably just copied from
Dear Albert ARIBAUD,
In message <4ce04241.7070...@free.fr> you wrote:
>
> > OK, this is not even 0.1% of the size, but anyway...
>
> If the difference in size is marginal, then I prefer the implementation
> that has the least 'quirks' and most closely complies with EABI/AAPCS.
Yes, I agree. O
Dear Albert ARIBAUD,
In message <4ce04585@free.fr> you wrote:
>
> Currently start.S sets the stack twice, once before calling
> board_init_f, and once in relocate_code. Are you suggesting we remove
> the second sp setting?
As relocation can move the stack to some completely different locat
Dear Peter,
In message <1288293797-16422-1-git-send-email-hschau...@nulltrace.org> Himanshu
Chauhan wrote:
> Following is the patch for defining the subject line mentioned
> configuration defines for versatile boards.
>
> Signed-off-by: Himanshu Chauhan
> ---
> include/configs/versatile.h |
Dear All,
> Dear Albert ARIBAUD,
>
> In message<4ce04585@free.fr> you wrote:
>>
>> Currently start.S sets the stack twice, once before calling
>> board_init_f, and once in relocate_code. Are you suggesting we remove
>> the second sp setting?
>
> As relocation can move the stack to some complet
On Mon, Nov 15, 2010 at 7:16 AM, Reinhard Meyer
wrote:
> Dear Graeme Russ,
>>
>> On 15/11/10 00:46, Reinhard Meyer wrote:
>>>
>>> Dear Wolfgang Denk,
>>>
>>> To make it crystal clear now, and put the complete context:
>>>
>>> That simple change would rid us of all alignment concerns:
>>> Setting s
Dear Stefan Roese,
In message <201011021149.24656...@denx.de> you wrote:
>
> I prefer the first approach, not automatically unmounting upon UBI device
I don't see any advantages of this approach.
> change. One plus for this version is that the user might have issued the 2nd
> "ubi part" by mis
Dear "Premi, Sanjeev",
In message you
wrote:
>
> Did you get chance to look at this series?
Looks OK to me, but you should have put Sandeep on Cc: as this has to
go through his custodian tree.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zund
Dear Sergiy Kibrik,
In message <4cd27f08.8060...@globallogic.com> you wrote:
> Improved default config for OMAP4 Pandaboard for faster boot:
> -reduced environment size to speed up memory initialization;
> -USB TTY driver turned off;
> -tweaked blob load address to avoid image re
Dear Albert ARIBAUD,
In message <4cdba515.3050...@free.fr> you wrote:
>
> Alright. I'll prepare a V5 patch set with fixes to all ARM cpus.
> Wolfgang, is a single *patch* for all cpus ok or do you want a single
> *patchset* with one patch per cpu? Please tell me the single patch
> approach is o
On Mon, Nov 15, 2010 at 7:05 AM, Albert ARIBAUD wrote:
> Le 14/11/2010 20:34, Graeme Russ a écrit :
>>
>> On 15/11/10 06:23, Wolfgang Denk wrote:
>>>
>>> Dear Albert ARIBAUD,
>>>
>>> In message<4ce0221a.7030...@free.fr> you wrote:
Alright, then I think we should document how we comply,
Dear "Bernstein, Michael",
In message
you wrote:
>
> The patch attached add support for a flash bank size of 16 MB and for a
> second DRAM bank for the KS8695 (ARM9 core) depending on the configuration.
>
> A better solution would be to calculate the values for the registers (only
> some shift
Dear Mike Frysinger,
In message <201011091835.38581.vap...@gentoo.org> you wrote:
>
> > Should all architectures strive to look as much like one another as
> > possible? Should we accept that maybe this particular issue be thrown in
> > the too hard basket?
>
> imo, we should strive to have these
Dear Mike Frysinger,
In message <201011101755.54287.vap...@gentoo.org> you wrote:
>
> > > > Seems this was not a fix, but introduced an error. Dp you agree to
> > > > revert that commit?
> > >
> > > of course i disagree. this change is a fix in my mind.
> >
> > Please reconsider. This has bee
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-2-git-send-email-iwama...@nigauri.org> you wrote:
> rtl8139 driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iwa
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-1-git-send-email-iwama...@nigauri.org> you wrote:
> rtl8169 does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iwamatsu
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-3-git-send-email-iwama...@nigauri.org> you wrote:
> dc2114x driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iwa
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-5-git-send-email-iwama...@nigauri.org> you wrote:
> This prevents access to the member of eth_device which is not initialized.
>
> Signed-off-by: Nobuhiro Iwamatsu
> CC: Ben Warren
> ---
> drivers/net/fec_mxc.c |1 +
> 1 files changed, 1
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-4-git-send-email-iwama...@nigauri.org> you wrote:
> eepro100 driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iw
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-6-git-send-email-iwama...@nigauri.org> you wrote:
> natsemi driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iwa
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-7-git-send-email-iwama...@nigauri.org> you wrote:
> ns8382x driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iwa
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-8-git-send-email-iwama...@nigauri.org> you wrote:
> pcnet driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iwama
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-9-git-send-email-iwama...@nigauri.org> you wrote:
> tsi108_eth driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro
Dear Nobuhiro Iwamatsu,
In message <1287464627-12302-10-git-send-email-iwama...@nigauri.org> you wrote:
> uli526x driver does not have write_hwaddr function.
> However, eth stuff executes write_hwaddr function
> because eth_device structure has not been initialized.
>
> Signed-off-by: Nobuhiro Iw
Dear Kumar Gala,
In message <1289556786-15201-1-git-send-email-ga...@kernel.crashing.org> you
wrote:
> nic and hw structures are allocated via malloc i.e. return memory
> is not zero initialized. Because of this few structure member like
> "function pointers" are initialized with garbage values.
Dear Joakim Tjernlund,
In message <1288893720-29915-1-git-send-email-joakim.tjernl...@transmode.se>
you wrote:
> The fixup procedure just stored a constant value in the
> fixup table rather than just adjusting the table.
> Although that doesn't seem to do any harm, it prevents
> relocation more t
Dear Lei Wen,
In message you
wrote:
> --00248c0d766c2c192a0494a740ed
> Content-Type: text/plain; charset=UTF-8
>
> Hi Mike,
>
> Please review this refined patch.
>
> >From a7c694f84bec6b0db26ece4c77d06585be5a6755 Mon Sep 17 00:00:00 2001
> From: Lei Wen
> Date: Wed, 10 Nov 2010 07:44:03 +080
Dear Jason Liu,
In message <1289708589-12221-1-git-send-email-r64...@freescale.com> you wrote:
> Can't get IP address with dhcp due to the dhcp server not
> allow the empty param list request under some network env
>
> This patch is based on Gray Remlin's initial patch.
>
> Signed-off-by: Jason
Dear Peter Tyser,
In message <1288297499-21417-1-git-send-email-pty...@xes-inc.com> you wrote:
> Previously fsl_pci_init_port() always assumed that a port was a PCIe
> port and would incorrectly print messages for a PCI port such as the
> following on bootup:
> PCI1: 32 bit, 33 MHz, sync, hos
Dear Peter Tyser,
In message <1288393169-9814-2-git-send-email-pty...@xes-inc.com> you wrote:
> Previously some mpc85xx boards printed indented messages such as the
> following on bootup:
> printf("eTSEC4 is in sgmii mode.\n");
> printf("Serdes2 disalbed\n");
>
> The bootup appearance
Dear Peter Tyser,
In message <1288393169-9814-3-git-send-email-pty...@xes-inc.com> you wrote:
> The "Scanning PCI bus X" message doesn't provide any real useful
> information, so remove it.
>
> Original output:
> PCIE1: connected as Root Complex
> Scanning PCI bus 01
> 04
Dear Peter Tyser,
In message <1288393169-9814-1-git-send-email-pty...@xes-inc.com> you wrote:
> Previously boards used a variety of indentations, newline styles, and
> colon styles for the PCI information that is printed on bootup. This
> patch unifies the style to look like:
>
> ...
> NAND: 10
Dear Peter Tyser,
In message <1288393169-9814-4-git-send-email-pty...@xes-inc.com> you wrote:
> This change does the following:
> - Removes the printing of the PCI interrupt line value. This is
> normally set to 0 by U-Boot on bootup and is rarely used during
> everyday operation.
>
> - Prin
Dear Peter Tyser,
In message <1288393169-9814-5-git-send-email-pty...@xes-inc.com> you wrote:
> Move the printing of PCI device information to before the PCI device is
> configured. This prevents the case where recursive scanning results in
> the deepest devices being printed first.
>
> This cha
Dear Peter Tyser,
In message <1288393169-9814-6-git-send-email-pty...@xes-inc.com> you wrote:
> When CONFIG_PCI_SCAN_SHOW is defined U-Boot prints out PCI devices as
> they are found during bootup, eg:
> PCIE1: connected as Root Complex
> 01:00.0 - 10b5:8518 - Bridge device
> 02:
Dear Peter Tyser,
In message <1288393146-9753-1-git-send-email-pty...@xes-inc.com> you wrote:
> Add a check to make sure that the user's arguments actually find a board
> in boards.cfg. Previously, if a user misspelled an argument the
> argument would be discarded without warning. For example, r
Dear =?iso-8859-1?Q?Fran=E7ois_Revol?=,
In message you wrote:
>
> --Apple-Mail-3-908474921
> Content-Transfer-Encoding: quoted-printable
> Content-Type: text/plain;
> charset=iso-8859-1
Please use git-send-email to submit patches. Make sure to use a short,
descriptive subject, and a sane
Dear Ben Warren,
In message <1283321104-953-2-git-send-email-biggerbadder...@gmail.com> you
wrote:
> This has always been confusing, and the idea of these functions returning the
> number of interfaces initialized was half-baked and ultimately pointless.
> Instead, act more like regular functions
Dear Kyle Moffett,
In message <1284393146-22142-2-git-send-email-kyle.d.moff...@boeing.com> you
wrote:
> By allocating the e1000 device structures much earlier, we can easily
> generate better error messages and siginficantly clean things up.
>
> The only user-visable change (aside from reworded
Healthy Coffee & Tea Beverage Drinks
Reply to: atj...@sbcglobal.net
Dear coffee beverage drinkers,
We would like for you to try our coffee brand favorites that taste better then
anything you have tried before.
To request a coffee brand trial packet please email us atj...@sbcglobal.net and
2010/11/15 Stefano Babic :
> On 11/14/2010 04:26 AM, Jason Liu wrote:
>> The patch is to support getting FEC MAC address from fuse bank.
>>
>> Signed-off-by: Jason Liu
>>
>
> Hi Jason,
>
>> ---
>> Changes for v2:
>> - correct the mac address byte order according to review comments
>> - add mem
Dear Wolfgang,
On 13 November 2010 21:14, Prafulla Wadaskar wrote:
>
>
>> -Original Message-
>> From: Paulraj, Sandeep [mailto:s-paul...@ti.com]
>> Sent: Saturday, November 13, 2010 5:31 AM
>> To: Wolfgang Denk; u-boot@lists.denx.de
>> Cc: Albert Aribaud; Reinhard Meyer; Stefano Babic; Pr
> - ColdFire:
> ---
>
> Liew Tsi Chun has announced that he has to give up ColdFire
> custodianship.
>
> Thanks a lot for all work done to TsiChung!
>
> He proposes that Jason (Jin Zhengxiong) will pick up his work.
>
> So welcome aboard, Jason!
Thanks
> For now, I would l
> - ColdFire:
> ---
> Liew Tsi Chun has announced that he has to give up ColdFire
> custodianship.
> Thanks a lot for all work done to TsiChung!
> He proposes that Jason (Jin Zhengxiong) will pick up his work.
> So welcome aboard, Jason!
Thanks.
> - General:
> --
>
>
Tested on upcoming hydra (mpc5200 based) board.
Signed-off-by: Heiko Schocher
---
arch/powerpc/cpu/mpc5xxx/i2c.c | 43
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc5xxx/i2c.c b/arch/powerpc/cpu/mpc5xxx/i2c.c
index
If CONFIG_SYS_POST_I2C_ADDRS is not defined and CONFIG_SYS_POST_I2C
is activated, i2c_probe() is not called in the for statement,
because missing curly bracket.
Signed-off-by: Heiko Schocher
---
post/drivers/i2c.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/post/dr
hi Stefano,
On Sun Nov 14, 2010 at 03:55:01PM +0100, Stefano Babic wrote:
> diff --git a/board/davinci/ea20/ea20.c b/board/davinci/ea20/ea20.c
> new file mode 100644
> index 000..c75ea63
> --- /dev/null
> +++ b/board/davinci/ea20/ea20.c
> @@ -0,0 +1,237 @@
> +/*
> + * Copyright (C) 2010 Texas
Dear Sebastien Carlier,
In message <20101110080708.ga8...@safe.home.local> you wrote:
> Good suggestion, done in v3:
I have to admit that I lost a bit of overview of the current state of
this work. My understanding is that you are preparing a new version
(V4 ?) of this patch?
If yes, do you ha
87 matches
Mail list logo