If we really want to simplify what bootm does than I think we should
remove ft_board_setup() from lib_ppc/bootm.c and expect any actually
modification of the device tree to have already occurred.
Is this something we'd really be willing to do?
- k
diff --git a/lib_ppc/bootm.c b/lib_ppc/bootm
In message <[EMAIL PROTECTED]> you wrote:
>
> > Why not? Wouldn't it be just another environment variable, like the
> > load address for the kernel?
>
> Right now the fdt is placed at the first 4k page after the kernel is
> decompressed. I don't now where that address is.
Who places it the
In message <[EMAIL PROTECTED]> you wrote:
>
> > > +/* See table in 31.6.11 */
> > > +static const int udivslot[] = {
> > > + 0,
> > > + 0x0080,
> > > + 0x0808,
> > > + 0x0888,
> > > + 0x,
> > > + 0x4924,
> > > + 0x4a52,
> > > + 0x54aa,
> > > + 0x,
> > > + 0xd555,
> > > + 0xd5d5,
> > > + 0x
Note that with older board revisions, NAND boot may only work after a
power-on reset, and not after a warm reset. I suspect there are hardware
issues involved.
I don't have a newer board to test on, though previous implementations
have been reported to work on boards with a 33MHz crystal (which c
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
Applied to u-boot-nand-flash/testing.
include/configs/MPC8313ERDB.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
index d547681..3a644d3 100644
--- a/include
On Mon, Aug 04, 2008 at 02:46:15PM +0200, Guennadi Liakhovetski wrote:
> +#ifdef CONFIG_NAND_SPL
> +static u_char nand_read_byte(struct mtd_info *mtd)
> +{
> + struct nand_chip *this = mtd->priv;
> + return readb(this->IO_ADDR_R);
> +}
> +
> +static void nand_write_byte(struct mtd_info *mtd
On Mon, Aug 04, 2008 at 02:45:33PM +0200, Guennadi Liakhovetski wrote:
> I _think_ this should work with all NAND chips. Otherwise we might have to
> introduce a configuration variable.
Which small-page NAND chips can't handle READOOB? On large page devices,
nand_command changes it to READ0.
Th
On Aug 4, 2008, at 4:07 PM, Wolfgang Denk wrote:
> In message [EMAIL PROTECTED]> you wrote:
>>
>>> So just run the needed commands before you run "bootm" as part of
>>> your
>>> boot command sequence.
>>
>> This doesnt work. Lets say I want to remove a node or property that
>> ft_board_setup(
Kumar Gala wrote:
> On Aug 4, 2008, at 3:55 PM, Scott Wood wrote:
>> Why not? Wouldn't it be just another environment variable, like the
>> load address for the kernel?
>
> Right now the fdt is placed at the first 4k page after the kernel is
> decompressed. I don't now where that address is.
On Aug 4, 2008, at 3:55 PM, Scott Wood wrote:
> Kumar Gala wrote:
>> On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:
>>> So just run the needed commands before you run "bootm" as part of
>>> your
>>> boot command sequence.
>> This doesnt work. Lets say I want to remove a node or property
>>
On Mon, 4 Aug 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 14:45 Mon 04 Aug , Guennadi Liakhovetski wrote:
> > Ported from u-boot-1.1.6 driver by Samsung.
> >
> > Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
> > ---
> >
> > Also added my copyright to the driver.
> >
> > d
On Mon, 4 Aug 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
> diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
> > index fd60edb..0bfa4d7 100644
> > --- a/drivers/usb/usb_ohci.c
> > +++ b/drivers/usb/usb_ohci.c
> > @@ -69,6 +69,7 @@
> > #if defined(CONFIG_ARM920T) || \
> > defin
On Thu, Jul 31, 2008 at 12:42:43PM +0200, Guennadi Liakhovetski wrote:
> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
> ---
> drivers/mtd/nand/nand_base.c | 33 +
> 1 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mtd/nand/n
> Arrr, my insanity. Wolfgang is correct, of course.
>
Gee, and I was just going to ask why on earth you liked
high-boot :)
I've seen one novel use of high-boot that could make it
useful if you're lazy and can't be bothered plugging in
your debugger ;)
Assuming your board has a toggle switch t
On Thu, Jul 31, 2008 at 12:38:26PM +0200, Guennadi Liakhovetski wrote:
> Environment can be smaller than NAND block size, do not need to read a whole
> block and minimum for writing is one page. Also remove an unused variable.
>
> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
Applied t
On 14:45 Mon 04 Aug , Guennadi Liakhovetski wrote:
> Ported from u-boot-1.1.6 driver by Samsung.
>
> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
> ---
>
> Also added my copyright to the driver.
>
> drivers/serial/Makefile |1 +
> drivers/serial/s3c64xx.c | 189
>
diff --git a/drivers/usb/usb_ohci.c b/drivers/usb/usb_ohci.c
> index fd60edb..0bfa4d7 100644
> --- a/drivers/usb/usb_ohci.c
> +++ b/drivers/usb/usb_ohci.c
> @@ -69,6 +69,7 @@
> #if defined(CONFIG_ARM920T) || \
> defined(CONFIG_S3C2400) || \
> defined(CONFIG_S3C2410) || \
> +defined(
In message <[EMAIL PROTECTED]> you wrote:
>
> > So just run the needed commands before you run "bootm" as part of your
> > boot command sequence.
>
> This doesnt work. Lets say I want to remove a node or property that
> ft_board_setup() adds. If I do what you are suggesting the node or
> pr
In message <[EMAIL PROTECTED]> you wrote:
>
> I don't like it that bootm is calling out to all sorts of functions that
> could better be scripted. It complicates the bootm code (badly!), it
> prevents users from doing clever things (because it hard codes the calls
> and sequences of the calls t
Kumar Gala wrote:
> On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:
>> So just run the needed commands before you run "bootm" as part of your
>> boot command sequence.
>
> This doesnt work. Lets say I want to remove a node or property that
> ft_board_setup() adds. If I do what you are suggest
On Aug 4, 2008, at 3:44 PM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
>>> Kumar Gala wrote:
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]
> > you wrote:
>> Added the 'fdtcmd' environment v
On Aug 4, 2008, at 3:27 PM, Wolfgang Denk wrote:
> In message
> <[EMAIL PROTECTED]> you wrote:
>>
Added the 'fdtcmd' environment variable as a way to provide 'fdt'
commands
that the user can supply to manipulate the device tree after
ft_board_setup()
and before the tree
David Hawkins wrote:
>> Arrr, my insanity. Wolfgang is correct, of course.
>>
>
> Gee, and I was just going to ask why on earth you liked
> high-boot :)
>
> I've seen one novel use of high-boot that could make it
> useful if you're lazy and can't be bothered plugging in
> your debugger ;)
Or th
Kumar Gala wrote:
>
> On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
>
>> Kumar Gala wrote:
>>> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
In message
<[EMAIL PROTECTED]> you wrote:
> Added the 'fdtcmd' environment variable as a way to provide 'fdt'
> commands
>
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>> Your choices are 0xfff0 and zero, based on the BMS (Boot Memory
>>> Space) bit of the low reset control word.
>>>
>>> -Scott
>> ...and of the two options, I recommend 0xfff0 ("boot high"). Note
>> that the start of u-bo
In message <[EMAIL PROTECTED]> you wrote:
>
> > Your choices are 0xfff0 and zero, based on the BMS (Boot Memory
> > Space) bit of the low reset control word.
> >
> > -Scott
>
> ...and of the two options, I recommend 0xfff0 ("boot high"). Note
> that the start of u-boot is 0xfff0 bu
In message <[EMAIL PROTECTED]> you wrote:
>
> >> Added the 'fdtcmd' environment variable as a way to provide 'fdt'
> >> commands
> >> that the user can supply to manipulate the device tree after
> >> ft_board_setup()
> >> and before the tree is handled to the kernel.
> >
> > Where exactly is t
Scott Wood wrote:
> Jatin Sharma wrote:
>> I have Freescale MPC8347. Can you confirm that I have to have U-Boot
>> start at 0xFFF0?
>
> Your choices are 0xfff0 and zero, based on the BMS (Boot Memory
> Space) bit of the low reset control word.
>
> -Scott
...and of the two options, I rec
On Aug 4, 2008, at 3:19 PM, Jerry Van Baren wrote:
> Kumar Gala wrote:
>> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
>>> In message >> [EMAIL PROTECTED]> you wrote:
Added the 'fdtcmd' environment variable as a way to provide
'fdt' commands
that the user can supply to mani
Rafal,
Can you try the following patch and see if works for you (make sure the
resulting image actually boots the board). If so I'll fixup all the .lds
I changed to match.
diff --git a/board/freescale/mpc8555cds/u-boot.lds
b/board/freescale/mpc8555cds/u-boot.lds
index a18b3a7..e7fbe5d 100644
--
Kumar Gala wrote:
> On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
>
>> In message <[EMAIL PROTECTED]>
>> you wrote:
>>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'
>>> commands
>>> that the user can supply to manipulate the device tree after
>>> ft_board_setup()
>>>
This is just to apologise for not CC-ing the ARM-maintainer in the
original post. I did forward him the patch afterwards, sorry.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194
Scott Wood wrote:
> Jatin Sharma wrote:
>> I have Freescale MPC8347. Can you confirm that I have to have U-Boot
>> start at 0xFFF0?
>
> Your choices are 0xfff0 and zero, based on the BMS (Boot Memory
> Space) bit of the low reset control word.
Grr, that should say "high reset control wor
Jatin Sharma wrote:
> I have Freescale MPC8347. Can you confirm that I have to have U-Boot
> start at 0xFFF0?
Your choices are 0xfff0 and zero, based on the BMS (Boot Memory
Space) bit of the low reset control word.
-Scott
I have Freescale MPC8347. Can you confirm that I have to have U-Boot
start at 0xFFF0?
Thanks,
Jatin
2008/8/4 Scott Wood <[EMAIL PROTECTED]>:
> Jatin Sharma wrote:
>> After I posted this message, I learned the reset vector for the PPC
>> architecture lies at 0xFFF00100.
>
> Well, it depends on
On Aug 4, 2008, at 1:56 PM, Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]>
> you wrote:
>> Added the 'fdtcmd' environment variable as a way to provide 'fdt'
>> commands
>> that the user can supply to manipulate the device tree after
>> ft_board_setup()
>> and before the tree is handl
Jatin Sharma wrote:
> After I posted this message, I learned the reset vector for the PPC
> architecture lies at 0xFFF00100.
Well, it depends on what kind of PPC chip...
> Does it mean the u-boot has to start
> at the address 0xFFF0?
Yes (or possibly zero, if the RCW is set appropriately).
No, I don't think I made changes to let CPU know about this when it
branches to the boot vector.
After I posted this message, I learned the reset vector for the PPC
architecture lies at 0xFFF00100. Does it mean the u-boot has to start
at the address 0xFFF0? If not, how can I let CPU know to lo
Currently, they use CONFIG_NUM_CPUS, which is different than
85xx for no good reason.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
cpu/mpc86xx/start.S |4 ++--
include/configs/MPC8610HPCD.h |2 +-
include/configs/MPC8641HPCN.h |2 +-
include/configs/sbc8641d.h|
This is needed because we will be possibly be locating
devices at physical addresses above 32bits, and the asm
preprocessing does not appear to deal with ULL constants
properly. We now call write_bat in lib_ppc/bat_rw.c.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
cpu/mpc86xx/cpu_init.c |
Perform sync/isync as required by the architecture.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
lib_ppc/bat_rw.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib_ppc/bat_rw.c b/lib_ppc/bat_rw.c
index 8546333..a40b377 100644
--- a/lib_ppc/bat_rw.c
+++ b/lib_
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
include/configs/sbc8641d.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/configs/sbc8641d.h b/include/configs/sbc8641d.h
index 76712fd..e075a10 100644
--- a/include/configs/sbc8641d.h
+++ b/include/configs/sbc86
In message <[EMAIL PROTECTED]> you wrote:
> Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
> that the user can supply to manipulate the device tree after ft_board_setup()
> and before the tree is handled to the kernel.
Where exactly is the needed, i. e. which spoecific
Added the 'fdtcmd' environment variable as a way to provide 'fdt' commands
that the user can supply to manipulate the device tree after ft_board_setup()
and before the tree is handled to the kernel.
The idea is that users may want to add or manipulate nodes w/changing the u-boot
binary. The curre
On Fri, Aug 01, 2008 at 12:16:13PM -0500, Jatin Sharma wrote:
> I have to increase u-boot's partition size on my board to make room
> for an application to be compiled as part of u-boot binary. I am
> currently running u-boot version "1.3.1-rc1" and my current NOR
> partition is as follows:
>
> Pa
Kenneth,
My kernel boots without your patch but not with it. I haven't done any
debug yet so I don't know why.
John
Kenneth Johansson wrote:
> And in the process eliminate some duplicate register defines.
>
>
> Signed-off-by: Kenneth Johansson <[EMAIL PROTECTED]>
> ---
> board/ads5121/Makefil
Hi,
in general I totally ack to a new version numbering scheme.
When we are releasing U-Boot for some of our hardware this is typically done
asynchronous to the U-Boot release cycle. We (often) cannot wait until a new
U-Boot is released. So we take the current U-Boot version + build date/time
as
Hi Wolfgang,
yes, please do so.
I just returned from vacation and got unsubscribed again :-(
Matthias
On Friday 01 August 2008 17:17, Wolfgang Denk wrote:
> Hello,
>
> I would like to get your general opinion about moving the
> "u-boot-users" mailing list away from SourceForge and host it on
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>>> Why? One address is as good as any other.
>> I think statistically you'll find that that isn't true. A built-in DTB is
>> more
>> likely to be present on the flash than an external DTB would be.
>
> Please present the data your
In message <[EMAIL PROTECTED]> you wrote:
>
> > Why? One address is as good as any other.
>
> I think statistically you'll find that that isn't true. A built-in DTB is
> more
> likely to be present on the flash than an external DTB would be.
Please present the data your statistics is based on.
In message <[EMAIL PROTECTED]> you wrote:
>
> The idea was to discover the proximity of where to look for the API signature
> in run-time and only search within some range around it. This way we'd drop
> static definitions of the search range.
I think this is pretty unreliable.
> The assumption w
Jon Smirl wrote:
> BTW, how do know which DT to dynamically interpret? If you are
> installing a universal uboot you still are going to have to install a
> different DT in each model. If you're installing a different DT you
> might as well install a different uboot.
That's what I was thinking, t
On 8/3/08, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
> >
> > > What about creating a tool that parses a device tree and creates (or
> > > updates) the board header file? This will retain compatibility with
> > > other platforms, clean up the existin
I have corrected the syntax to CONFIG_PREBOOT. I believe the reason that
I am not seeing the effect of this is I am not able to build the binary
image.
I have sprinkled questions along this email that I hope someone can
assist with
In an earlier reply to me, you (Wolfgang) mentioned that I shoul
Wolfgang Denk wrote:
> Why? One address is as good as any other.
I think statistically you'll find that that isn't true. A built-in DTB is more
likely to be present on the flash than an external DTB would be.
--
Timur Tabi
Linux kernel developer at Freescale
--
Hi
On Wed, Jul 30, 2008 at 12:13 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>> you wrote:
>> If CONFIG_SKIP_RELOCATE_UBOOT is set the flag GD_FLG_RELOC is usually never
>> set, because relocation to RAM is actually never done by U-boot itself.
>> However, several p
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>
>> I have verified that the Sequoia (440EPx) does not have its UARTs
>> properly configured. The attached patch corrects this by setting three
>> bits in SDR0_PFC1 to enable 4-wire mode, and to select cts/rts
>> functionality fo
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>> De-hard code the range in RAM we search for API signature, which might not be
>> uniform accross architectures and board configurations. Instead use current
>> global_data pointer as a hint to narrow down the range the [malloc'ed]
In message <[EMAIL PROTECTED]> you wrote:
> De-hard code the range in RAM we search for API signature, which might not be
> uniform accross architectures and board configurations. Instead use current
> global_data pointer as a hint to narrow down the range the [malloc'ed]
> signature
> could resid
SMDK6400 can only boot U-Boot from NAND-flash. This patch adds a nand_spl
driver for it too. The board can also boot from the NOR flash, but due to
hardware limitations it can only address 64KiB on it, which is not enough
for U-Boot. Ported from u-boot-1.1.6 version by Samsung.
Signed-off-by: Guen
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c64xx.c | 307
2 files changed, 308 insertions(+), 0 deletions(-)
create mode 100644 driv
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
Also added my copyright to the driver.
drivers/serial/Makefile |1 +
drivers/serial/s3c64xx.c | 189 ++
2 files changed, 190 insertions(+),
Notice: USB on s3c6400 currently works _only_ with switched off MMU. One could
try to enable the MMU, but map addresses 1-to-1, and disable data cache, then
it should work too and we could still profit from instruction cache.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
cpu/arm117
(Tested on ARM920-based EP93xx system)
Signed-off-by: Rafal Czubak <[EMAIL PROTECTED]>
Acked-by: Rafal Jaworowski <[EMAIL PROTECTED]>
---
api_examples/Makefile |6 +++---
api_examples/crt0.S | 17 +++--
lib_arm/board.c |5 +
3 files changed, 23 insertions(+), 5 d
De-hard code the range in RAM we search for API signature, which might not be
uniform accross architectures and board configurations. Instead use current
global_data pointer as a hint to narrow down the range the [malloc'ed] signature
could reside.
Signed-off-by: Rafal Czubak <[EMAIL PROTECTED]>
S
I _think_ this should work with all NAND chips. Otherwise we might have to
introduce a configuration variable.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
nand_spl/nand_boot.c | 64 ++---
1 files changed, 34 insertions(+), 30 deletio
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/mtd/jedec_flash.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 9845e93..020647a 100644
--- a/drivers/mtd/jedec_flash.c
+++ b
Version 3: now all lines over 80 characters are gone. And a couple more
checkpatch warnings with them.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Pho
Hello,
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open
In message <[EMAIL PROTECTED]> you wrote:
>
> Sorry, looks like a matter of taste to me. There are also very few lines
> over 80 characters left, but fixing them would look too awkward...
This is not a matter of taste. Please fix these, too!
Best regards,
Wolfgang Denk
--
DENX Software Engin
SMDK6400 can only boot U-Boot from NAND-flash. This patch adds a nand_spl
driver for it too. The board can also boot from the NOR flash, but due to
hardware limitations it can only address 64KiB on it, which is not enough
for U-Boot. Ported from u-boot-1.1.6 version by Samsung.
Signed-off-by: G
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c64xx.c | 307
2 files changed, 308 insertions(+), 0 deletions(-)
create mode 100644 driv
Ported from u-boot-1.1.6 driver by Samsung.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/serial/Makefile |1 +
drivers/serial/s3c64xx.c | 186 ++
2 files changed, 187 insertions(+), 0 deletions(-)
create mode 100644 driver
Notice: USB on s3c6400 currently works _only_ with switched off MMU. One could
try to enable the MMU, but map addresses 1-to-1, and disable data cache, then
it should work too and we could still profit from instruction cache.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
cpu/arm117
I _think_ this should work with all NAND chips. Otherwise we might have to
introduce a configuration variable.
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
nand_spl/nand_boot.c | 61 +
1 files changed, 31 insertions(+), 30 deletio
Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
---
drivers/mtd/jedec_flash.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/jedec_flash.c b/drivers/mtd/jedec_flash.c
index 9845e93..020647a 100644
--- a/drivers/mtd/jedec_flash.c
+++ b
Hi,
this is version 2 of the smdk6400 patch series. I hope, I took care of all
comments, apart of these ones:
On Thu, 31 Jul 2008, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > +#ifdef CONFIG_NAND_SPL
> > +static u_char nand_read_byte(struct mtd_info *mtd)
> > +{
> > + struct nand_chip *this = m
Hi Remy,
Le jeudi 31 juillet 2008 à 15:24 +0200, Remy Bohmer a écrit :
> Hello Stelian and others,
>
> I have made some progress here, and I would like to inform you all:
[...]
> I have done a lot of debugging/testing etc. and I noticed that binary
> deliverables of U-boot for the evaluationkit
Wolfgang Denk wrote:
>> With today's top of the tree U-Boot I'm getting this:
>>
>> ./MAKEALL MPC8555CDS
>> Configuring for MPC8555CDS board...
>> ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need=
>> 4)
>> ppc_85xx-ld: final link failed: Bad value
>> make: *** [u-boot] B
In message <[EMAIL PROTECTED]> you wrote:
> Hi,
>
> With today's top of the tree U-Boot I'm getting this:
>
> ./MAKEALL MPC8555CDS
> Configuring for MPC8555CDS board...
> ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need=
> 4)
> ppc_85xx-ld: final link failed: Bad value
Hi,
With today's top of the tree U-Boot I'm getting this:
./MAKEALL MPC8555CDS
Configuring for MPC8555CDS board...
ppc_85xx-ld: u-boot: Not enough room for program headers (allocated 3, need 4)
ppc_85xx-ld: final link failed: Bad value
make: *** [u-boot] Błąd 1
ppc_85xx-size: './u-boot': No such
Yes, I also happened it as you.
Please revert it and have a try.
Revert "mpc85xx: Update linker scripts for Freescale boards"
This reverts commit f0ff885ca64655bee6540eb8a25eed90b1152686.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of
Timur Tabi a écrit :
> On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely <[EMAIL PROTECTED]> wrote:
>
>> Better to just not depend on the DTB at all for basic operation. ie.
>> don't brick the board if the DTB is unavailable.
>
> Is it even possible to have a "recovery mode U-Boot" that is not tied
>
Feng Kan schrieb:
> Albert ARIBAUD wrote:
>> Wolfgang Denk a écrit :
>>
>>> Hello,
>>>
>>> I would like to get your general opinion about changing the U-Boot
>>> version numbering scheme.
>>>
>>> To be honest, I never really understood myself how this is supposed
>>> to work and if the next
Grant Likely schrieb:
> On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
>> On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>>
>>> If the DTB can be at any
>>> flash location, you can for example have a fall-back version which is
>>> used to bri
[EMAIL PROTECTED] wrote on :
> Kumar Gala wrote:
> > On Aug 1, 2008, at 10:32 AM, Wolfgang Denk wrote:
> >
> >
> > > Hello,
> > >
> > > I would like to get your general opinion about changing the
> > > U-Boot version numbering scheme.
> > >
> > > To be honest, I never really understood myse
86 matches
Mail list logo
