* [ECOS] fis free command
@ 2003-10-31 18:23 Chris Garry
2003-11-01 7:56 ` Gary Thomas
0 siblings, 1 reply; 8+ messages in thread
From: Chris Garry @ 2003-10-31 18:23 UTC (permalink / raw)
To: eCos Discussion
I just re-built RedBoot and noticed a small problem with the fis free
command. Output from RedBoot below:
-- Begin --
RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version E7T-DBoard - built 16:51:24, Oct 31 2003
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available
0x01900000-0x03900000, [0x01900000-0x03900000] available
FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes each.
RedBoot> fis free
0x0183B000 .. 0x0187E000
0x01880000 .. 0x0187FFFF
RedBoot>
-- End --
The last line of output from the fis free command
(0x01880000 .. 0x0187FFFF) is bogus since the highest FLASH address
is 0x0187FFFF.
Has this been seen on other platforms?
--
Chris
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [ECOS] fis free command
2003-10-31 18:23 [ECOS] fis free command Chris Garry
@ 2003-11-01 7:56 ` Gary Thomas
2003-11-01 11:28 ` Chris Garry
2003-11-19 21:32 ` [ECOS] IXP420 Problems Sleepy
0 siblings, 2 replies; 8+ messages in thread
From: Gary Thomas @ 2003-11-01 7:56 UTC (permalink / raw)
To: Chris Garry; +Cc: eCos Discussion
Chris Garry said:
> I just re-built RedBoot and noticed a small problem with the fis free
> command. Output from RedBoot below:
>
> -- Begin --
> RedBoot(tm) bootstrap and debug environment [ROM]
> Non-certified release, version E7T-DBoard - built 16:51:24, Oct 31 2003
>
> Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
>
> RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available
> 0x01900000-0x03900000, [0x01900000-0x03900000] available
> FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes each.
> RedBoot> fis free
> 0x0183B000 .. 0x0187E000
> 0x01880000 .. 0x0187FFFF
> RedBoot>
> -- End --
>
> The last line of output from the fis free command
> (0x01880000 .. 0x0187FFFF) is bogus since the highest FLASH address
> is 0x0187FFFF.
>
> Has this been seen on other platforms?
No. What does 'fis list' show?
Note: 'fis free' has recently been changed to believe the values in
the fis directory. If it is incorrect, then all bets are off. A
configuration control can be used to restore the previous [dubious]
behaviour.
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] fis free command
2003-11-01 7:56 ` Gary Thomas
@ 2003-11-01 11:28 ` Chris Garry
2003-11-01 13:11 ` Chris Garry
2003-11-19 21:32 ` [ECOS] IXP420 Problems Sleepy
1 sibling, 1 reply; 8+ messages in thread
From: Chris Garry @ 2003-11-01 11:28 UTC (permalink / raw)
To: Gary Thomas; +Cc: eCos Discussion
----- Original Message -----
From: "Gary Thomas" <gary@mlbassoc.com>
To: "Chris Garry" <cgarry@sweeneydesign.co.uk>
Cc: "eCos Discussion" <ecos-discuss@sources.redhat.com>
Sent: Saturday, November 01, 2003 7:56 AM
Subject: Re: [ECOS] fis free command
> Chris Garry said:
> > I just re-built RedBoot and noticed a small problem with the fis free
> > command. Output from RedBoot below:
> >
> > -- Begin --
> > RedBoot(tm) bootstrap and debug environment [ROM]
> > Non-certified release, version E7T-DBoard - built 16:51:24, Oct 31 2003
> >
> > Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
> >
> > RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available
> > 0x01900000-0x03900000, [0x01900000-0x03900000] available
> > FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes each.
> > RedBoot> fis free
> > 0x0183B000 .. 0x0187E000
> > 0x01880000 .. 0x0187FFFF
> > RedBoot>
> > -- End --
> >
> > The last line of output from the fis free command
> > (0x01880000 .. 0x0187FFFF) is bogus since the highest FLASH address
> > is 0x0187FFFF.
> >
> > Has this been seen on other platforms?
>
> No. What does 'fis list' show?
>
RedBoot> fis free
0x0183B000 .. 0x0187E000
0x01880000 .. 0x0187FFFF
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
(reserved) 0x01800000 0x01800000 0x00010000 0x00000000
RedBoot[post] 0x01810000 0x01810000 0x00020000 0x00000000
support.fpga 0x01830000 0x01900000 0x0000B000 0x01900000
RedBoot config 0x0187E000 0x0187E000 0x00001000 0x00000000
FIS directory 0x0187F000 0x0187F000 0x00001000 0x00000000
RedBoot>
> Note: 'fis free' has recently been changed to believe the values in
> the fis directory. If it is incorrect, then all bets are off. A
> configuration control can be used to restore the previous [dubious]
> behaviour.
I rebuilt RedBoot with CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS
disabled and 'fis free' worked correctly. I agree that the new 'fis free'method is
better so I'll have a look at what is going wrong on my target.
Chris
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] fis free command
2003-11-01 11:28 ` Chris Garry
@ 2003-11-01 13:11 ` Chris Garry
2003-11-01 13:18 ` Gary Thomas
2003-11-04 14:02 ` Gary Thomas
0 siblings, 2 replies; 8+ messages in thread
From: Chris Garry @ 2003-11-01 13:11 UTC (permalink / raw)
To: Gary Thomas; +Cc: eCos Discussion
> > > I just re-built RedBoot and noticed a small problem with the fis free
> > > command. Output from RedBoot below:
> > >
> > > -- Begin --
> > > RedBoot(tm) bootstrap and debug environment [ROM]
> > > Non-certified release, version E7T-DBoard - built 16:51:24, Oct 31 2003
> > >
> > > Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
> > >
> > > RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available
> > > 0x01900000-0x03900000, [0x01900000-0x03900000] available
> > > FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes each.
> > > RedBoot> fis free
> > > 0x0183B000 .. 0x0187E000
> > > 0x01880000 .. 0x0187FFFF
> > > RedBoot>
> > > -- End --
> > >
> > > The last line of output from the fis free command
> > > (0x01880000 .. 0x0187FFFF) is bogus since the highest FLASH address
> > > is 0x0187FFFF.
> > >
> > > Has this been seen on other platforms?
> >
> > No. What does 'fis list' show?
> >
>
> RedBoot> fis free
> 0x0183B000 .. 0x0187E000
> 0x01880000 .. 0x0187FFFF
> RedBoot> fis list
> Name FLASH addr Mem addr Length Entry point
> (reserved) 0x01800000 0x01800000 0x00010000 0x00000000
> RedBoot[post] 0x01810000 0x01810000 0x00020000 0x00000000
> support.fpga 0x01830000 0x01900000 0x0000B000 0x01900000
> RedBoot config 0x0187E000 0x0187E000 0x00001000 0x00000000
> FIS directory 0x0187F000 0x0187F000 0x00001000 0x00000000
> RedBoot>
>
> > Note: 'fis free' has recently been changed to believe the values in
> > the fis directory. If it is incorrect, then all bets are off. A
> > configuration control can be used to restore the previous [dubious]
> > behaviour.
>
> I rebuilt RedBoot with CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS
> disabled and 'fis free' worked correctly. I agree that the new 'fis free'method is
> better so I'll have a look at what is going wrong on my target.
>
> Chris
>
Okay, the problem looks to be in the find_free function.
This fix works for me:
Index: redboot/current/src/flash.c
===================================================================
RCS file: /cvs/ecos/ecos/packages/redboot/current/src/flash.c,v
retrieving revision 1.58
diff -u -5 -b -p -r1.58 flash.c
--- redboot/current/src/flash.c 15 Oct 2003 15:52:03 -0000 1.5
+++ redboot/current/src/flash.c 1 Nov 2003 13:07:00 -0000
@@ -536,11 +536,11 @@ find_free(struct free_chunk *chunks)
for (idx = 0; idx < num_chunks; idx++) {
if ((img->flash_base >= chunks[idx].start) &&
(img->flash_base <= chunks[idx].end)) {
if (img->flash_base == chunks[idx].start) {
chunks[idx].start += img->size;
- if (chunks[idx].start == chunks[idx].end)
+ if (chunks[idx].start >= chunks[idx].end)
// This free chunk has collapsed
while (idx < (num_chunks-1)) {
chunks[idx] = chunks[idx+1];
}
num_chunks--;
Would this fix be safe for other targets?
--
Chris
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [ECOS] fis free command
2003-11-01 13:11 ` Chris Garry
@ 2003-11-01 13:18 ` Gary Thomas
2003-11-04 15:11 ` [ECOS] RE : " David POUTY
2003-11-04 14:02 ` Gary Thomas
1 sibling, 1 reply; 8+ messages in thread
From: Gary Thomas @ 2003-11-01 13:18 UTC (permalink / raw)
To: Chris Garry; +Cc: Gary Thomas, eCos Discussion
Chris Garry said:
>> > > I just re-built RedBoot and noticed a small problem with the fis free
>> > > command. Output from RedBoot below:
>> > >
>> > > -- Begin --
>> > > RedBoot(tm) bootstrap and debug environment [ROM]
>> > > Non-certified release, version E7T-DBoard - built 16:51:24, Oct 31 2003
>> > >
>> > > Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
>> > >
>> > > RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available
>> > > 0x01900000-0x03900000, [0x01900000-0x03900000] available
>> > > FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes each.
>> > > RedBoot> fis free
>> > > 0x0183B000 .. 0x0187E000
>> > > 0x01880000 .. 0x0187FFFF
>> > > RedBoot>
>> > > -- End --
>> > >
>> > > The last line of output from the fis free command
>> > > (0x01880000 .. 0x0187FFFF) is bogus since the highest FLASH address
>> > > is 0x0187FFFF.
>> > >
>> > > Has this been seen on other platforms?
>> >
>> > No. What does 'fis list' show?
>> >
>>
>> RedBoot> fis free
>> 0x0183B000 .. 0x0187E000
>> 0x01880000 .. 0x0187FFFF
>> RedBoot> fis list
>> Name FLASH addr Mem addr Length Entry point
>> (reserved) 0x01800000 0x01800000 0x00010000 0x00000000
>> RedBoot[post] 0x01810000 0x01810000 0x00020000 0x00000000
>> support.fpga 0x01830000 0x01900000 0x0000B000 0x01900000
>> RedBoot config 0x0187E000 0x0187E000 0x00001000 0x00000000
>> FIS directory 0x0187F000 0x0187F000 0x00001000 0x00000000
>> RedBoot>
>>
>> > Note: 'fis free' has recently been changed to believe the values in
>> > the fis directory. If it is incorrect, then all bets are off. A
>> > configuration control can be used to restore the previous [dubious]
>> > behaviour.
>>
>> I rebuilt RedBoot with CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS
>> disabled and 'fis free' worked correctly. I agree that the new 'fis free'method is
>> better so I'll have a look at what is going wrong on my target.
>>
>> Chris
>>
>
> Okay, the problem looks to be in the find_free function.
> This fix works for me:
I think I had it that way before and had troubles, so I'm not sure.
Today, I'm 6000+ miles from my office, so I can't do much checking.
I'll give this a look on Monday.
Thanks for looking into it.
>
> Index: redboot/current/src/flash.c
> ===================================================================
> RCS file: /cvs/ecos/ecos/packages/redboot/current/src/flash.c,v
> retrieving revision 1.58
> diff -u -5 -b -p -r1.58 flash.c
> --- redboot/current/src/flash.c 15 Oct 2003 15:52:03 -0000 1.5
> +++ redboot/current/src/flash.c 1 Nov 2003 13:07:00 -0000
> @@ -536,11 +536,11 @@ find_free(struct free_chunk *chunks)
> for (idx = 0; idx < num_chunks; idx++) {
> if ((img->flash_base >= chunks[idx].start) &&
> (img->flash_base <= chunks[idx].end)) {
> if (img->flash_base == chunks[idx].start) {
> chunks[idx].start += img->size;
> - if (chunks[idx].start == chunks[idx].end)
> + if (chunks[idx].start >= chunks[idx].end)
> // This free chunk has collapsed
> while (idx < (num_chunks-1)) {
> chunks[idx] = chunks[idx+1];
> }
> num_chunks--;
>
>
> Would this fix be safe for other targets?
>
> --
> Chris
>
>
------------------------------------------------------------
Gary Thomas |
MLB Associates | Consulting for the
+1 (970) 229-1963 | Embedded world
http://www.mlbassoc.com/ |
email: <gary@mlbassoc.com> |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread* [ECOS] RE : [ECOS] fis free command
2003-11-01 13:18 ` Gary Thomas
@ 2003-11-04 15:11 ` David POUTY
0 siblings, 0 replies; 8+ messages in thread
From: David POUTY @ 2003-11-04 15:11 UTC (permalink / raw)
To: 'Gary Thomas'; +Cc: 'eCos Discussion'
I think there's another problem with 'fis free'. In the following code
'idx' is never incremented, so ...
// This free chunk has collapsed
while (idx < (num_chunks-1)) {
chunks[idx] = chunks[idx+1];
}
There's also a limitation. fis free doesn't work well when FIS end at
address 0xFFFFFFFF (I'm in this case).
I'll try to submit a patch this week.
David
-----Message d'origine-----
De : Gary Thomas [mailto:gary@mlbassoc.com]
Envoyé : samedi 1 novembre 2003 14:18
À : Chris Garry
Cc : Gary Thomas; eCos Discussion
Objet : Re: [ECOS] fis free command
Chris Garry said:
>> > > I just re-built RedBoot and noticed a small problem with the fis
>> > > free command. Output from RedBoot below:
>> > >
>> > > -- Begin --
>> > > RedBoot(tm) bootstrap and debug environment [ROM] Non-certified
>> > > release, version E7T-DBoard - built 16:51:24, Oct 31 2003
>> > >
>> > > Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
>> > >
>> > > RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available
>> > > 0x01900000-0x03900000, [0x01900000-0x03900000] available
>> > > FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes
>> > > each.
>> > > RedBoot> fis free
>> > > 0x0183B000 .. 0x0187E000
>> > > 0x01880000 .. 0x0187FFFF
>> > > RedBoot>
>> > > -- End --
>> > >
>> > > The last line of output from the fis free command (0x01880000 ..
>> > > 0x0187FFFF) is bogus since the highest FLASH address is
>> > > 0x0187FFFF.
>> > >
>> > > Has this been seen on other platforms?
>> >
>> > No. What does 'fis list' show?
>> >
>>
>> RedBoot> fis free
>> 0x0183B000 .. 0x0187E000
>> 0x01880000 .. 0x0187FFFF
>> RedBoot> fis list
>> Name FLASH addr Mem addr Length Entry point
>> (reserved) 0x01800000 0x01800000 0x00010000 0x00000000
>> RedBoot[post] 0x01810000 0x01810000 0x00020000 0x00000000
>> support.fpga 0x01830000 0x01900000 0x0000B000 0x01900000
>> RedBoot config 0x0187E000 0x0187E000 0x00001000 0x00000000
>> FIS directory 0x0187F000 0x0187F000 0x00001000 0x00000000
>> RedBoot>
>>
>> > Note: 'fis free' has recently been changed to believe the values in
>> > the fis directory. If it is incorrect, then all bets are off. A
>> > configuration control can be used to restore the previous [dubious]
>> > behaviour.
>>
>> I rebuilt RedBoot with CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS
>> disabled and 'fis free' worked correctly. I agree that the new 'fis
>> free'method is better so I'll have a look at what is going wrong on
>> my target.
>>
>> Chris
>>
>
> Okay, the problem looks to be in the find_free function.
> This fix works for me:
I think I had it that way before and had troubles, so I'm not sure.
Today, I'm 6000+ miles from my office, so I can't do much checking. I'll
give this a look on Monday.
Thanks for looking into it.
>
> Index: redboot/current/src/flash.c
> ===================================================================
> RCS file: /cvs/ecos/ecos/packages/redboot/current/src/flash.c,v
> retrieving revision 1.58
> diff -u -5 -b -p -r1.58 flash.c
> --- redboot/current/src/flash.c 15 Oct 2003 15:52:03 -0000 1.5
> +++ redboot/current/src/flash.c 1 Nov 2003 13:07:00 -0000
> @@ -536,11 +536,11 @@ find_free(struct free_chunk *chunks)
> for (idx = 0; idx < num_chunks; idx++) {
> if ((img->flash_base >= chunks[idx].start) &&
> (img->flash_base <= chunks[idx].end)) {
> if (img->flash_base == chunks[idx].start) {
> chunks[idx].start += img->size;
> - if (chunks[idx].start == chunks[idx].end)
> + if (chunks[idx].start >= chunks[idx].end)
> // This free chunk has collapsed
> while (idx < (num_chunks-1)) {
> chunks[idx] = chunks[idx+1];
> }
> num_chunks--;
>
>
> Would this fix be safe for other targets?
>
> --
> Chris
>
>
------------------------------------------------------------
Gary Thomas |
MLB Associates | Consulting for the
+1 (970) 229-1963 | Embedded world
http://www.mlbassoc.com/ |
email: <gary@mlbassoc.com> |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ECOS] fis free command
2003-11-01 13:11 ` Chris Garry
2003-11-01 13:18 ` Gary Thomas
@ 2003-11-04 14:02 ` Gary Thomas
1 sibling, 0 replies; 8+ messages in thread
From: Gary Thomas @ 2003-11-04 14:02 UTC (permalink / raw)
To: Chris Garry; +Cc: eCos Discussion
On Sat, 2003-11-01 at 06:16, Chris Garry wrote:
> > > > I just re-built RedBoot and noticed a small problem with the fis free
> > > > command. Output from RedBoot below:
> > > >
> > > > -- Begin --
> > > > RedBoot(tm) bootstrap and debug environment [ROM]
> > > > Non-certified release, version E7T-DBoard - built 16:51:24, Oct 31 2003
> > > >
> > > > Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
> > > >
> > > > RAM: 0x00000000-0x00080000, [0x00017cc8-0x0006f000] available
> > > > 0x01900000-0x03900000, [0x01900000-0x03900000] available
> > > > FLASH: 0x01800000 - 0x01880000, 128 blocks of 0x00001000 bytes each.
> > > > RedBoot> fis free
> > > > 0x0183B000 .. 0x0187E000
> > > > 0x01880000 .. 0x0187FFFF
> > > > RedBoot>
> > > > -- End --
> > > >
> > > > The last line of output from the fis free command
> > > > (0x01880000 .. 0x0187FFFF) is bogus since the highest FLASH address
> > > > is 0x0187FFFF.
> > > >
> > > > Has this been seen on other platforms?
> > >
> > > No. What does 'fis list' show?
> > >
> >
> > RedBoot> fis free
> > 0x0183B000 .. 0x0187E000
> > 0x01880000 .. 0x0187FFFF
> > RedBoot> fis list
> > Name FLASH addr Mem addr Length Entry point
> > (reserved) 0x01800000 0x01800000 0x00010000 0x00000000
> > RedBoot[post] 0x01810000 0x01810000 0x00020000 0x00000000
> > support.fpga 0x01830000 0x01900000 0x0000B000 0x01900000
> > RedBoot config 0x0187E000 0x0187E000 0x00001000 0x00000000
> > FIS directory 0x0187F000 0x0187F000 0x00001000 0x00000000
> > RedBoot>
> >
> > > Note: 'fis free' has recently been changed to believe the values in
> > > the fis directory. If it is incorrect, then all bets are off. A
> > > configuration control can be used to restore the previous [dubious]
> > > behaviour.
> >
> > I rebuilt RedBoot with CYGDAT_REDBOOT_FIS_MAX_FREE_CHUNKS
> > disabled and 'fis free' worked correctly. I agree that the new 'fis free'method is
> > better so I'll have a look at what is going wrong on my target.
> >
> > Chris
> >
>
> Okay, the problem looks to be in the find_free function.
> This fix works for me:
>
> Index: redboot/current/src/flash.c
> ===================================================================
> RCS file: /cvs/ecos/ecos/packages/redboot/current/src/flash.c,v
> retrieving revision 1.58
> diff -u -5 -b -p -r1.58 flash.c
> --- redboot/current/src/flash.c 15 Oct 2003 15:52:03 -0000 1.5
> +++ redboot/current/src/flash.c 1 Nov 2003 13:07:00 -0000
> @@ -536,11 +536,11 @@ find_free(struct free_chunk *chunks)
> for (idx = 0; idx < num_chunks; idx++) {
> if ((img->flash_base >= chunks[idx].start) &&
> (img->flash_base <= chunks[idx].end)) {
> if (img->flash_base == chunks[idx].start) {
> chunks[idx].start += img->size;
> - if (chunks[idx].start == chunks[idx].end)
> + if (chunks[idx].start >= chunks[idx].end)
> // This free chunk has collapsed
> while (idx < (num_chunks-1)) {
> chunks[idx] = chunks[idx+1];
> }
> num_chunks--;
>
>
> Would this fix be safe for other targets?
Yes, this does appear to be a safe fix. I'll check it in.
--
Gary Thomas <gary@mlbassoc.com>
MLB Associates
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread
* [ECOS] IXP420 Problems
2003-11-01 7:56 ` Gary Thomas
2003-11-01 11:28 ` Chris Garry
@ 2003-11-19 21:32 ` Sleepy
1 sibling, 0 replies; 8+ messages in thread
From: Sleepy @ 2003-11-19 21:32 UTC (permalink / raw)
To: Gary Thomas; +Cc: Chris Garry, eCos Discussion
I am having problems again with my XSCALE IXP420 based board.
the development board originally had 256M and PCI card. I had to disable
the PCI stuff from redboot, and the kernel.I built the kernel and loaded
it via minicom
Redboot>load -r -v -b 0x10600000 -m yMODEM
Now when I try to load the ramdisk(2MB) the thing dies in the middle.
I am curious if anyone can give me hints on this.
I understand the memory is mirrored on xscale architectures.how does that
affect things like redboot?
Thanks
------------------------------------------------------------------------------
Do you Unix?
------------
http://www.maximumunix.org Network Consulting, Security Research, Embedded
Systems.
------------------------------------------------------------------------------
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2003-11-19 21:32 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-31 18:23 [ECOS] fis free command Chris Garry
2003-11-01 7:56 ` Gary Thomas
2003-11-01 11:28 ` Chris Garry
2003-11-01 13:11 ` Chris Garry
2003-11-01 13:18 ` Gary Thomas
2003-11-04 15:11 ` [ECOS] RE : " David POUTY
2003-11-04 14:02 ` Gary Thomas
2003-11-19 21:32 ` [ECOS] IXP420 Problems Sleepy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).