ramdisk problem

ramdisk problem

[somshekar chandrashekar kadam]

hi Wolfgang,

         thanks for ur info

when i am booting its saying ,couldnt find valid ramdisk image ,i
am using pRamdisk from denx site which u have sent me the link

   he is calling PAGE ALIGN
  i dont what it does  but i mostly think
    it computes the offset after after zImage
  as it is given as a parameter


let me know whether i am correct
please

thanks in advance
regards
somshekar


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ramdisk problem

[Wolfgang Denk]

In message <20020613111432.22212.qmail@webmail27.rediffmail.com> you wrote:
>
> when i am booting its saying ,couldnt find valid ramdisk image ,i
> am using pRamdisk from denx site which u have sent me the link

As I wrote you have to strip the PPCBoot header if you are not  using
PPCBoot as boot loader.

Did you do this?

>    he is calling PAGE ALIGN
>   i dont what it does  but i mostly think
>     it computes the offset after after zImage
>   as it is given as a parameter

I cannot make sense out of this. What exactly did you do? How did you
build your zImage.initrd image?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It would seem that evil retreats when forcibly confronted
	-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

ramdisk problem

[刘彩苹]

Hi,hello:
 I use montavista linux,and I use ramdisk root filesystem.But when I run
a simple program (helloworld),I made an error as fellow. I can run the
helloworld program successfully in nfs . Any idea? Thank you very much.

=>tftp 1000000 ramdisk

=>bootm ff850000 1000000

bash# ls
bin            etc            linuxrc        myapplication
dev            lib            lost+found
bash# cd myapplication
bash# ls
helloworld-8xx
bash# ./helloworld-8xx
/helloworld-8xx: error in loading shared libraries
: undefined symbol: __libc_start_main
bash#

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: RAMDISK problem

[VanBaren, Gerald (AGRE)]

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd@denx.de]
> Sent: Thursday, November 20, 2003 11:27 AM
> To: Joao Vicente
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: RAMDISK problem
>
>
>
> In message
> <DEF39A0710293E489D45B10E06645CBD02671CA2@dub-msx1.spectelcorp
> .com> you wrote:
> >
> > My problem is that I dont really know what address the core
> is trying to write to when the exception occurs.
> > As I mentioned in the previous message, the write() calls
> _syscall3() macro which will perform the write operation, but
> early  in that macro the assembly 'sc' instruction is called.
> > As I cannot step through 'sc', I cannot go further on
> investigating at what write access the exception occurs.
>
> But you can set a breakpoint in the sc exception handler.
>
> > How do I even find out what is the start address of the
> file associated with the file descritor?
>
> Analyze at which offset the file starts  in  your  filesystem  image;
> find  out  the  load  address of the filesystem image in RAM; add the
> offset.
>
> Best regards,
>
> Wolfgang Denk

Hi Joao,

I assume you get a crash dump including the registers when it crashes.  If not, you need a better debugger (BDI2000).  If so, look at SRR0, SRR1, etc.  Please read the PowerPC 603e User's Manual (assuming that is applicable: I forgot which processor you are using).  For the 82xx (PPC603e core):
  SRR0 = effective address for resuming program execution
  SRR1 = MSR with some error identification bits

When you find the failure location, disassemble the memory leading up to the failure.  Figure out which registers are being used for a memory access when the crash occurred, and find what those registers contained in the crash dump.  That will tell you why the crash occurred (I'm guessing TEA, bit 13 in SRR1) and which address was at fault (load or store into a memory location, said memory location being one of the GPRs).

If your tools don't give you this information, you need to buy better tools.

gvb


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RAMDISK problem

[Wolfgang Denk]

In message <DEF39A0710293E489D45B10E06645CBD02671CA2@dub-msx1.spectelcorp.com> you wrote:
>
> My problem is that I dont really know what address the core is trying to write to when the exception occurs.
> As I mentioned in the previous message, the write() calls _syscall3() macro which will perform the write operation, but early  in that macro the assembly 'sc' instruction is called.
> As I cannot step through 'sc', I cannot go further on investigating at what write access the exception occurs.

But you can set a breakpoint in the sc exception handler.

> How do I even find out what is the start address of the file associated with the file descritor?

Analyze at which offset the file starts  in  your  filesystem  image;
find  out  the  load  address of the filesystem image in RAM; add the
offset.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Love is an ideal thing, marriage a real thing; a  confusion  of  the
real with the ideal never goes unpunished."                  - Goethe

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: RAMDISK problem

[Joao Vicente]

Hi Gerald

> Dumb questions:
> * What memory address is it writing to on the 37th write when
> it crashes?

My problem is that I dont really know what address the core is trying to write to when the exception occurs.
As I mentioned in the previous message, the write() calls _syscall3() macro which will perform the write operation, but early  in that macro the assembly 'sc' instruction is called.
As I cannot step through 'sc', I cannot go further on investigating at what write access the exception occurs.
My question is then:

How do I even find out what is the start address of the file associated with the file descritor?

> * Can you read and write that memory from the command line?
> * If you zero the memory before doing the load, what is in
> that memory area
>   a) Before it crashes (set a breakpoint after say 30 writes)
>   b) After it crashes?
> * Is the memory area close to a power-of-two address -- could you
>     have a memory map problem where you think you have x Kbytes but
>     the hardware/MMU is only properly decoding x/2 Kbytes or
> x/4 Kbytes?
>
> Given the repeatability, this sounds like a hardware problem
> or a software configuration problem (loading over top of
> important information like the stack or the currently
> executing program or off the end of real memory, off the end
> of the memory that is validly mapped via the BATs, etc.).
>
> gvb

Best regards

Joao Vicente



>
>
> > -----Original Message-----
> > From: Joao Vicente [mailto:joao.vicente@spectel.com]
> > Sent: Wednesday, November 19, 2003 2:13 PM
> > To: Wolfgang Denk
> > Cc: linuxppc-embedded@lists.linuxppc.org
> > Subject: RE: RAMDISK problem
> >
> >
> >
> > Hi
> >
> > I have gone through the SDRAM initialisation, and the init
> > sequence, on u-boot, and I dont seem to find any discrepancies.
> > I am using a Micron MTLSDT464HG-10EC3 DIMM, and I have it
> > initialised as follows.
> >
> > #define CFG_BR3_PRELIM  ((CFG_SDRAM_BASE & BRx_BA_MSK)  |\
> > 			 BRx_PS_64                      |\
> > 			 BRx_MS_SDRAM_P                 |\
> > 			 BRx_V)
> >
> > #define CFG_OR3_PRELIM  ((~(CFG_GLOBAL_SDRAM_LIMIT-1) &
> > ORxS_SDAM_MSK) |\
> >       ORxS_PMSEL                     |\
> >       ORxS_BPD_4                     |\
> >       ORxS_ROWST_PBI0_A9             |\
> >       ORxS_NUMR_12)
> >
> > #define CFG_PSDMR_PRELIM (PSDMR_BSMA_A14_A16  |\
> >       PSDMR_SDA10_PBI0_A9               |\
> >       PSDMR_RFRC_3_CLK                  |\
> >       PSDMR_PRETOACT_1W                 |\
> >       PSDMR_ACTTORW_1W                  |\
> >       PSDMR_LDOTOPRE_1C                 |\
> >       PSDMR_WRC_2C                      |\
> >       PSDMR_CL_2)
> >
> > On the SDRAM init sequence
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_PREA;
> > 	*base = c;
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_CBRR;
> > 	for (i = 0; i < 8; i++)
> > 		*base = c;
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_MRW;
> > 	*(base + CFG_MRS_OFFS) = c;	/* setting MR on
> > address lines */
> >
> > 	*sdmr_ptr = sdmr | PSDMR_OP_NORM | PSDMR_RFEN;
> > 	*base = c
> >
> > I am setting the Mode Register Set Command to
> > #define CFG_MRS_OFFS	0x00000110
> >
> > which sets:
> > Programmable burst mode
> > Burst Length = 4
> > Burst Type = Sequential (also tried interleaved)
> > CAS latency = 2
> >
> > I have also confirmed that the uP is (Write) bursting from
> > the first time write() is called (and even before that) by
> > measuring the pulse width on WEx, verifying that it's pulse
> > is 4x the width of a normal write sequence.
> >
> > I have also debugged further, and I got much closer to the
> > exception point.
> >
> > crd_load() 			(from ./init/do_mounts.c)
> > |_ gunzip()
> >    |_ inflate()
> >       |_ inflate_block()
> >          |_ inflate_dynamic()
> >             |_ inflate_codes()
> >                |_ flush_output()
> >                   |_ flush_window()
> >                      |_write(crd_outfd, window, outcnt)
> >
> > The last function call before the exception seems to be
> > writing a decompressed 32k'outcount' chunk of data pointed by
> >  'window' onto a targey file specified by the crd_outfd file
> > descriptor.
> >
> > Notice the system ALLWAYS crashes after the 37th time the
> > write() function is called.
> > This also points more onto a software/configuration fault
> > than a burst problem with SDRAM (correct me if I am wrong)
> >
> > Another problem is that write() function will invoke
> > static inline _syscall3(int,write,int,fd,const char
> *,buf,off_t,count)
> >
> > Early in this call the assembly 'sc' instruction will be
> > executed which prevents me from stepping through the call,
> > and  finding out exactly at what point the exception occurs.
> >
> > I would appeciate suggestions onto carrying out debugging
> > from this point, or any other suggestions on how to fix the
>  problem.
> >
> > Thanks in advance
> >
> > Joao Vicente
> >
> > > -----Original Message-----
> > > From: Wolfgang Denk [mailto:wd@denx.de]
> > > Sent: Wednesday, November 12, 2003 7:46 PM
> > > To: Joao Vicente
> > > Cc: linuxppc-embedded@lists.linuxppc.org
> > > Subject: Re: RAMDISK problem
> > >
> > >
> > > Dear Joao,
> > >
> > > in message
> > > <DEF39A0710293E489D45B10E06645CBD026719AB@dub-msx1.spectelcorp
> > > .com> you wrote:
> > > >
> > > > The SDRAM parameters used for initialisation have been
> > > fully verified
> > >
> > > Parameters is one thing, the init sequence is  another
> > story.  Boith
> > > are  required,  or you will see strange crashes as soon as
> > the system
> > > starts using burst mode heavily.
> > >
> > > > with this board, as we have used them with another RTOS,
> > without any
> > > > problem.
> > >
> > > That does not mean anything. Really. We have seen boards
> > that used to
> > > run pSOS+ for years without problem, but would crash
> > reliably  under
> > > Linux. The problems went away after fixing the RAM initialization.
> > >
> > > Your problem is a FAQ on the PPCboot / U-Boot mailing lists.
> > >
> > > > Aditionaly I ran the u-boot mtest utility on sections of
> > the RAM to
> > > > ensure the configuration was good.
> > >
> > > Again, that doesn't mean anything, as this test performs
> > simple  read
> > > / write cycles. It will not cause any accesses in burst mode.
> > >
> > > > I believe that rules out bad SDRAM configuration.
> > >
> > > I disagree. I've seen this too many times before.
> > >
> > > > I thought that could give me an idea if inflate was writing
> > > outside the
> > > > valid
> > > > virtual address range.
> > >
> > > I think you're on the wrong track. But I may be wrong, of course.
> > >
> > > Best regards,
> > >
> > > Wolfgang Denk
> > >
> > > --
> > > Software Engineering:  Embedded and Realtime Systems,
> > Embedded Linux
> > > Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email:
> > wd@denx.de
> > > "Just Say No."   - Nancy Reagan
> > > "No."            - Ronald Reagan
> > >
> >
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: RAMDISK problem

[VanBaren, Gerald (AGRE)]

Dumb questions:
* What memory address is it writing to on the 37th write when it crashes?
* Can you read and write that memory from the command line?
* If you zero the memory before doing the load, what is in that memory area
  a) Before it crashes (set a breakpoint after say 30 writes)
  b) After it crashes?
* Is the memory area close to a power-of-two address -- could you
    have a memory map problem where you think you have x Kbytes but
    the hardware/MMU is only properly decoding x/2 Kbytes or x/4 Kbytes?

Given the repeatability, this sounds like a hardware problem or a software configuration problem (loading over top of important information like the stack or the currently executing program or off the end of real memory, off the end of the memory that is validly mapped via the BATs, etc.).

gvb


> -----Original Message-----
> From: Joao Vicente [mailto:joao.vicente@spectel.com]
> Sent: Wednesday, November 19, 2003 2:13 PM
> To: Wolfgang Denk
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: RE: RAMDISK problem
>
>
>
> Hi
>
> I have gone through the SDRAM initialisation, and the init
> sequence, on u-boot, and I dont seem to find any discrepancies.
> I am using a Micron MTLSDT464HG-10EC3 DIMM, and I have it
> initialised as follows.
>
> #define CFG_BR3_PRELIM  ((CFG_SDRAM_BASE & BRx_BA_MSK)  |\
> 			 BRx_PS_64                      |\
> 			 BRx_MS_SDRAM_P                 |\
> 			 BRx_V)
>
> #define CFG_OR3_PRELIM  ((~(CFG_GLOBAL_SDRAM_LIMIT-1) &
> ORxS_SDAM_MSK) |\
>       ORxS_PMSEL                     |\
>       ORxS_BPD_4                     |\
>       ORxS_ROWST_PBI0_A9             |\
>       ORxS_NUMR_12)
>
> #define CFG_PSDMR_PRELIM (PSDMR_BSMA_A14_A16  |\
>       PSDMR_SDA10_PBI0_A9               |\
>       PSDMR_RFRC_3_CLK                  |\
>       PSDMR_PRETOACT_1W                 |\
>       PSDMR_ACTTORW_1W                  |\
>       PSDMR_LDOTOPRE_1C                 |\
>       PSDMR_WRC_2C                      |\
>       PSDMR_CL_2)
>
> On the SDRAM init sequence
>
> 	*sdmr_ptr = sdmr | PSDMR_OP_PREA;
> 	*base = c;
>
> 	*sdmr_ptr = sdmr | PSDMR_OP_CBRR;
> 	for (i = 0; i < 8; i++)
> 		*base = c;
>
> 	*sdmr_ptr = sdmr | PSDMR_OP_MRW;
> 	*(base + CFG_MRS_OFFS) = c;	/* setting MR on
> address lines */
>
> 	*sdmr_ptr = sdmr | PSDMR_OP_NORM | PSDMR_RFEN;
> 	*base = c
>
> I am setting the Mode Register Set Command to
> #define CFG_MRS_OFFS	0x00000110
>
> which sets:
> Programmable burst mode
> Burst Length = 4
> Burst Type = Sequential (also tried interleaved)
> CAS latency = 2
>
> I have also confirmed that the uP is (Write) bursting from
> the first time write() is called (and even before that) by
> measuring the pulse width on WEx, verifying that it's pulse
> is 4x the width of a normal write sequence.
>
> I have also debugged further, and I got much closer to the
> exception point.
>
> crd_load() 			(from ./init/do_mounts.c)
> |_ gunzip()
>    |_ inflate()
>       |_ inflate_block()
>          |_ inflate_dynamic()
>             |_ inflate_codes()
>                |_ flush_output()
>                   |_ flush_window()
>                      |_write(crd_outfd, window, outcnt)
>
> The last function call before the exception seems to be
> writing a decompressed 32k'outcount' chunk of data pointed by
>  'window' onto a targey file specified by the crd_outfd file
> descriptor.
>
> Notice the system ALLWAYS crashes after the 37th time the
> write() function is called.
> This also points more onto a software/configuration fault
> than a burst problem with SDRAM (correct me if I am wrong)
>
> Another problem is that write() function will invoke
> static inline _syscall3(int,write,int,fd,const char *,buf,off_t,count)
>
> Early in this call the assembly 'sc' instruction will be
> executed which prevents me from stepping through the call,
> and  finding out exactly at what point the exception occurs.
>
> I would appeciate suggestions onto carrying out debugging
> from this point, or any other suggestions on how to fix the  problem.
>
> Thanks in advance
>
> Joao Vicente
>
> > -----Original Message-----
> > From: Wolfgang Denk [mailto:wd@denx.de]
> > Sent: Wednesday, November 12, 2003 7:46 PM
> > To: Joao Vicente
> > Cc: linuxppc-embedded@lists.linuxppc.org
> > Subject: Re: RAMDISK problem
> >
> >
> > Dear Joao,
> >
> > in message
> > <DEF39A0710293E489D45B10E06645CBD026719AB@dub-msx1.spectelcorp
> > .com> you wrote:
> > >
> > > The SDRAM parameters used for initialisation have been
> > fully verified
> >
> > Parameters is one thing, the init sequence is  another
> story.  Boith
> > are  required,  or you will see strange crashes as soon as
> the system
> > starts using burst mode heavily.
> >
> > > with this board, as we have used them with another RTOS,
> without any
> > > problem.
> >
> > That does not mean anything. Really. We have seen boards
> that used to
> > run pSOS+ for years without problem, but would crash
> reliably  under
> > Linux. The problems went away after fixing the RAM initialization.
> >
> > Your problem is a FAQ on the PPCboot / U-Boot mailing lists.
> >
> > > Aditionaly I ran the u-boot mtest utility on sections of
> the RAM to
> > > ensure the configuration was good.
> >
> > Again, that doesn't mean anything, as this test performs
> simple  read
> > / write cycles. It will not cause any accesses in burst mode.
> >
> > > I believe that rules out bad SDRAM configuration.
> >
> > I disagree. I've seen this too many times before.
> >
> > > I thought that could give me an idea if inflate was writing
> > outside the
> > > valid
> > > virtual address range.
> >
> > I think you're on the wrong track. But I may be wrong, of course.
> >
> > Best regards,
> >
> > Wolfgang Denk
> >
> > --
> > Software Engineering:  Embedded and Realtime Systems,
> Embedded Linux
> > Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email:
> wd@denx.de
> > "Just Say No."   - Nancy Reagan
> > "No."            - Ronald Reagan
> >
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: RAMDISK problem

[Joao Vicente]

Hi

I have gone through the SDRAM initialisation, and the init sequence, on u-boot, and I dont seem to find any discrepancies.
I am using a Micron MTLSDT464HG-10EC3 DIMM, and I have it initialised as follows.

#define CFG_BR3_PRELIM  ((CFG_SDRAM_BASE & BRx_BA_MSK)  |\
			 BRx_PS_64                      |\
			 BRx_MS_SDRAM_P                 |\
			 BRx_V)

#define CFG_OR3_PRELIM  ((~(CFG_GLOBAL_SDRAM_LIMIT-1) & ORxS_SDAM_MSK) |\
      ORxS_PMSEL                     |\
      ORxS_BPD_4                     |\
      ORxS_ROWST_PBI0_A9             |\
      ORxS_NUMR_12)

#define CFG_PSDMR_PRELIM (PSDMR_BSMA_A14_A16  |\
      PSDMR_SDA10_PBI0_A9               |\
      PSDMR_RFRC_3_CLK                  |\
      PSDMR_PRETOACT_1W                 |\
      PSDMR_ACTTORW_1W                  |\
      PSDMR_LDOTOPRE_1C                 |\
      PSDMR_WRC_2C                      |\
      PSDMR_CL_2)

On the SDRAM init sequence

	*sdmr_ptr = sdmr | PSDMR_OP_PREA;
	*base = c;

	*sdmr_ptr = sdmr | PSDMR_OP_CBRR;
	for (i = 0; i < 8; i++)
		*base = c;

	*sdmr_ptr = sdmr | PSDMR_OP_MRW;
	*(base + CFG_MRS_OFFS) = c;	/* setting MR on address lines */

	*sdmr_ptr = sdmr | PSDMR_OP_NORM | PSDMR_RFEN;
	*base = c

I am setting the Mode Register Set Command to
#define CFG_MRS_OFFS	0x00000110

which sets:
Programmable burst mode
Burst Length = 4
Burst Type = Sequential (also tried interleaved)
CAS latency = 2

I have also confirmed that the uP is (Write) bursting from the first time write() is called (and even before that) by  measuring the pulse width on WEx, verifying that it's pulse is 4x the width of a normal write sequence.

I have also debugged further, and I got much closer to the exception point.

crd_load() 			(from ./init/do_mounts.c)
|_ gunzip()
   |_ inflate()
      |_ inflate_block()
         |_ inflate_dynamic()
            |_ inflate_codes()
               |_ flush_output()
                  |_ flush_window()
                     |_write(crd_outfd, window, outcnt)

The last function call before the exception seems to be writing a decompressed 32k'outcount' chunk of data pointed by  'window' onto a targey file specified by the crd_outfd file descriptor.

Notice the system ALLWAYS crashes after the 37th time the write() function is called.
This also points more onto a software/configuration fault than a burst problem with SDRAM (correct me if I am wrong)

Another problem is that write() function will invoke
static inline _syscall3(int,write,int,fd,const char *,buf,off_t,count)

Early in this call the assembly 'sc' instruction will be executed which prevents me from stepping through the call, and  finding out exactly at what point the exception occurs.

I would appeciate suggestions onto carrying out debugging from this point, or any other suggestions on how to fix the  problem.

Thanks in advance

Joao Vicente

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd@denx.de]
> Sent: Wednesday, November 12, 2003 7:46 PM
> To: Joao Vicente
> Cc: linuxppc-embedded@lists.linuxppc.org
> Subject: Re: RAMDISK problem
>
>
> Dear Joao,
>
> in message
> <DEF39A0710293E489D45B10E06645CBD026719AB@dub-msx1.spectelcorp
> .com> you wrote:
> >
> > The SDRAM parameters used for initialisation have been
> fully verified
>
> Parameters is one thing, the init sequence is  another  story.  Boith
> are  required,  or you will see strange crashes as soon as the system
> starts using burst mode heavily.
>
> > with this board, as we have used them with another RTOS, without any
> > problem.
>
> That does not mean anything. Really. We have seen boards that used to
> run pSOS+ for years without problem, but would crash  reliably  under
> Linux. The problems went away after fixing the RAM initialization.
>
> Your problem is a FAQ on the PPCboot / U-Boot mailing lists.
>
> > Aditionaly I ran the u-boot mtest utility on sections of the RAM to
> > ensure the configuration was good.
>
> Again, that doesn't mean anything, as this test performs simple  read
> / write cycles. It will not cause any accesses in burst mode.
>
> > I believe that rules out bad SDRAM configuration.
>
> I disagree. I've seen this too many times before.
>
> > I thought that could give me an idea if inflate was writing
> outside the
> > valid
> > virtual address range.
>
> I think you're on the wrong track. But I may be wrong, of course.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
> "Just Say No."   - Nancy Reagan
> "No."            - Ronald Reagan
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RAMDISK problem

[Wolfgang Denk]

In message <AB5AF73EAF23304EA1B932174137CED703042C@m5tmail.m5t.com> you wrote:
>
> A silly question but...
> Why does U-boot report a ramdisk size of about 555kB,

He  was  using  the  old  "simple-ramdisk.PPCBoot"  image  wich   was
optimized for size. It is really just 550 kB.

> while the original from Denx's ftp server has a size of 1.33MB ?

You mean a different image (the SELF based one).


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"My doctor told me to stop having intimate dinners for  four.  Unless
there are three other people."                         - Orson Welles

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: RAMDISK problem

[Jean-Denis Boyer]

A silly question but...
Why does U-boot report a ramdisk size of about 555kB,
while the original from Denx's ftp server has a size of 1.33MB ?

Is it possible that the kernel runs out of data while booting ?
Or may be you just strip the ramdisk image?
If so, what is the expected size once it is uncompressed?
Would it be advisable to increase the CONFIG_BLK_DEV_RAM_SIZE?

Regards,

--------------------------------------------
 Jean-Denis Boyer, Eng.
 M5T Centre d'Excellence en Télécom Inc.
 4283 Garlock Street
 Sherbrooke (Québec)
 J1L 2C8  CANADA
 (819)829-3972 x241
--------------------------------------------

> -----Original Message-----
> From: owner-linuxppc-embedded@lists.linuxppc.org
> [mailto:owner-linuxppc-embedded@lists.linuxppc.org]On Behalf Of Joao
> Vicente
> Sent: 11 novembre, 2003 10:45
> To: linuxppc-embedded@lists.linuxppc.org
> Subject: RAMDISK problem
>
>
>
> Hi
>
> I am struggling with a problem where I dont seem to be able
> to mount a boot filesystem from a RAMDISK.
> I am using the sample RAMDisk root filesystem available from
> Denx's ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/
>
[...]
>
> ## Checking Image at 03000000 ...
>    Image Name:   Simple Ramdisk-Image
>    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
>    Data Size:    567988 Bytes = 554.7 kB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> ## Booting image at 00100000 ...
>    Image Name:   Linux-2.4.20
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    595016 Bytes = 581.1 kB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
>    Uncompressing Kernel Image ... OK
>
[...]

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RAMDISK problem

[Wolfgang Denk]

Dear Joao,

in message <DEF39A0710293E489D45B10E06645CBD026719AB@dub-msx1.spectelcorp.com> you wrote:
>
> The SDRAM parameters used for initialisation have been fully verified

Parameters is one thing, the init sequence is  another  story.  Boith
are  required,  or you will see strange crashes as soon as the system
starts using burst mode heavily.

> with this board, as we have used them with another RTOS, without any
> problem.

That does not mean anything. Really. We have seen boards that used to
run pSOS+ for years without problem, but would crash  reliably  under
Linux. The problems went away after fixing the RAM initialization.

Your problem is a FAQ on the PPCboot / U-Boot mailing lists.

> Aditionaly I ran the u-boot mtest utility on sections of the RAM to
> ensure the configuration was good.

Again, that doesn't mean anything, as this test performs simple  read
/ write cycles. It will not cause any accesses in burst mode.

> I believe that rules out bad SDRAM configuration.

I disagree. I've seen this too many times before.

> I thought that could give me an idea if inflate was writing outside the
> valid
> virtual address range.

I think you're on the wrong track. But I may be wrong, of course.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Just Say No."   - Nancy Reagan
"No."            - Ronald Reagan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: RAMDISK problem

[Steven Blakeslee]

did you add a configuration line command like root=/dev/ram0

-----Original Message-----
From: Joao Vicente [mailto:joao.vicente@spectel.com]
Sent: Tuesday, November 11, 2003 10:45 AM
Subject: RAMDISK problem

I am struggling with a problem where I dont seem to be
able to mount a boot filesystem from a RAMDISK. I am using
the sample RAMDisk root filesystem available from Denx's
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/

On the config file I have the following lines:
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_CRAMFS=y
CONFIG_RAMFS=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y

I've browsed through a lot of threads relating to problems mounting the
root filsystem from RAM but I failed to see a similar symptom to this,
with a response.

I would appreciate any suggestion from perhaps somebody that has gone
through this problem already.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RAMDISK problem

[Wolfgang Denk]

Dear Joao,

in message <DEF39A0710293E489D45B10E06645CBD026718F8@dub-msx1.spectelcorp.com> you wrote:
>
> CPU:   MPC8260 (HiP3 Rev 01, Mask C.2 6K23A) at 133.333 MHz
> Board: Spectel MC3
> DRAM:  (60x:?COL - 16 MB, 16 MB
-------------^^^

Are you sure your SDRAM initialization is correct?

> RAMDISK: Compressed image found at block 0
> Machine check in kernel mode.
> Caused by (from SRR1=41000): Transfer error ack signal
> Oops: machine check, sig: 7
> NIP: 0000113C XER: 00000000 LR: C0006628 SP: C0FBD4F0 REGS: c0fbd440 TRAP:
> 0200
>    Not tainted
> MSR: 00041000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
> TASK = c0fbc000[59392] '' Last syscall: 3
> last math 00000000 last altivec 00000000
> GPR00: 00000000 C0FBD4F0 C0FBC000 C0FBD540 00000000 00000120 00000005 00000005
> GPR08: C0FBD4F8 4E81001B 00000000 00000000 22004042 950A0000 0000003F C0110000
> GPR16: C0150000 C0EE4008 C0EE7008 C0150000 00009032 00FBD530 00000000 C0006074
> GPR24: C0006610 4E80FFFF 00000000 00000001 C0FBD540 00000004 00000009 4E81001B
> Call backtrace:
> 0000007B C0006628 C0006074 000000BB C0006074 C00304D0 C001EA88
> C001EAB4 C000A9D4 C0005EA4 00000000 00000083 Machine check in kernel mode.

Did you bother to decode the cal backtrace?

And are you really, really sure that  your  SDRAM  initialization  is
complete  and  correct? Remember that there is more to do than to set
up the memory controller.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Time is a drug. Too much of it kills you.
                                      - Terry Pratchett, _Small Gods_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RAMDISK problem

[Joao Vicente]

Hi

I am struggling with a problem where I dont seem to be able to mount a boot filesystem from a RAMDISK.
I am using the sample RAMDisk root filesystem available from Denx's ftp://ftp.denx.de/pub/LinuxPPC/usr/src/SELF/images/ppc_82xx/

On the config file I have the following lines:
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
CONFIG_BLK_DEV_INITRD=y
CONFIG_CRAMFS=y
CONFIG_RAMFS=y
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
CONFIG_EXT2_FS=y

I've browsed through a lot of threads relating to problems mounting the root filsystem from RAM but I failed to see a similar  symptom to this, with a response.

I would appreciate any suggestion from perhaps somebody that has gone through this problem already.

Thanks in advance

Joao Vicente




U-Boot 0.4.5 (Nov 10 2003 - 18:11:40)

MPC8260 Reset Status: External Soft, External Hard

MPC8260 Clock Configuration
 - Bus-to-Core Mult 4x, VCO Div 2, 60x Bus Freq  25-75 , Core Freq 100-300
 - dfbrg 1, corecnf 0x0a, busdf 7, cpmdf 1, plldf 0, pllmf 3
 - vco_out  266666664, scc_clk   66666666, brg_clk   16666666
 - cpu_clk  133333332, cpm_clk  133333332, bus_clk   33333333

CPU:   MPC8260 (HiP3 Rev 01, Mask C.2 6K23A) at 133.333 MHz
Board: Spectel MC3
DRAM:  (60x:?COL - 16 MB, 16 MB
Top of RAM usable for U-Boot at: 01000000
Reserving 170k for U-Boot at: 00fd5000
Reserving 136k for malloc() at: 00fb3000
Reserving 76 Bytes for Board Info at: 00fb2fb4
Reserving 72 Bytes for Global Data at: 00fb2f6c
Stack Pointer at: 00fb2f48
New Stack Pointer is: 00fb2f48
Now running in RAM - U-Boot at: 00fd5000
FLASH:   4 MB
In:    serial
Out:   serial
Err:   serial
Reset Ethernet PHY
miiphy_read(0x4) @ 0x0 = 0x01e1
U-Boot relocated to 00fd5000
Net:   FCC1 ETHERNET
### main_loop entered: bootdelay=5

### main_loop: bootcmd="tftp 0x100000 $(bootfile);bootm"
Hit any key to stop autoboot:  0
=> run ramboot
Trying FCC1 ETHERNET
TFTP from server 10.121.10.150; our IP address is 10.121.10.23
Filename './spc_mc3/uImage'.
Load address: 0x100000
Loading: ######################T ##########T T
##################################
         ###T #################################################
done
Bytes transferred = 595080 (91488 hex)

## Checking Image at 03000000 ...
   Image Name:   Simple Ramdisk-Image
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    567988 Bytes = 554.7 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Booting image at 00100000 ...
   Image Name:   Linux-2.4.20
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:    595016 Bytes = 581.1 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Current stack ends at 0x00FB2928 => set upper limit to 0x00800000
## cmdline at 0x007FFF00 ... 0x007FFF60
bd address  = 0x00FB2FB4
memstart    = 0x00000000
memsize     = 0x01000000
flashstart  = 0x03000000
flashsize   = 0x00400000
flashoffset = 0x00000000
sramstart   = 0x00000000
sramsize    = 0x00000000
immr_base   = 0xF0000000
bootflags   = 0x00000001
vco         = 266.666 MHz
sccfreq     = 66.666 MHz
brgfreq     = 16.666 MHz
intfreq     = 133.333 MHz
cpmfreq     = 133.333 MHz
busfreq     = 33.333 MHz
ethaddr     = 00:D0:9B:00:00:F9
IP addr     = 10.121.10.23
baudrate    = 115200 bps
## Loading RAMDisk Image at 03000000 ...
   Image Name:   Simple Ramdisk-Image
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:    567988 Bytes = 554.7 kB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## initrd at 0x03000040 ... 0x0308AAF3 (len=567988=0x8AAB4)
   Loading Ramdisk to 00f27000, end 00fb1ab4 ... OK
## Transferring control to Linux (at address 00000000) ...
REVISIT - MMU_setup entered
Memory BAT mapping: BAT2=16Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.20 (jvicente@lab00056l.localdomain) (gcc version 2.95.4
20010319 (prerelease/franzo/20011204)) #1 Tue Nov 11 11:29:23 GMT 2003
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/ram rw
ip=10.121.10.23:10.121.10.150:10.121.10.254:255.255.255.0:mc3_joao::off
mem=16M
IP-Config: Parameter #0: `10.121.10.23'
IP-Config: Parameter #1: `10.121.10.150'
IP-Config: Parameter #2: `10.121.10.254'
IP-Config: Parameter #3: `255.255.255.0'
IP-Config: Parameter #4: `mc3_joao'
IP-Config: Parameter #6: `off'
Warning: real time clock seems stuck!
Calibrating delay loop... 88.67 BogoMIPS
Memory: 14096k available (1084k kernel code, 400k data, 52k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
JFFS version 1.0, (C) 1999, 2000  Axis Communications AB
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
CPM UART driver version 0.01
ttyS0 on SCC1 at 0x8000, BRG7
ttyS1 on SCC2 at 0x8100, BRG1
ttyS2 on SCC3 at 0x8200, BRG2
ttyS3 on SCC5 at 0x8300, BRG4
pty: 256 Unix98 ptys configured
eth0: FCC1 ENET Version 0.4, 00:D0:9B:00:00:F9
eth0: Phy @ 0x0, type LXT971 (0x001378e2)
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
CFI: Found no TQM8260 Bank 0 device at location zero
TQM8260: No supported flash chips found!
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 1024)
IP-Config: Entered.
eth0: config: auto-negotiation on, 100FDX, 100HDX, 10FDX, 10HDX.
IP-Config: eth0 UP (able=0, xid=00000000)
IP-Config: Complete:
      device=eth0, addr=10.121.10.23, mask=255.255.255.0, gw=10.121.10.254,
     host=mc3_joao, domain=, nis-domain=(none),
     bootserver=10.121.10.150, rootserver=10.121.10.150, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
RAMDISK: Compressed image found at block 0
Machine check in kernel mode.
Caused by (from SRR1=41000): Transfer error ack signal
Oops: machine check, sig: 7
NIP: 0000113C XER: 00000000 LR: C0006628 SP: C0FBD4F0 REGS: c0fbd440 TRAP:
0200
   Not tainted
MSR: 00041000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK = c0fbc000[59392] '' Last syscall: 3
last math 00000000 last altivec 00000000
GPR00: 00000000 C0FBD4F0 C0FBC000 C0FBD540 00000000 00000120 00000005 00000005
GPR08: C0FBD4F8 4E81001B 00000000 00000000 22004042 950A0000 0000003F C0110000
GPR16: C0150000 C0EE4008 C0EE7008 C0150000 00009032 00FBD530 00000000 C0006074
GPR24: C0006610 4E80FFFF 00000000 00000001 C0FBD540 00000004 00000009 4E81001B
Call backtrace:
0000007B C0006628 C0006074 000000BB C0006074 C00304D0 C001EA88
C001EAB4 C000A9D4 C0005EA4 00000000 00000083 Machine check in kernel mode.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RAMDISK Problem

[Kamalesh B]

hello,

I have a problem in booting linux 2.4.1 with RAMDISK on MPC8260ADS using
PPCBOOT.

After downloading kernel and ramdisk (simple-ramdisk.PPCBoot) image to
RAM using TFTP application and giving bootm command, it just hangs.

As u people suggested to dump "log_buf" contents, i got dump indicating
that it is hanging after reading the command line options in init.c.

--- Memory dump starts ---
=> md 0x127654 0x70
00127654: 3c343e72 343a2030 30656434 3030300a    <4>r4: 00ed4000.
00127664: 3c343e54 6f74616c 206d656d 6f727920    <4>Total memory
00127674: 3d203136 4d423b20 7573696e 67203634    = 16MB; using 64
00127684: 6b422066 6f722068 61736820 7461626c    kB for hash tabl
00127694: 65202861 74206330 31353030 3030290a    e (at c0150000).
001276a4: 3c343e4c 696e7578 20766572 73696f6e    <4>Linux version
001276b4: 20322e34 2e312028 726f6f74 40736869     2.4.1 (root@shi
001276c4: 76612920 28676363 20766572 73696f6e    va) (gcc version
001276d4: 20322e39 352e3320 32303031 30333135     2.95.3 20010315
001276e4: 20287265 6c656173 65292920 23312057     (release)) #1 W
001276f4: 6564204d 61722031 32203135 3a32323a    ed Mar 12 15:22:
00127704: 31352055 54432032 3030330a 3c343e4f    15 UTC 2003.<4>O
00127714: 6e206e6f 64652030 20746f74 616c7061    n node 0 totalpa
00127724: 6765733a 20343039 360a3c34 3e7a6f6e    ges: 4096.<4>zon
00127734: 65283029 3a203430 39362070 61676573    e(0): 4096 pages
00127744: 2e0a3c34 3e7a6f6e 65283129 3a203020    ..<4>zone(1): 0
00127754: 70616765 732e0a3c 343e7a6f 00000000    pages..<4>zo....
00127764: 00000000 00000000 00000000 00000000    ................
00127774: 00000000 00000000 00000000 00000000    ................
00127784: 00000000 00000000 00000000 00000000    ................
00127794: 00000000 00000000 00000000 00000000    ................
001277a4: 00000000 00000000 00000000 00000000    ................
001277b4: 00000000 00000000 00000000 352e302e    ............5.0.
001277c4: 303a7368 6976613a 6f66660a 00000000    0:shiva:off.....
001277d4: 00000000 00000000 00000000 00000000    ................
--- Memory dump ends ---

Iam stuck at this point.

bootargs command passed:
root=/dev/ram ip=10.1.40.175:10.1.40.176:10.1.1.1:255.255.0.0:shiva::off

Is there any problem with this command?

I have selected Ramdisk support during linux configuration settings. Is
there any other option i have missed?

thanks in advance,
with rgds,
kamal


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: RAMDISK Problem

[Wolfgang Denk]

In message <3E63484A.6340720C@tataelxsi.co.in> you wrote:
>
> Iam working on MPC8260ADS and trying to boot linux-2.4.1 in a standalone
> mode without NFS support.

2.4 1. is very old.  Did  you  make  sure  that  the  "clocks_in_mhz"
variable is set in your PPCBoot environment?

> I loaded both kernel image which was booting earlier with NFS system and

I understand the NFS based kernel was working on your system?

> newly downloaded ramdisk at address 100000 and 200000 respectively. And
> i also updated the bootargs environment variable as
> ---
> setenv bootargs root=/dev/ram
> ip=10.1.40.176:10.1.40.175:10.1.1.1:255.255.0.0:10.1.40.175::off
> ---
>
> where,
> target ip = 10.1.40.176
> server ip = 10.1.40.175
> gateway ip = 10.1.1.1

You should not configure a gateway address when you need none.

> netmask = 255.255.0.0
> host name = 10.1.40.175

This is an IP address, but not a host name.

[Not that teither of these would cause the boot to fail.]

>      Verifying Checksum ... OK
>      Loading Ramdisk to 00ed4000, end 00f5eab4 ... OK
>
>     [After this, no messages]

If your NFS based kernel was working correctly, you should  at  least
see  the  same  boot  messages  until  it  tires  to  mount  the root
filesystem.

> I am stuck at this point and don't know what could be the reason. Can
> somebody help me?

Attach a debugger (BDI2000) and check where it's hanging.

As a poor man's solution, try to find out if a  post-mortem  dump  of
the  log_buf area contains some information: grep the System.map file
in your kernel directory for the virtual  address  of  "log_buf"  and
subtract 0xC0000000 to get the physical address; when you board hangs
press  the  reset  button  and  use PPCBoot's "md" command to print a
memory dump of this area.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Put your Nose to the Grindstone!
                 -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RAMDISK Problem

[Kamalesh B]

hello,

As suggested, i downloaded the "simple-ramdisk.PPCBoot" from ftp site
and also went thru the dplg.pdf file to know more about PPCBoot.

Iam working on MPC8260ADS and trying to boot linux-2.4.1 in a standalone
mode without NFS support.

I loaded both kernel image which was booting earlier with NFS system and
newly downloaded ramdisk at address 100000 and 200000 respectively. And
i also updated the bootargs environment variable as
---
setenv bootargs root=/dev/ram
ip=10.1.40.176:10.1.40.175:10.1.1.1:255.255.0.0:10.1.40.175::off
---

where,
target ip = 10.1.40.176
server ip = 10.1.40.175
gateway ip = 10.1.1.1
netmask = 255.255.0.0
host name = 10.1.40.175

I have checked ip addresses for correctness.

After all this, i gave bootm 100000 200000 command.

Output:
After loading kernel image and ramdisk image, it is hanging!!!

--- Messages ---

## Booting Linux kernel at 10100000 ...
     Image Name: Linux-2.4.1
     Image Type: PowerPC Linux Kernel Image (gzip compressed)
     Data Size: 400259 Bytes = 390 kB = 0 MB
     Load Address: 00000000
     Entry Point: 00000000
     Verifying Checksum ... OK
     Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 10200000 ...
     Image Name: Simple Ramdisk Image
     Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
     Data Size: 507630 Bytes = 495 kB = 0 MB
     Load Address: 00000000
     Entry Point: 00000000
     Verifying Checksum ... OK
     Loading Ramdisk to 00ed4000, end 00f5eab4 ... OK

    [After this, no messages]
--- Messages ---

I am stuck at this point and don't know what could be the reason. Can
somebody help me?

thanks in advance,
with rgds,
kamal


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ramdisk problem

[Wolfgang Denk]

In message <20020613152000.18777.qmail@webmail22.rediffmail.com> you wrote:
>
>       i use kernel provided bootloader to load image,

This is not what I mean. You must have some sort of firmware  running
on  this board. Obviously it is not PPCBoot, because then things were
very simple.

There are firmware implementations which can  load  ELF  images,  but
either  load only "conventional" segments (text, data) or those which
have the "LOAD" flag set. The "zImage.initrd"  contains  non-standard
segments  ("image"  and  "initrd"),  which don't have the "LOAD" flag
set. Maybe your firmware does not load all segments...

>   i am using binary form of zImage
>   i didnt get u denk ,i dont know abt this elf what u have said ,i
> am not sure abt it ,i will check it

Maybe reading the "Linux for PowerPC Embedded Systems HOWTO" gives
some additional information, see
http://penguinppc.org/embedded/howto/PowerPC-Embedded-HOWTO.html

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Do not simplify the design of a program if a way can be found to make
it complex and wonderful.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: ramdisk problem

[Wolfgang Denk]

In message <20020613134334.24727.qmail@webmail21.rediffmail.com> you wrote:
>
> after compiling zImage i give command make zImage.initrd
> so that r4,r5 contain initrd offset and size
> i am getting initrd offset as 9099b
>
> initrd_load routine is called ,he is checking at this loaction for
> start of ramdisk image ,he is not getting it, so he says couldnt
> find valid ramdisk image
>
> what can be the problem

How do you load the image? Linux uses a special segment  in  the  ELF
file  for the initrd image; maybe your bot loader does not understand
this, and drops it?

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Have you lived in this village all your life?"        "No, not yet."

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/