On 14/11/10 16:10, Graeme Russ wrote:
> On 13/11/10 22:18, Graeme Russ wrote:
>> On 13/11/10 19:20, Albert ARIBAUD wrote:
>>> Le 13/11/2010 05:16, Graeme Russ a écrit :
>>>
> static inline void *get_gd_ptr(void)
> {
> void *gd_ptr;
>
> asm volatile("gs mov 0, %0\n" : "=r" (gd_ptr));
>
On 13/11/10 22:18, Graeme Russ wrote:
> On 13/11/10 19:20, Albert ARIBAUD wrote:
>> Le 13/11/2010 05:16, Graeme Russ a écrit :
>>
>>> I essence, the gd pointer is a unique global variable available prior to
>>> relocation. On all other arches, this is achieved by using a reserved
>>> register which
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 Liu
Signed-off-by: Gray Remlin
---
Changes for v2:
- address the comments from Mike and re-order the co
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)
{
bd_t *bd;
init_fnc_t **init_fnc_ptr;
gd_t *id;
ulong addr, addr_sp;
+ gd_t auto_gd;
/* Pointer is wr
2010/10/23 Mike Frysinger :
> On Friday, October 22, 2010 04:36:25 Jason Liu wrote:
>> From: Gray Remlin
>>
>> Can't get IP address with dhcp due to the dhcp server not
>> allow the empty param list request under some network env
>>
>> --- a/net/bootp.c
>> +++ b/net/bootp.c
>> @@ -417,9 +417,19 @@
The patch is to support getting FEC MAC address from fuse bank.
Signed-off-by: Jason Liu
---
Changes for v2:
- correct the mac address byte order according to review comments
- add memset(edev, 0. sizeof(*edev)) when do fec_probe,
- fix some code comments
---
arch/arm/include/asm/arch-mx2
On 14/11/10 11:35, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4cdf2c8b.3060...@gmail.com> you wrote:
>>
>>> You cannot and must not touch SDRAM in board_early_init_f(). And even
>>> more, you must not at all run relocate_code() there!
>>>
>>
>> See:
>> arch/powerpc/lib/board.c
>> a
Dear Graeme Russ,
In message <4cdf2c8b.3060...@gmail.com> you wrote:
>
> > You cannot and must not touch SDRAM in board_early_init_f(). And even
> > more, you must not at all run relocate_code() there!
> >
>
> See:
> arch/powerpc/lib/board.c
> arch/m68k/lib/board.c
> arch/arm/lib/board.c
>
>
On 14/11/10 11:07, Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message <4cdf15bb.1090...@emk-elektronik.de> you wrote:
>>
Correct, that's why its even now copied over to storage in SDRAM...
(at least on ARM:
debug ("relocation Offset is: %08lx\n", gd->reloc_off);
m
Dear Reinhard Meyer,
In message <4cdf15bb.1090...@emk-elektronik.de> you wrote:
>
> >> Correct, that's why its even now copied over to storage in SDRAM...
> >> (at least on ARM:
> >>debug ("relocation Offset is: %08lx\n", gd->reloc_off);
> >>memcpy (id, (void *)gd, sizeof (gd_t));
> >>
>
On Friday, November 12, 2010 09:42:52 Jason Kridner wrote:
> On Tue, Nov 9, 2010 at 8:52 AM, Mike Frysinger wrote:
> > On Friday, November 05, 2010 01:50:36 Jason Kridner wrote:
> >> + if (strcmp(argv[2], "off") == 0) {
> >> + state = 0;
> >> + } else if (strcmp(argv[2], "on")
Dear Michael,
Ping!
In message <20101026210959.51803136...@gemini.denx.de> I wrote:
> Dear Michael Zaidman,
>
> In message
>
> you wrote:
> > - Revives POST for blackfin arch;
> > - Removes redundant code:
> > arch/blackfin/lib/post.c
> > arch/powerpc/cpu/ppc4xx/commproc.c
> >
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 such as the
> following on bootup:
> PCI1: 32 bit, 33 MHz, sync,
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4cdf137e.2000...@emk-elektronik.de> you wrote:
>>
>>> This has but on tiny shortcoming: we use GD to pass data around, for
>>> example to pass clock frequencies determind before relocation to the
>>> code running after relocation - which me
Dear Reinhard Meyer,
In message <4cdf137e.2000...@emk-elektronik.de> you wrote:
>
> > This has but on tiny shortcoming: we use GD to pass data around, for
> > example to pass clock frequencies determind before relocation to the
> > code running after relocation - which means that GD must be of a
>
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message<4cdf04a8.4050...@emk-elektronik.de> you wrote:
>>
>> But whats left of my ideas is the following:
>>
>> in asm: set stack to end of SRAM (or whatever)
>> (board-config.h would not subtract GENERATED_GBL_DATA_SIZE
>> anymore)
>>
>> in c:
>>
Dear Reinhard Meyer,
In message <4cdf04a8.4050...@emk-elektronik.de> you wrote:
>
> But whats left of my ideas is the following:
>
> in asm: set stack to end of SRAM (or whatever)
> (board-config.h would not subtract GENERATED_GBL_DATA_SIZE
> anymore)
>
> in c:
> board_early_init(void)
> {
>
Dear Wolfgang Denk,
> I think you would quickly find this becoming a pretty serious pain.
Yes, I saw that soon after my first post:)
But whats left of my ideas is the following:
in asm: set stack to end of SRAM (or whatever)
(board-config.h would not subtract GENERATED_GBL_DATA_SIZE
anymore)
Dear Claudio Mignanti,
> The problem is related to the new MMC driver, simple the mmc driver
> don't recognize my cards and also "mmc info" returns no info.
Just a blind shot:
is your MCI on port B (like it is on the at91sam9xxx-ek)?
Then define CONFIG_ATMEL_MCI_PORTB.
Best Regards,
Reinhard
_
I managed to build mpc8548 u-boot on FreeBSD with it's native powerpc cross
tools. All went fine after a little changes.
But at final linking stage, I got those "start.o(.got2+0x1c): relocation
truncated to fit: blah blah blah..." messages.
so I looked at .lds and it's write
* .resetvec RESET_V
Le 13/11/2010 19:13, Wolfgang Denk a écrit :
> Dear Darius Augulis,
>
> In message<4cdec32b.7050...@gmail.com> you wrote:
>>
>>> FWIW, there already is a solution based on statics and post-relocation
>>> initialization for orion5x. The principle there is that the timer is not
>>> used before calli
Dear Kumar Gala,
In message you wrote:
>
> I'd like to move cpu_init_r to after env_relocate(). This is desirable
> on 85xx based systems to deal with an issue when we boot from NAND (and
> probably SPI or SDHC/MMC) in which we use the L2 cache in SRAM mode to
> load the u-boot image from the s
Dear Darius Augulis,
In message <4cdec32b.7050...@gmail.com> you wrote:
>
> > FWIW, there already is a solution based on statics and post-relocation
> > initialization for orion5x. The principle there is that the timer is not
> > used before calling board_init_r, so we don't need initializing
> >
Dear Reinhard,
2010/11/10 Reinhard Meyer :
>
> Correct. However atmel_mci is the "old" driver, at at91 we are using
> the common mmc driver gen_atmel_mci. This one should work for avr32 as
> well (not tested).
>
Thanks for all your comments, now I finished to do some tests using my
board definiti
Hi list,
this is my first post on u-boot list.
I'm trying to write function "board_nand_init" for a Pollux VR3520F SoC
based board.
I'm having some troubles and really don't know very good where to start and
which parts of nand_chip pointer have to be filled and which not.
Could you please help me
Wolfgang, Stefan, Kim, (other PPC arch maintainers)
I'd like to move cpu_init_r to after env_relocate(). This is desirable on 85xx
based systems to deal with an issue when we boot from NAND (and probably SPI or
SDHC/MMC) in which we use the L2 cache in SRAM mode to load the u-boot image
from t
Dear Albert,
On 11/12/2010 09:25 PM, Albert ARIBAUD wrote:
> Le 12/11/2010 19:18, Darius Augulis a écrit :
>> Dear Minkyu Kang,
>>
>> On 11/12/2010 05:10 AM, Minkyu Kang wrote:
>>> Dear Darius Augulis,
>>>
>>> On 2 November 2010 05:49, Darius Auguliswrote:
S3C64XX timer uses static variab
I've been debugging a "memory corruption" issue and it seems to come down to
how we set MORECORE_CLEARS
from malloc.h:
MORECORE (default: sbrk)
The name of the routine to call to obtain more memory from the system.
MORECORE_FAILURE (default: -1)
The value
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 going on,
>> so it's called mALLOc in that file, but it
> -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; Prafulla Wadaskar;
> Marek Vasut; Minkyu Kang; Mike Frysinger; Stefan Roese; J
On 13/11/10 19:20, Albert ARIBAUD wrote:
> Le 13/11/2010 05:16, Graeme Russ a écrit :
>
>> I essence, the gd pointer is a unique global variable available prior to
>> relocation. On all other arches, this is achieved by using a reserved
>> register which I do not have the luxury of on x86 :(
>
>
Dear Stefano Babic,
In message <1289638030-6838-1-git-send-email-sba...@denx.de> you wrote:
> This board uses the OMAP-L138 SOM stacked on a
> custom baseboard. It supports SPI Flash, Ethernet
> with RMII.
>
> Signed-off-by: Stefano Babic
> ---
> board/davinci/ea20/Makefile | 53 ++
>
Some boar config files defined DEF_BOOTM but this was not used
anywhere in the code. Remove this bogus define.
Signed-off-by: Wolfgang Denk
Cc: Sandeep Paulraj
---
include/configs/da830evm.h |1 -
include/configs/da850evm.h |1 -
include/configs/davinci_dvevm.h |1 -
i
On 13/11/10 17:38, Reinhard Meyer wrote:
> On 13.11.2010 07:31, Reinhard Meyer wrote:
>> Dear Graeme Russ, Dear All,
>>> On 10/11/10 10:35, Mike Frysinger wrote:
On Sunday, November 07, 2010 05:06:26 Graeme Russ wrote:
> Should all architectures strive to look as much like one another as
>
This board uses the OMAP-L138 SOM stacked on a
custom baseboard. It supports SPI Flash, Ethernet
with RMII.
Signed-off-by: Stefano Babic
---
board/davinci/ea20/Makefile | 53 ++
board/davinci/ea20/ea20.c | 237 +++
boards.cfg
Le 13/11/2010 05:16, Graeme Russ a écrit :
> I essence, the gd pointer is a unique global variable available prior to
> relocation. On all other arches, this is achieved by using a reserved
> register which I do not have the luxury of on x86 :(
Dusting off old knowledge of x86 and without eve
Dear Reinhard Meyer,
In message <4cde30cf.9010...@emk-elektronik.de> you wrote:
>
> I *personally* prefer code without tool-chain specific, out of "C"
> constructs. So I would be fine with passing gd as a parameter to all
I think you would quickly find this becoming a pretty serious pain.
I've b
>
> http://patchwork.ozlabs.org/project/uboot/list/
>
> The setup has just been activated; I will try to arrange to have
> some more history added, but I don;t want to promise that this will
> work, or when this will happen.
>
>
> For now, I would like to ask all CUSTODIANS to regist
38 matches
Mail list logo
