Hello Albert,
Albert ARIBAUD wrote:
> Le 02/10/2010 22:39, Reinhard Meyer a écrit :
>
>> And as an idea, if position independent code is used, only pointers
>> in initialized data need adjustment. Cannot the linker emit a table
>> of addresses that need fixing?
>
> IIU Bill C, yes the linker can
Hello Wolfgang,
Wolfgang Denk wrote:
> Dear Reinhard Meyer,
>
> In message <4ca79896.2010...@emk-elektronik.de> you wrote:
>> I agree here. _If_ relocation, it should work without hand-adding
>> fixup stuff to all functions using initialized data with pointers.
>> Even Wolfgang forgot to fixup hi
Hello Albert,
Albert ARIBAUD wrote:
> Le 03/10/2010 20:03, Wolfgang Denk a écrit :
>
>> Dear Reinhard Meyer,
>>
>> In message<4ca6e8e5.2090...@emk-elektronik.de> you wrote:
And yes, this means the content arrays of pointers such as init_sequence
is not relocated. Been there, done that,
Hello Hiremath,
Hiremath, Vaibhav wrote:
> Hi All,
>
> I think the current denx/matser is broken and is not building up for OMAP3
> platforms except Beagle board.
but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC
or compile with:
"CONFIG_SYS_ARM_WITHOUT_RELOC=1 ./MAKEALL boar
>
> Hi Wolfgang,
>
>
>
> > Well, please keep in mind that all this code is working find on
> > PowerPC, which has been using relocation right from the beginning.
> >
> > It is my understanding that we don't suffer from this issue any more
> > on PPC - Peter Tyser posted relocation fixup patches fo
I wrote:
> Dear Wolfgang Denk,
>> In message <4ca5d26d.2090...@emk-elektronik.de> you wrote:
If this is really for all AT91 SoCs, then please feel free to
introduce a common define (CONFIG_SYS_AT91 ?) and use that. Eventually
you can clean up some other such #if's on the way.
>>> Tha
>
> Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
>
> > However, I think we will loose the possibility to add "link once, burn and
> run anywhere"
> > feature I impl. once(but it was at the time deemed to intrusive) if
> > we skip -fPIC and go for the linker -pie relocation.
>
> On ARM at least,
Dear Mike Frysinger, All:)
> On Tuesday, September 14, 2010 10:50:09 Reinhard Meyer wrote:
>> JEDEC types
>> non JEDEC types
>
> this changelog is useless ... either make it say something, or just leave it
> empty
>
>> +static int ramtron_common(struct spi_flash *flash,
>> +u32 offse
Dear Reinhard Meyer,
In message <4ca985dc.4000...@emk-elektronik.de> you wrote:
>
> The Qs that remain now are:
>
> 1. currently I see about 8 CONFIG_AT91SAMxxx defines required
> (not only 2 like above). The method is still undecided how to
> handle this. Add "CONFIG_AT91SAM9_FAMILY" to "common.
Le 04/10/2010 08:08, Heiko Schocher a écrit :
> Hello Albert,
>
> Albert ARIBAUD wrote:
>> Le 03/10/2010 20:03, Wolfgang Denk a écrit :
>>
>>> Dear Reinhard Meyer,
>>>
>>> In message<4ca6e8e5.2090...@emk-elektronik.de> you wrote:
> And yes, this means the content arrays of pointers such as in
Dear Marek Vasut,
In message <201010040224.35419.marek.va...@gmail.com> you wrote:
>
> The data section isn't writable, right ?
The data section is (officially) writable only after relocation.
This rule has the situation in mind that U-Boot starts runnng from
some form of ROM (like NOR flash). I
Dear Reinhard Meyer,
In message <4ca974b5.8030...@emk-elektronik.de> you wrote:
>
> I am unsure whether currently I should put further effort into this, because
> this
> won't work on architectures with incomplete relocation. The pointers in the
> "probe" table would need relocation fixups otherw
Dear Peter Tyser,
In message <1286167382.22760.19.ca...@ptyser-laptop> you wrote:
>
> > Peter, could you please fill in the details of that old story?
>
> I haven't been following the ARM relocation thread very closely, but a
> summary of the PPC relocation is:
> - Prior to commit 858290178f222d
On 10/4/2010 4:14 PM, Wolfgang Denk wrote:
> Dear Vipin Kumar,
>
> In message <4ca9acaa.2020...@st.com> you wrote:
>>
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
>>>
>>> I
Dear Vipin Kumar,
In message <4ca9a095.9000...@st.com> you wrote:
>
> I encountered a problem something like
>
> struct xyz {
> int x;
> int y;
> int z[CONST];
> } __attribute__ ((packed));
>
> struct xyz *abc;
> u32 * status_reg = (u32 *)&abc->z[0];
>
> writel(st
Dear Albert ARIBAUD,
In message <4ca999ee.5030...@free.fr> you wrote:
>
> Note however that linking for base address 0 is not mandatory for
> achieving true position independence. What is required is that the code
> which runs from power-up until relocation be able to run anywhere, i.e.,
> this
Dear Reinhard Meyer,
In message <4ca995d7.5010...@emk-elektronik.de> you wrote:
>
> >> Maybe there is a misunderstanding here. I see three patches
> >>
> >> 1. introduce CONFIG_AT91SAM9_FAMILY to common.h
> >>
> >> 2. add an #ifdef CONFIG_AT91SAM9_FAMILY to global_data.h with the
> >> required var
Dear Wolfgang Denk,
>> The Qs that remain now are:
>>
>> 1. currently I see about 8 CONFIG_AT91SAMxxx defines required
>> (not only 2 like above). The method is still undecided how to
>> handle this. Add "CONFIG_AT91SAM9_FAMILY" to "common.h"? Or put
>> all 8 defined() into "global_data.h" (would g
Dear Reinhard Meyer,
In message <4ca9be94.6000...@emk-elektronik.de> you wrote:
>
> Do you imply that the code is really different when the pointer gets
> its value by assigning it NOT to a packed entity? Hard to believe.
This is a special "feature" of GCC on ARM.
-> cat foo.c
#define writel(v,a
Remove uneccessary functions to access the TCR/TSR registers as well.
Signed-off-by: Stefan Roese
---
arch/powerpc/cpu/ppc4xx/cpu_init.c |8
arch/powerpc/cpu/ppc4xx/interrupts.c |7 ---
arch/powerpc/cpu/ppc4xx/traps.c | 11 +--
3 files changed, 5 insertions(
Hello Rogan,
Rogan Dawes wrote:
> On 2010/10/04 8:00 AM, Heiko Schocher wrote:
>> Hello Hiremath,
>>
>> Hiremath, Vaibhav wrote:
>>> Hi All,
>>>
>>> I think the current denx/matser is broken and is not building up for OMAP3
>>> platforms except Beagle board.
>> but they should compile if you defi
Dear Wolfgang Denk,
I see the misunderstanding here:
> It will be needed to replace the "#if defined(CONFIG_AT91SAM9260) ||
> defined(CONFIG_AT91SAM9XE)" in global_data.h and a ton of similar
> ocurrences like these:
That does not exist yet (its only in my local tree so far!)
> arch/arm/cpu/arm
On 04/10/10 20:54, Sergei Shtylyov wrote:
> Hello.
>
> On 04-10-2010 7:37, Graeme Russ wrote:
>
>> The header of recent Linux Kernels includes the size of the image, and
>> therefore is not needed to be passed to zboot. Still process the third
>> parameter (size of image) in the event that an old
On 04/10/10 19:28, Albert ARIBAUD wrote:
> Le 04/10/2010 09:27, Reinhard Meyer a écrit :
>> Dear Albert ARIBAUD,
>>>
>>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
Any reason to do it in assembl
Dear Vipin Kumar,
In message <4ca9b316.3050...@st.com> you wrote:
>
> >>> Hm... Why do these structs have any "__attribute__ ((packed))" at all?
> >>
> >> Even I could not understand that very well
> >
> > Eventually alignment of these structs cannot be guaranteed?
>
> In my opinion it can be gu
Dne Po 4. října 2010 06:43:45 Wolfgang Denk napsal(a):
> Dear Marek Vasut,
>
> In message <201010040136.27940.marek.va...@gmail.com> you wrote:
> > Dne Po 20. zá#í 2010 03:57:25 Marek Vasut napsal(a):
> > > This fixes TIMEOUT with my Kingston 32GB USB3.0 flashdrive, which I
> > > experienced on my
>
> Le 04/10/2010 10:57, Heiko Schocher a écrit :
>
> >> ./MAKEALL edminiv2 results:
> >>
> >> text databssdechexfilename
> >> 141376 4388 16640 162404 27a64./u-boot (for GOT
> >> reloc)
> >> 150160 3819 16640 170619
Dear Wolfgang Denk and Reinhard Meyer,
The compiler (4.4.1) generates the expected 32bit store instruction when using:
struct p {
int n;
} __attribute__ ((packed, aligned(4)));
In case of hardware registers, I have yet to see a case where this is not true.
Regards,
Francesco
On Mon, Oc
Do you have the general materials about DDR programming in u-boot?
Thanks!
Shuyou
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Heiko,
[...]
>> Surely having e.g.
>>
>> #if (not fixed config)
>> #error See http://blah/blah/blah for information about how to fix your board
>> #endif
>>
>> would be more beneficial than an obscure compiler failure that doesn't
>> even reference useful keywords?
>
> but that would result
Dear Detlev Zundel,
In message you wrote:
>
> > but that would result in editing *all* config files, which are not
> > coverted.
>
> Are you sure? Isn't there some central place in arm land where board.h
> is included? Such an ifdef there would catch all configs or what am I
> missing?
Any c
Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> In message <4ca9be94.6000...@emk-elektronik.de> you wrote:
>> Do you imply that the code is really different when the pointer gets
>> its value by assigning it NOT to a packed entity? Hard to believe.
>
> This is a special "feature" of GCC on ARM.
>
Hello Richard,
Richard Retanubun wrote:
>>> Follow up to commit 620f1f6a64095ed558e68d37f1965d015cd49b02
>>> removed compiler warning for (now) unused cmd_tbl_t* cmdtp
>>> ---
>>>
>>> Hi Heiko,
>>>
>>> Not sure if you caught this one already, just a simple unused variable
>>> cleanup
>> Thanks, bu
Hello Detlev,
Detlev Zundel wrote:
> Hi Heiko,
>
> [...]
>
>>> Surely having e.g.
>>>
>>> #if (not fixed config)
>>> #error See http://blah/blah/blah for information about how to fix your board
>>> #endif
>>>
>>> would be more beneficial than an obscure compiler failure that doesn't
>>> even ref
On Tuesday 28 September 2010 23:15:14 tma...@apm.com wrote:
> From: Tirumala Marri
>
> APM821XX is a new line of SoCs which are derivatives of
> PPC44X family of processors. This patch adds support of CPU, cache,
> tlb, 32k ocm, bootstraps, PLB and AHB bus.
Applied to u-boot-ppc4xx/master. Thank
Le 04/10/2010 10:52, Joakim Tjernlund a écrit :
> Albert ARIBAUD wrote on 2010/10/04 10:33:05:
>>
>> Le 04/10/2010 10:28, Joakim Tjernlund a écrit :
Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
> However, I think we will loose the possibility to add "link once, burn and
Dear Joakim Tjernlund,
In message
you
wrote:
>
> However, I think we will loose the possibility to add "link once, burn and
> run anywhere"
> feature I impl. once(but it was at the time deemed to intrusive) if
> we skip -fPIC and go for the linker -pie relocation.
>
> I would suggest to leave
>> Follow up to commit 620f1f6a64095ed558e68d37f1965d015cd49b02
>> removed compiler warning for (now) unused cmd_tbl_t* cmdtp
>> ---
>>
>> Hi Heiko,
>>
>> Not sure if you caught this one already, just a simple unused variable
>> cleanup
>
> Thanks, but already fixed in arch/arm/lib/board.c
>
> bye,
Le 04/10/2010 10:28, Joakim Tjernlund a écrit :
>>
>> Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
>>
>>> However, I think we will loose the possibility to add "link once, burn and
>> run anywhere"
>>> feature I impl. once(but it was at the time deemed to intrusive) if
>>> we skip -fPIC and go f
Albert ARIBAUD wrote on 2010/10/04 10:33:05:
>
> Le 04/10/2010 10:28, Joakim Tjernlund a écrit :
> >>
> >> Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
> >>
> >>> However, I think we will loose the possibility to add "link once, burn and
> >> run anywhere"
> >>> feature I impl. once(but it was
On Wednesday 29 September 2010 17:22:32 Stefan Roese wrote:
> This patch fixes a bug in fdt_fixup_nor_flash_node() when the reg
> property has multiple reg tuples, like:
>
> reg = <0 0x 0x0400
> 0 0x0400 0x0400>;
>
> In this case this function did not update
On Wednesday 29 September 2010 17:22:45 Stefan Roese wrote:
> Signed-off-by: Stefan Roese
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phon
On Wednesday 29 September 2010 17:20:10 Stefan Roese wrote:
> From: Sascha Laue
>
> This patch brings the lwmon5 board support up-to-date. Here a
> summary of the changes:
>
> lwmon5 board port related:
> - GPIO's changed to control the LSB transmitter
> - Reset USB PHY's upon power-up
> - Enabl
On Wednesday 29 September 2010 17:21:08 Stefan Roese wrote:
> Signed-off-by: Stefan Roese
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phon
Le 04/10/2010 11:58, Graeme Russ a écrit :
> On 04/10/10 19:28, Albert ARIBAUD wrote:
>> Le 04/10/2010 09:27, Reinhard Meyer a écrit :
>>> Dear Albert ARIBAUD,
Right now I can build (not run, mind you) u-boot for edminiv2 without
-fPIC/-fPIE, with -pie and a modified u-boot.lds and s
Dear Reinhard Meyer,
In message <4ca99373.7020...@emk-elektronik.de> you wrote:
>
> > Patch 1 will change the #if and introduce CONFIG_AT91SAM9_FAMILY
> > instead.
> >
> > Patch 2 will fix at91/clock.c+timer.c
>
> Maybe there is a misunderstanding here. I see three patches
>
> 1. introduce CONF
On 04/10/10 20:59, Sergei Shtylyov wrote:
> Hello.
>
> On 04-10-2010 7:37, Graeme Russ wrote:
>
>> To allow for 'load anywhere' images, the %ebp return pointer 'hack' must
>> be removed, so we cannot have two 'calls' to get_mem_size
>
>> Signed-off-by: Graeme Russ
> [...]
>
>> diff --git a/arch
Le 04/10/2010 09:27, Reinhard Meyer a écrit :
> Dear Albert ARIBAUD,
>>
>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
>> of the .rel.dyn fixup entries are type 23, that is, relative to the base
>>
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: Monday, October 04, 2010 12:08 AM
> To: Hiremath, Vaibhav
> Cc: Albert ARIBAUD; u-boot@lists.denx.de
> Subject: Re: [U-Boot] denx/master is not building for OMAP3 platforms
> except Beagle
>
> Dear "Hiremath, Vaibhav
Hi ame,
On Friday 01 October 2010 17:36:39 ame wrote:
> > Ok, confirmed the new one has it in there. sorry about that. The logic
> > is the same as the one that is in the old code though.
>
> Well, ok, kind of. cpu.c is correct, cpu_init.c that actually sets up the
> watchdog timer is not tho
Dear Graeme Russ,
In message <4ca9a70b.6030...@gmail.com> you wrote:
>
> >> +#if CONFIG_SYS_SDRAM_ECC_ENABLE
> >> +/* Skip ECC initialization if not starting from cold-reset */
> >> +movl%ebx, %ecx
> >> +andl$GD_FLG_COLD_BOOT, %ecx
> >> +jzecc_init_ret
> >
> >But t
Le 04/10/2010 08:40, Albert ARIBAUD a écrit :
> Right now I can build (not run, mind you) u-boot for edminiv2 without
> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
> of the .rel.dyn fixup entries are type 23, that is, relative to the base
> address, which is good. Howe
Hi Sergey,
> It is already 5th or more same spam email in a row. Does anybody care?
Yes I do, thanks for the reminder.
Cheers
Detlev
--
Less talking -- more hacking
-- Olin Shivers
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zund
Le 04/10/2010 09:36, Joakim Tjernlund a écrit :
> However, I think we will loose the possibility to add "link once, burn and
> run anywhere"
> feature I impl. once(but it was at the time deemed to intrusive) if
> we skip -fPIC and go for the linker -pie relocation.
On ARM at least, I don't think
Hello Albert,
Albert ARIBAUD wrote:
> Le 04/10/2010 09:27, Reinhard Meyer a écrit :
>> Dear Albert ARIBAUD,
>>>
>>> Right now I can build (not run, mind you) u-boot for edminiv2 without
>>> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
>>> of the .rel.dyn fixup entries a
In message <1285752572-2107-1-git-send-email...@denx.de> you wrote:
> Signed-off-by: Wolfgang Denk
> ---
> doc/feature-removal-schedule.txt | 29 -
> 1 files changed, 28 insertions(+), 1 deletions(-)
Applied (with fixes as discussed here).
Best regards,
Wolfgang D
Le 04/10/2010 10:57, Heiko Schocher a écrit :
>> ./MAKEALL edminiv2 results:
>>
>> text databssdechexfilename
>> 141376 4388 16640 162404 27a64./u-boot (for GOT
>> reloc)
>> 150160 3819 16640 170619 29a7b./u-
The following changes since commit dd09985499ac95484974eb0f832fe47b33369952:
hmi1001, mucmc52, uc100, uc101: move boards to vendor directory (2010-10-04
10:58:38
+0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-ppc4xx.git master
Rupjyoti Sarmah (1):
ppc44x:
Changes from V1 to V2:
- Add a configuration option for the LZO compression
- Add a comment line specifying the origin of the source code
In some case, LZO compression function is needed in U-Boot.
This patch supports LZO compression feature which is originated from Linux
kernel.
Thanks.
-Dongg
Dear Wolfgang Denk,
>>> Patch 1 will change the #if and introduce CONFIG_AT91SAM9_FAMILY
>>> instead.
>>>
>>> Patch 2 will fix at91/clock.c+timer.c
>> Maybe there is a misunderstanding here. I see three patches
>>
>> 1. introduce CONFIG_AT91SAM9_FAMILY to common.h
>>
>> 2. add an #ifdef CONFIG_AT91
Dear Albert ARIBAUD,
>
> Right now I can build (not run, mind you) u-boot for edminiv2 without
> -fPIC/-fPIE, with -pie and a modified u-boot.lds and start.S. Almost all
> of the .rel.dyn fixup entries are type 23, that is, relative to the base
> address, which is good. However, here are about
Dear Vipin Kumar,
A writel to status_reg results in byte by byte writing
>> How do you know that? Disassembly? Bus snooping?
>>
>
> Disassembly
>
>>> I agree with you. I always considered such behaviour of the ARM C
>>> compiler a bug, and still do. However, people with better knowledge
>>>
On 2010/10/04 4:17 PM, Albert ARIBAUD wrote:
> At this point I have an ARM926, ELF-relocating, u-boot reaching prompt.
>
> Environment is correctly read and can be modified (did not try saving
> though).
>
> Flash operations work (flinfo, erase, cp.b).
>
> Ethernet does not work, however -- pin
Dear Reinhard Meyer,
In message <4ca9cc04.5020...@emk-elektronik.de> you wrote:
>
> In a non-packed struct an int will never be unaligned
> (unless you use an unaligned pointer to the whole struct)
Which may happen for example when overlaying such a struct on top of
some I/O buffer.
> In a packe
Hi,
Prafulla Wadaskar writes:
> On guruplug+ if the uSD cards are inserted on both the slots (internal and
> external)
> The USB storage does not gets detected.
Yes, I figured out. I’m preparing a patch that adds support for
multi-LUN USB mass storage devices.
Thanks,
Ludo’.
On 2010/10/04 8:00 AM, Heiko Schocher wrote:
> Hello Hiremath,
>
> Hiremath, Vaibhav wrote:
>> Hi All,
>>
>> I think the current denx/matser is broken and is not building up for OMAP3
>> platforms except Beagle board.
>
> but they should compile if you define CONFIG_SYS_ARM_WITHOUT_RELOC
>
> or
Dear Wolfgang Denk,
In message <1282133657-28368-1-git-send-email...@denx.de> you wrote:
> Signed-off-by: Wolfgang Denk
> Cc: Heiko Schocher
> Cc: Stefan Roese
> Cc: Roderik Wildenburg
>
> ---
> board/{ => manroland}/hmi1001/Makefile |0
> board/{ => manroland}/hmi1001/config.mk
Dear Shinya Kuribayashi,
with all the discussion about relocation on ARM going on, Heiko and me
wondered if we had similar problems on MIPS. Unfortunately don't we
have to any MIPS board that could be used for testing.
Could you please tru and check if the current top-of-tree version of
U-Boot st
On 10/4/2010 3:47 PM, Wolfgang Denk wrote:
> Dear Vipin Kumar,
>
Dear Wolfgang
> In message <4ca9a095.9000...@st.com> you wrote:
>>
>> I encountered a problem something like
>>
>> struct xyz {
>> int x;
>> int y;
>> int z[CONST];
>> } __attribute__ ((packed));
>>
>> st
Dear Balau,
In message you
wrote:
>
> The compiler (4.4.1) generates the expected 32bit store instruction when
> using:
>
> struct p {
> int n;
> } __attribute__ ((packed, aligned(4)));
Confirmed. Thanks for pointing this out.
> In case of hardware registers, I have yet to see a ca
On Tuesday 28 September 2010 23:15:21 tma...@apm.com wrote:
> From: Tirumala Marri
>
> Add support code for bluestone board wth APM821XX processor based.
> This patch includes early board init, misc init, configure EBC,
> initializes UIC, MAKEALL, board.cfg and MAINTAINERS file.
Applied to u-boo
On Wednesday 29 September 2010 17:23:17 Stefan Roese wrote:
> I accidentally left these hacks in the code while doing the big header
> cleanup. Let's remove it now.
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
On Friday 01 October 2010 11:01:28 Rupjyoti Sarmah wrote:
> The GPIO 16 and 19 reconfiguration should be done once USB is initialized.
> So moved the reconfiguration to the USB init function.
Applied to u-boot-ppc4xx/master. Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wo
On Wednesday 29 September 2010 17:23:03 Stefan Roese wrote:
> This patch changes the PPC4xx POST UART driver to use the common
> NS16550 functions for receiving and sending. Additionally the
> local function for SoC divisor setup are removed. Instead the
> functions from arch/powerpc/cpu/ppc4xx/4xx
Dear Vipin Kumar,
In message <4ca9acaa.2020...@st.com> you wrote:
>
> >> This writel results in writing byte by byte on the address pointed to by
> >> status_reg.
> >> This problem is visible with both gcc version 4.4.1 as well as 4.5.0
> >
> > I bet this is on some ARM system?
>
> Yes, it is o
On 10/4/2010 4:26 PM, Reinhard Meyer wrote:
> Dear Wolfgang Denk, Vipin Kumar,
>>
>> In message <4ca9acaa.2020...@st.com> you wrote:
> This writel results in writing byte by byte on the address pointed to by
> status_reg.
> This problem is visible with both gcc version 4.4.1 as well as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Wolfgang Denk
since my board (Ben NanoNote) is mips.
so I test the those commands in my board.
printenv, saveenv: works fine.
env print, evn save: make U-Boot hang. (then I must reset the board)
- --
my board patch never touch the common/ folder.
Hello Xiangfu,
Xiangfu Liu wrote:
> Hi Wolfgang Denk
>
> since my board (Ben NanoNote) is mips.
> so I test the those commands in my board.
>
> printenv, saveenv: works fine.
> env print, evn save: make U-Boot hang. (then I must reset the board)
as I thought ... can you try following patch:
>F
Dear Wolfgang Denk, Vipin Kumar,
>
> In message <4ca9acaa.2020...@st.com> you wrote:
This writel results in writing byte by byte on the address pointed to by
status_reg.
This problem is visible with both gcc version 4.4.1 as well as 4.5.0
>>> I bet this is on some ARM system?
>> Ye
Hello.
On 04-10-2010 7:37, Graeme Russ wrote:
> The header of recent Linux Kernels includes the size of the image, and
> therefore is not needed to be passed to zboot. Still process the third
> parameter (size of image) in the event that an older kernel is being loaded
> Signed-off-by: Graeme Ru
Hi All,
I encountered a problem something like
struct xyz {
int x;
int y;
int z[CONST];
} __attribute__ ((packed));
struct xyz *abc;
u32 * status_reg = (u32 *)&abc->z[0];
writel(status, status_reg);
This writel results in writing byte by byte on the address
Hello.
On 04-10-2010 7:37, Graeme Russ wrote:
> To allow for 'load anywhere' images, the %ebp return pointer 'hack' must
> be removed, so we cannot have two 'calls' to get_mem_size
> Signed-off-by: Graeme Russ
[...]
> diff --git a/arch/i386/cpu/start.S b/arch/i386/cpu/start.S
> index cb47ce7..9
Dear Wolfgang Denk,
>
> I see the misunderstanding here:
>
>> It will be needed to replace the "#if defined(CONFIG_AT91SAM9260) ||
>> defined(CONFIG_AT91SAM9XE)" in global_data.h and a ton of similar
>> ocurrences like these:
>
> That does not exist yet (its only in my local tree so far!)
>
>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Heiko
by applied this patch. both works fine.
On 10/04/2010 10:49 PM, Heiko Schocher wrote:
> Hello Xiangfu,
>
> Xiangfu Liu wrote:
>> Hi Wolfgang Denk
>>
>> since my board (Ben NanoNote) is mips.
>> so I test the those commands in my board.
>>
Le 04/10/2010 16:25, Rogan Dawes a écrit :
> On 2010/10/04 4:17 PM, Albert ARIBAUD wrote:
>> At this point I have an ARM926, ELF-relocating, u-boot reaching prompt.
>>
>> Environment is correctly read and can be modified (did not try saving
>> though).
>>
>> Flash operations work (flinfo, erase, cp
On 10/4/2010 3:13 AM, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message<4ca999ee.5030...@free.fr> you wrote:
>> Note however that linking for base address 0 is not mandatory for
>> achieving true position independence. What is required is that the code
>> which runs from power-up until
Dear Heiko Schocher,
>> printenv, saveenv: works fine.
>> env print, evn save: make U-Boot hang. (then I must reset the board)
>
> as I thought ... can you try following patch:
>
Not surprisingly, it makes env subcommands work on ARM/AT91, too:)
Thanks,
Reinhard
PS: I still get the "*** Warnin
Le 04/10/2010 17:28, J. William Campbell a écrit :
> On 10/4/2010 3:13 AM, Wolfgang Denk wrote:
>> Dear Albert ARIBAUD,
>>
>> In message<4ca999ee.5030...@free.fr> you wrote:
>>> Note however that linking for base address 0 is not mandatory for
>>> achieving true position independence. What is requi
On Monday, October 04, 2010 09:02:26 sywang wrote:
> Do you have the general materials about DDR programming in u-boot?
do not hijack threads. start your own.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing
On Sat, 2 Oct 2010 14:50:23 +0200
Matthias Weißer wrote:
> Hi Scott
>
> Am 01.10.2010 21:52, schrieb Scott Wood:
> > On Fri, 1 Oct 2010 16:31:40 +0200
> >> MT29F16G08CBABA
> >> The NAND is connected (8 bit wide) to an iMX25 which is booting from
> >> NOR. So the NAND is only a mass storage devi
On Monday 04 October 2010 17:24:09 Albert ARIBAUD wrote:
> > Excellent work! Congratulations!
>
> Thanks, but I'd suggest to wait for congrats until ethernet works --
> tough I've got a clue, I think; it may have to do with the core
> activating its caches and the driver doing DMA. :)
Yes. Very l
Dear Marek Vasut,
In message <201010041602.04183.marek.va...@gmail.com> you wrote:
>
> > How do you expoect this to work? You did NOT add him to the Cc: list.
...
> I added him to CC in mail ... what else do you expect?
The message I received through the list did not contain any such Cc:
| Subje
Hello,
before the relocation patches, and if relocation is disabled
(CONFIG_SYS_ARM_WITHOUT_RELOC)
board_init() is called _very_ early, before relocation.
With relocation enabled, board_init() is called after relocation and
when BSS is available.
--->> Board maintainers should look at their boar
Dear Reinhard Meyer,
In message <4ca9eb88.5000...@emk-elektronik.de> you wrote:
>
> 1. The board's config file defines "CONFIG_AT91FAMILY" like this:
> /* SoC */
> #define CONFIG_ARM926EJS 1 /* ARM926EJS Core */
> #define CONFIG_AT91FAMILY 1 /* it's a member of A
Dear Xiangfu Liu,
In message <4ca9ec8e.9080...@openmobilefree.net> you wrote:
>
> by applied this patch. both works fine.
Thanks a lot for testing. This confirms that we have a more global
issue here, i. e. not only ARM is affected, but also MIPS.
Any MIPS tool chain experts out there to try an
On Monday, October 4, 2010, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <4ca999ee.5030...@free.fr> you wrote:
>>
>> Note however that linking for base address 0 is not mandatory for
>> achieving true position independence. What is required is that the code
>> which runs from power-u
Dear "J. William Campbell",
In message <4ca9f294.8080...@comcast.net> you wrote:
>
> Yes, I think Wolfgang is correct. This is not going to be easy to do in
> general. To run anywhere, the code must be true Position Independent
> code. If you intend to use any C code in the initialization, this
Dear Graeme Russ,
In message you
wrote:
>
> > That means you need to build all of U-Boot that way, because
> > significant parts of the code already run before relocation
> > (including all clocks and timers setup, console setup, printf and all
> > routines these pull in).
>
> Have a look at x8
Dear Wolfgang Denk,
> In message<4ca9eb88.5000...@emk-elektronik.de> you wrote:
>>
>> 1. The board's config file defines "CONFIG_AT91FAMILY" like this:
>> /* SoC */
>> #define CONFIG_ARM926EJS 1 /* ARM926EJS Core */
>> #define CONFIG_AT91FAMILY 1 /* it's a member o
The following changes since commit 2e6e1772c0e34871769be4aef79748fe3e47d953:
Merge branch 'next' of /home/wd/git/u-boot/next (2010-09-28 23:30:47 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Mike Frysinger (34):
Blackfin: add support
1 - 100 of 153 matches
Mail list logo
