SMRDATA in a/a/c/arm920t/at91/lowlevel_init.c has wrong size. This patch
reduces it to correct size of 40 byte.
Signed-off-by: Andreas Bießmann
---
Dear all,
I thougt about a problem in lowlevel_init() cause of errornous booting from
NOR flash on at91rm9200ek last night . This morning I detected
> Hi,
> > I am trying to read images from SD cards attached to
> > a USB card reader. "usb start" command shows errors
> > as per logs copied below.
>
> I tested with uboot version 2009.11 and will try with latest
> Uboot and update the results.
With the latest uboot Transcend card reader works f
> This patch introduces an extra mask-field in spansion_spi_flash_params
> to support flash chips with 1-byte extended ID (like the S25FL032P).
> Signed-off-by: David Jander
The extension ID has been checked with the datasheet.
http://www.spansion.com/Support/Datasheets/S25FL032P_00_05_e.pdf
a
Hi,
> I am trying to read images from SD cards attached to
> a USB card reader. "usb start" command shows errors
> as per logs copied below.
I tested with uboot version 2009.11 and will try with latest
Uboot and update the results.
Ajay
>
> Is there any known issue in supporting usb card readers
This file has been synced (copy) from Linux source code.
This commit was based on kernel 2.6.32.
It updates gigabit related phy registers and basic definitions.
Signed-off-by: Macpaul Lin
---
Change v1: pull header file from Linux.
Change v2: clean up unused code for u-boot.
include/linux/mii.h
Hi All,
I am trying to read images from SD cards attached to
a USB card reader. "usb start" command shows errors
as per logs copied below.
Is there any known issue in supporting usb card readers
In general or it's compatibility issue with few card
readers?
Regards,
Ajay
1) Card reader - [A]
===
> Mike Frysinger [mailto:vap...@gentoo.org]
> > ???: u-boot@lists.denx.de
> Macpaul Chih-Pin Lin
> Re: [U-Boot] [PATCH] include/linux/mii.h: update for supporting GE
>
> On Thursday, December 02, 2010 22:25:53 Macpaul Lin wrote:
> > This file has been synced (copy) from Linux source code.
>
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Thursday, December 02, 2010 5:05 PM
> To: Lei Wen
> Cc: Prafulla Wadaskar; Eric Miao; Manas Saksena; Lei Wen; Yu Tang; u-
> b...@lists.denx.de; Ashish Karkare; Kiran Vedere; Prabhanjan Sarnaik
> Subject: Re: [U-Boot]
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Carlo Caione
> Sent: Friday, December 03, 2010 3:11 AM
> To: U-Boot@lists.denx.de
> Subject: Re: [U-Boot] [STATUS] v2010.12-rc2 released
>
> > Some of the times, the boot hung a
On Thursday, December 02, 2010 22:25:53 Macpaul Lin wrote:
> This file has been synced (copy) from Linux source code.
pulling in updates is fine, but i dont think it makes sense to pull in
types/prototypes that arent used in u-boot
> +/* This structure is used in all SIOCxMIIxxx ioctl calls */
>
Sehr geehrte
Ich heibe Christian Schroeder und ich habe ein Angebot fur Sie!
Unser Unternehmen Jasckson Logistic sucht im Moment neue Arbeitskrafte! Wir
haben Ihre Bewerbungsunterlagen bei uns vor einige Zeit
liegen gefunden und jetzt mochten wir Ihnen eine Stelle von unseren
AuBendienstvertre
This file has been synced (copy) from Linux source code.
This commit was based on kernel 2.6.32.
It updates gigabit related phy registers and basic definitions.
Signed-off-by: Macpaul Lin
---
include/linux/mii.h | 270 +--
1 files changed, 197 ins
Hi Vitaly,
On Fri, Dec 3, 2010 at 12:34 AM, Vitaly Kuzmichev wrote:
> Hi Lei,
>
> Lei Wen wrote:
>> Since the ether may not be the only one usb gadget would be used
>> in the uboot, it is neccessary to do the register each time the
>> eth begin to work to make usb gadget driver less confussed whe
On Thu, Dec 2, 2010 at 5:45 PM, Becky Bruce wrote:
> This is for boards that use the SDRAM mode on the LBC but don't
> require any additional setup.
>
> I'm merging all the initdram() calls into a single function for 85xx,
> and have to be able to distinguish between boards that require an
> sdram
On Thu, 2 Dec 2010 18:19:08 -0600
Kumar Gala wrote:
> [Adding Scott W. - would like his ack on this]
Acked-by: Scott Wood
>
> - k
>
> On Dec 2, 2010, at 11:43 AM, Peter Tyser wrote:
>
> > From: John Schmoller
> >
> > According to Freescale reference manuals (eg section "13.4.4.2
> > Progr
On Dec 2, 2010, at 10:50 AM, Peter Tyser wrote:
> Hi Kumar,
>
>> Signed-off-by: Kumar Gala
>
> Acked-by: Peter Tyser
> Tested-by: Peter Tyser
>
>
>
>> index e0a1fa4..9d87eaf 100644
>> --- a/include/configs/xpedite537x.h
>> +++ b/include/configs/xpedite537x.h
>> @@ -375,6 +375,12 @@ extern
[Adding Scott W. - would like his ack on this]
- k
On Dec 2, 2010, at 11:43 AM, Peter Tyser wrote:
> From: John Schmoller
>
> According to Freescale reference manuals (eg section "13.4.4.2
> Programming the UPMs" of the P4080 Reference Manual):
>
> "Since the result of any update to the MxMR/
Correct initdram to use phys_size_t to represent the size of
dram; instead of changing this all over the place, and correcting
all the other random errors I've notived, create a
common initdram that is used by all non-corenet 85xx parts. Most
of the initdram() functions were identical, with 2 comm
This config option is for an erratum workaround; rename it to be more
clear. Also, drop it from config files don't need it and were
undefining it.
Signed-off-by: Becky Bruce
---
arch/powerpc/cpu/mpc85xx/cmd_errata.c |3 +++
arch/powerpc/cpu/mpc85xx/cpu.c|2 +-
doc/README.mpc85xx
Neither of these parts should have the erratum this is meant to
work around. Delete it.
Signed-off-by: Becky Bruce
---
include/configs/MPC8568MDS.h |1 -
include/configs/MPC8569MDS.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/configs/MPC8568MDS.h b/incl
This is used to distinguish between boards that require extra setup
to use LBC sdram, and those that don't
Signed-off-by: Becky Bruce
---
include/configs/SBC8540.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/SBC8540.h b/include/configs/SBC8540.h
ind
This is needed to distinguish between boards with lbc sdram
that require additional initialization and those that do not.
Signed-off-by: Becky Bruce
---
include/configs/stxgp3.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/stxgp3.h b/include/configs/
This board does not actually configure anything for SDRAM - change
the name to avoid confusion and make it easier to go to a common
initdram going forward.
Signed-off-by: Becky Bruce
---
board/pm856/law.c |5 ++---
board/pm856/tlb.c |4 ++--
include/configs/PM856.h |6 +--
Also, change this code to use phys_size_t instead of long int.
Using common naming for this function will enable us to use the common
initdram() for 85xx going forward. Other than the type change,
this is just a code rearrange.
Signed-off-by: Becky Bruce
---
board/tqc/tqm85xx/sdram.c | 37 +++
This will help us go to a fixed initdram() for all 85xx boards going
forward. sdram_setup() had an argument that it didn't need, since the
value was #defined.
Signed-off-by: Becky Bruce
---
board/socrates/sdram.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/
This patch series consists of a bunch of cleanups that allow us to use
a common initdram() on all of the non-corenet 85xx-based boards. Also,
switch to using phys_size_t to represent the size of memory returned.
Most of these patches are just code rearranges or renaming things to
get a common sc
As far as I can tell, this board doesn't actually configure the LBC
for SDRAM. I've renamed this to avoid confusion (and to make the
initdram() cleanup easier later.)
Signed-off-by: Becky Bruce
---
board/pm854/law.c |5 ++---
board/pm854/tlb.c |4 ++--
include/configs/PM854.
This is for boards that use the SDRAM mode on the LBC but don't
require any additional setup.
I'm merging all the initdram() calls into a single function for 85xx,
and have to be able to distinguish between boards that require an
sdram_init() function, and those that do not. We could have defined
Some platforms might want to override the default wimge=0 for
DDR. Add CONFIG_DDR_TLB_WIMGE for those platforms to use.
This will initially only be used by TQM85xx, but could be
useful for other boards or testing going forward.
Signed-off-by: Becky Bruce
---
arch/powerpc/cpu/mpc85xx/tlb.c |
Modeled after the MPC8540DS code; this will allow us to use a common
initdram() once that is available. There should be no functional
change.
Signed-off-by: Becky Bruce
---
board/mpc8540eval/mpc8540eval.c | 64 +-
1 files changed, 35 insertions(+), 29 delet
This isn't used - delete it.
Signed-off-by: Becky Bruce
---
include/configs/MPC8569MDS.h |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/include/configs/MPC8569MDS.h b/include/configs/MPC8569MDS.h
index c7973b4..720b5b6 100644
--- a/include/configs/MPC8569MDS.h
+++
> Some of the times, the boot hung after printing DRAM: 128 MiB,
> but never did it hang without printing anything.
The same here.
Beagleboard xM rev.A hangs after DRAM: 256 MiB
Regards,
--
Carlo Caione
___
U-Boot mailing list
U-Boot@lists.denx.de
http
Le 02/12/2010 21:27, Jens Scharsig a écrit :
>> I suggest visually running through all (board or cpu-specific) code that
>> runs as part of execution board_init_f() and checking that no global is
>> ever used -- BSS or initialized.
>
> Andreas mirror BSS check says OK, But the board hangs on write
Dear Albert ARIBAUD,
>
>> A second problem, the board does not restart (reset command).
>> I find out that a NULL pointer used by reset code, was also
>> relocated.
>
> How did you come to this conclusion? NULL pointers are constants and
> thus are *not* relocated.
This problem will be gone wit
Hi Kumar,
> #elif defined (CONFIG_MPC85xx)
> #include
> -#define _POST_WORD_ADDR (CONFIG_SYS_IMMR + offsetof(ccsr_pic_t, tfrr))
> +#define _POST_WORD_ADDR (CONFIG_SYS_IMMR +
> CONFIG_SYS_MPC85xx_PIC_OFFSET + \
> + offsetof(ccsr_pic_t, tfrr))
> #elif defin
Hi Albert,
On 12/01/2010 08:42 AM, Albert ARIBAUD wrote:
> Hi Darius,
>
> Le 30/11/2010 10:19, Darius Augulis a écrit :
>
>> I understand, that there is such rule in u-boot, but it's ... at least
>> strange.
>> Even linux kernel doesn't use such approach and uses simple defines instead.
>> One bi
Hi Wolfgang,
On 12/02/2010 11:13 AM, John Rigby wrote:
> On Tue, Nov 30, 2010 at 8:00 AM, Wolfgang Denk wrote:
>> Hello everybody.
>>
>> I apologise for being a bit late with this announcement:
>>
>> * U-Boot v2010.12-rc2 was released on Sunday, November 28.
>>
>> * Release "v2010.12" is (still)
From: Matt Waddel
This patch fixes build errors in the vexpress system:
- Removed sys_proto.h requirement from syslib.c.
- Switched vexpress to the default armv7 linker script.
- Renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE.
Signed-off-by: Matt Waddel
---
Change log v2:
Removed the new arch
Le 02/12/2010 19:51, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cf7c7f4.6030...@free.fr> you wrote:
>>
>>> Well, an u8 is as good a data type as any other. The available range
>>> of 0...255 seems more than sufficient to store the needed
>>> information, so why should I waste 4
Am 30.11.2010 20:45, schrieb Andreas Bießmann:
> From: Andreas Bießmann
>
> Signed-off-by: Andreas Bießmann
> ---
I can confirm this patch. It works with eb+cpux9k2 board.
regard Jens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/
Dear Albert ARIBAUD,
In message <4cf7c7f4.6030...@free.fr> you wrote:
>
> > Well, an u8 is as good a data type as any other. The available range
> > of 0...255 seems more than sufficient to store the needed
> > information, so why should I waste 4 bytes of storage when a single
> > byte is suffici
On Tue, Nov 30, 2010 at 8:00 AM, Wolfgang Denk wrote:
> Hello everybody.
>
> I apologise for being a bit late with this announcement:
>
> * U-Boot v2010.12-rc2 was released on Sunday, November 28.
>
> * Release "v2010.12" is (still) scheduled in 13 days:
> on December 13, 2010.
>
> Please help te
Scott Wood wrote:
> If you were to immediately follow it with out_8 as currently defined,
> yes. But setbits_8 should be OK.
I don't want my flash_writeX functions to make any assumptions about what
set_mux_to_diu() does. Can I just replace the __raw_readb() with an in_8()?
--
Timur Tabi
Linux
From: John Schmoller
According to Freescale reference manuals (eg section "13.4.4.2
Programming the UPMs" of the P4080 Reference Manual):
"Since the result of any update to the MxMR/MDR register must be in
effect before the dummy read or write to the UPM region, a write to
MxMR/MDR should be fol
Hi Kumar,
> Signed-off-by: Kumar Gala
Acked-by: Peter Tyser
Tested-by: Peter Tyser
> index e0a1fa4..9d87eaf 100644
> --- a/include/configs/xpedite537x.h
> +++ b/include/configs/xpedite537x.h
> @@ -375,6 +375,12 @@ extern unsigned long get_board_ddr_clk(unsigned long
> dummy);
> #define CO
Hi Lei,
Lei Wen wrote:
> Since the ether may not be the only one usb gadget would be used
> in the uboot, it is neccessary to do the register each time the
> eth begin to work to make usb gadget driver less confussed when
> we want to use two different usb gadget at the same time.
>
> Usb gadget
Le 02/12/2010 14:58, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cf7922b.3020...@free.fr> you wrote:
>>
>> Now, on an unrelated note, omap3_emv's code arbitrarily uses an u8 where
>> an int (or enum) would be more appropriate, and this should be changed
>> not because it removes
Hi Wolfgang,
sorry for the late reply. I just "stumbled" again over this mail.
On Monday 01 November 2010 20:05:00 Wolfgang Denk wrote:
> I still wonder what's the logic behind this code. When will
> read_block() return -ENOENT (aka "No such file or directory") ?
> What are the other possible err
Yaffs image require to use the oob to store some info, so when we
burn the yaffs image, we need to also write the image's oob part
into flash.
This patch add addition suffix to onenand write to give the uboot
the power to directly burn the yaffs image to onenand.
Signed-off-by: Lei Wen
---
comm
Am 02.12.2010 14:33, schrieb zfsdk:
>
> Maybe in init sequens asm func, i used turn on led to check which func faild.
>
Using a LED for debugging is time consuming. And you won't see which
code still uses BSS before relocation as such code does not have to fail
(it still might work). I prefer re
Seems original implementation forget to set the pointer to point
to the oobbuf, so when we want to see oob buf, we see nothing...
Fix it by get pointer as the oobbuf set.
Signed-off-by: Lei Wen
---
common/cmd_onenand.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/com
On 02/12/10 14:18, Ben Gardiner wrote:
> Hi Nick,
>
> On Thu, Dec 2, 2010 at 8:57 AM, Nick Thompson wrote:
>> This change allows the davinci timer functions to be used before
>> relocation since it avoids using static variables prior to BSS being
>> made available.
>> Signed-off-by: Nick Thompso
Hi Nick,
On Thu, Dec 2, 2010 at 8:57 AM, Nick Thompson wrote:
> This change allows the davinci timer functions to be used before
> relocation since it avoids using static variables prior to BSS being
> made available.
>
> The code is based on that used in the at91 timers, modified to use
> a davi
The link_name variable is declared inside the if block and it is used
outside it through the name pointer.
Signed-off-by: Ricardo Ribalda Delgado
---
fs/ubifs/ubifs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/ubifs/ubifs.c b/fs/ubifs/ubifs.c
index 0f8128c..2bad
Dear "Premi, Sanjeev",
In message you
wrote:
>
> > Do you still need to remove the $(sort) call for the LIBS? That
> > should NOT be done.
...
> I know it shouldn't be done - but just trying to take problem one by
> one. Unless you want me to report the problems onl after I have a fix
> for the
Dear Albert ARIBAUD,
In message <4cf7922b.3020...@free.fr> you wrote:
>
> Now, on an unrelated note, omap3_emv's code arbitrarily uses an u8 where
> an int (or enum) would be more appropriate, and this should be changed
> not because it removes a linker warning, but because the u8 choice is
> a
This change allows the davinci timer functions to be used before
relocation since it avoids using static variables prior to BSS being
made available.
The code is based on that used in the at91 timers, modified to use
a davinci specific hardware timer. It also maintains reset_timer()
to allow depre
Maybe in init sequens asm func, i used turn on led to check which func faild.
--
View this message in context:
http://old.nabble.com/-U-Boot--OMAP3%3A-relocation-and-bss-usage-%28timer%2C-gpmc%2C-...%29-tp30341173p30358424.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
__
Hi Nick,
On Thu, Dec 2, 2010 at 4:39 AM, Nick Thompson wrote:
> I have changed the davinci timer code to work with the, originally at91
> only, gd variables:
>
> unsigned long timer_rate_hz;
> unsigned long tbl;
> unsigned long tbu;
> unsigned long long time
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Thursday, December 02, 2010 5:07 PM
> To: Premi, Sanjeev
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] omap3evm: Clean-up EVM detection code.
>
> Dear Sanjeev Premi,
>
> In message <1291288812-12653-1-g
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Thursday, December 02, 2010 5:09 PM
> To: Premi, Sanjeev
> Cc: Albert ARIBAUD; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
>
> Dear "Premi, Sanjeev",
>
Le 02/12/2010 13:01, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cf7896b.5090...@free.fr> you wrote:
>>
>> Note that initialization should be unnecessary if the static variable is
>> int rather than u8.
>
> It should ALWAYS be not necessary.
I understand your point re: the link
Dear Albert ARIBAUD,
In message <4cf7896b.5090...@free.fr> you wrote:
>
> Note that initialization should be unnecessary if the static variable is
> int rather than u8.
It should ALWAYS be not necessary.
Otherwise we have a bug, and that bug needs to be fixed rather than
papered over.
Best reg
Le 02/12/2010 12:37, Wolfgang Denk a écrit :
> Dear Sanjeev Premi,
>
> In message<1291288812-12653-1-git-send-email-pr...@ti.com> you wrote:
>> This patch does following changes:
>>* Change the type (u8 -> int) for omap3_evm_version.
>>* Introduce an 'undefined' board revision for init
>>
On 01/12/10 12:16, Prafulla Wadaskar wrote:
> After ARM relocation,
> any code executed directly or indirectly by board_init_f() have
> global (BSS) variables need to be fixed. mostly timer.c needs to
> fix on most of the ARM platforms.
>
> This patch makes timer related variables in gd_t availabl
Dear "Premi, Sanjeev",
In message you
wrote:
>
> Just posted the patch. The u-boot comes up on the EVM - only after
> sort related change in the Makefile. Haven't debuged it yet.
Could you ***please*** be a bit more precise?
What EXACTLY was that "sort related change"?
Do you still need to re
Dear Sanjeev Premi,
In message <1291288812-12653-1-git-send-email-pr...@ti.com> you wrote:
> This patch does following changes:
> * Change the type (u8 -> int) for omap3_evm_version.
> * Introduce an 'undefined' board revision for init
> value.
> * Use of #define instead of magic numbers
Dear Lei Wen,
In message you
wrote:
> Do we really need this? I think the better way to configure GPIO MFP
> is doing like below.
> That is create each GPIO name, and define its MFPD and MFP_AF.
>
> > +/* UART2 */
> > +#define MFP47_UART2_RXDMFPD(47) | MFP_AF(6)
> > +#define MFP
Dear Prafulla Wadaskar,
In message
you wrote:
>
> > Since the mfp.c is for generic case, and should be made as generic at
> > the beginning...
>
> Sure.. but I don't know how it will be on other SoCs?
> Apart from that what would be other impact?
> So in my opinion, let's keep it for future up
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Thursday, December 02, 2010 2:12 PM
> To: Premi, Sanjeev
> Cc: Wolfgang Denk; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
>
> Hi Sanjeev,
>
>
Dear Prafulla Wadaskar,
In message <1291302695-15561-1-git-send-email-prafu...@marvell.com> you wrote:
> Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
> For ex. ARMADA100.
>
> These registers are programmed to expose the specific functionality
> associated with res
This patch does following changes:
* Change the type (u8 -> int) for omap3_evm_version.
* Introduce an 'undefined' board revision for init
value.
* Use of #define instead of magic numbers
Signed-off-by: Sanjeev Premi
---
board/ti/evm/evm.c | 39 +++
Hi Prafulla,
On Thu, Dec 2, 2010 at 11:11 PM, Prafulla Wadaskar wrote:
> This patch adds the support MFP support for Marvell ARMADA100 SoCs
>
> Signed-off-by: Prafulla Wadaskar
> ---
> Change log v3 REPOST:
> macro MFPR_PTR_UPDATE added
>
> arch/arm/include/asm/arch-armada100/mfp.h | 231
> ++
Dear Prafulla Wadaskar,
In message <1291302695-15561-2-git-send-email-prafu...@marvell.com> you wrote:
> This patch adds the support MFP support for Marvell ARMADA100 SoCs
>
> Signed-off-by: Prafulla Wadaskar
> ---
> Change log v3 REPOST:
> macro MFPR_PTR_UPDATE added
>
> arch/arm/include/asm/
This patch adds the support MFP support for Marvell ARMADA100 SoCs
Signed-off-by: Prafulla Wadaskar
---
Change log v3 REPOST:
macro MFPR_PTR_UPDATE added
arch/arm/include/asm/arch-armada100/mfp.h | 231 +
1 files changed, 231 insertions(+), 0 deletions(-)
create mo
Most of the Marvell SoCs has Multi Function Pin (MFP) configuration registers
For ex. ARMADA100.
These registers are programmed to expose the specific functionality
associated with respective SoC Pins
This driver provides configuration APIs,
using them, configuration need to be done in board spec
Mark,
Please do not write your answers above the text you answer to (i.e., do
not top-post)
Le 02/12/2010 10:48, Mark Underwood a écrit :
> Hi!
>
> thanks for your quick replys. More helpful than the manufacturer thats
> for sure.
>
> I totally admit that im a newbie at all this, so sorry if I d
Hi!
thanks for your quick replys. More helpful than the manufacturer thats
for sure.
I totally admit that im a newbie at all this, so sorry if I dont
understand things.
I was under the impression that the MAC address was supplied by the
hardware supplier. (at least this seems to be the can
I have changed the davinci timer code to work with the, originally at91
only, gd variables:
unsigned long timer_rate_hz;
unsigned long tbl;
unsigned long tbu;
unsigned long long timer_reset_value;
It does use the timer_reset_value to keep compatibility w
Hi Sekhar,
> Hmm, I had tested DA850 EVM yesterday with U-Boot 2010.12-rc2,
> and was able to successfully boot (at least most of the times).
>
> ---logs
> Booting with TI UBL
> Device OPP (300MHz, 1.2V)
>
> U-Boot 2010.12-rc2 (Nov 30 2010 - 11:55:35)
>
> I2C: ready
> DRAM: 128 MiB
> Using
Dear Albert ARIBAUD,
In message <4cf7583c.7000...@free.fr> you wrote:
>
> > Does it help when you change the "*(.bss)" in
> > "arch/arm/cpu/armv7/u-boot.lds" into "*(.*bss)"
> > (so it also includes any .sbss objects) ?
>
> No change.
Hm... Maybe it is indeed not a good idea to mix short object
Hi Sanjeev,
Le 02/12/2010 09:30, Premi, Sanjeev a écrit :
>> -Original Message-
>> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
>> Sent: Thursday, December 02, 2010 1:57 PM
>> To: Wolfgang Denk
>> Cc: u-boot@lists.denx.de; Premi, Sanjeev
>> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Thursday, December 02, 2010 1:57 PM
> To: Wolfgang Denk
> Cc: u-boot@lists.denx.de; Premi, Sanjeev
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
[snip]
>
> So Sanj
Le 02/12/2010 09:13, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4cf74fed.2030...@free.fr> you wrote:
>>
>> BTW... Why on Earth is it an uint8? Probably a space saving measure, but
>> one I think is not really fruitful, because of probable paddings and
>> alignments; making it an
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Thursday, December 02, 2010 12:30 PM
> To: u-boot@lists.denx.de
> Cc: Premi, Sanjeev; Wolfgang Denk
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
>
> Le 01/12/2010 2
> -Original Message-
> From: Albert ARIBAUD [mailto:albert.arib...@free.fr]
> Sent: Thursday, December 02, 2010 1:21 PM
> To: Wolfgang Denk
> Cc: u-boot@lists.denx.de; Premi, Sanjeev
> Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across
> toolchain versions
>
> Hi Wolfgang,
>
Dear Albert ARIBAUD,
In message <4cf74fed.2030...@free.fr> you wrote:
>
> BTW... Why on Earth is it an uint8? Probably a space saving measure, but
> one I think is not really fruitful, because of probable paddings and
> alignments; making it an int would allow using smsc_id directly as
> value
87 matches
Mail list logo
