headers
Wolfgang Denk | 1 Oct 2001 09:00
Picon
Picon
Favicon

Re: mkimage fails in ppcboot-1.0.2

Hi,

in message <3BB0D93B.EDCEC477 <at> emc.com> you wrote:
> 
> mkimage works fine on i386/redhat.
> even a mkimage compiled on an i386/mandrake works on i386/redhat.
> But mkimage failed to put "magic number" in image header on these 2
> machines,
> one G4/debian, one i386/mandrake.

The dump you included below shows that not only the magic number, but
the whole image header was not written.

> linux%od -h vmlinux.binary | more
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000100 6000 0000 6000 0000 6000 0000 7c7f 1b78
> 
> Anybody reported this before ?

Yes, this was a problem in older versions of "mkimage", but only when
the output file was on a NFS  mounted  filesystem.  The  problem  was
fixed in March, and all PPCBoot versions starting with 0.9.3-pre0 and
later work fine.

Your subject mentions PPCBoot 1.0.2 - please make sure that you don't
have an old version of "mkimage" somewhere in your PATH.

Hope this helps,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Oct 2001 09:00
Picon
Picon
Favicon

[Ppcboot-users] Re: mkimage fails in ppcboot-1.0.2

Hi,

in message <3BB0D93B.EDCEC477 <at> emc.com> you wrote:
> 
> mkimage works fine on i386/redhat.
> even a mkimage compiled on an i386/mandrake works on i386/redhat.
> But mkimage failed to put "magic number" in image header on these 2
> machines,
> one G4/debian, one i386/mandrake.

The dump you included below shows that not only the magic number, but
the whole image header was not written.

> linux%od -h vmlinux.binary | more
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000100 6000 0000 6000 0000 6000 0000 7c7f 1b78
> 
> Anybody reported this before ?

Yes, this was a problem in older versions of "mkimage", but only when
the output file was on a NFS  mounted  filesystem.  The  problem  was
fixed in March, and all PPCBoot versions starting with 0.9.3-pre0 and
later work fine.

Your subject mentions PPCBoot 1.0.2 - please make sure that you don't
have an old version of "mkimage" somewhere in your PATH.

Hope this helps,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Oct 2001 09:00
Picon
Picon
Favicon

Re: [Ppcboot-users] what does CFG_CLKS_IN_HZ control ???

Dear Stuart,

in message <3BB43DAB.778E57A2 <at> lineo.com> you wrote:
> I was just wondering what CFG_CLKS_IN_HZ controls.  It seems like it
> only affects the booting of Linux (I noticed that it affected the baud
> rate setting for instance).  Can anyone explain what else it does, e.g
> when should it be set and when should it not.

This option is obsolete.  You should not use it at all.

Have a look at the CHANGELOG file:

...
* PPCBoot stores all clock information in Hz internally.

  ####################################################################
  # WARNING:                                                         #
  # This will cause binary incompatibility with older Linux kernels! #
  ####################################################################

  For binary compatibility with older Linux kernels (which expect the
  clocks passed in the bd_info data to be in MHz) the environment
  variable "clock_in_mhz" can be defined so that PPCBoot converts
  clock data to MHZ before passing it to the Linux kernel. When
  CONFIG_CLOCKS_IN_MHZ is defined in the board config file, a
  definition of "clock_in_mhz=1" is automatically included in the
  default environment.

  NOTE: for all boards that did not use the (now obsolete)
  CFG_CLKS_IN_HZ option such a #define has been added to the config
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wolfgang Denk | 1 Oct 2001 09:00
Picon
Picon
Favicon

Re: [Ppcboot-users] what does CFG_CLKS_IN_HZ control ???

Dear Stuart,

in message <3BB43DAB.778E57A2 <at> lineo.com> you wrote:
> I was just wondering what CFG_CLKS_IN_HZ controls.  It seems like it
> only affects the booting of Linux (I noticed that it affected the baud
> rate setting for instance).  Can anyone explain what else it does, e.g
> when should it be set and when should it not.

This option is obsolete.  You should not use it at all.

Have a look at the CHANGELOG file:

...
* PPCBoot stores all clock information in Hz internally.

  ####################################################################
  # WARNING:                                                         #
  # This will cause binary incompatibility with older Linux kernels! #
  ####################################################################

  For binary compatibility with older Linux kernels (which expect the
  clocks passed in the bd_info data to be in MHz) the environment
  variable "clock_in_mhz" can be defined so that PPCBoot converts
  clock data to MHZ before passing it to the Linux kernel. When
  CONFIG_CLOCKS_IN_MHZ is defined in the board config file, a
  definition of "clock_in_mhz=1" is automatically included in the
  default environment.

  NOTE: for all boards that did not use the (now obsolete)
  CFG_CLKS_IN_HZ option such a #define has been added to the config
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerry Van Baren | 1 Oct 2001 16:18

Re: [Ppcboot-users] Flash Booting problem

You still haven't told us what JTAG hardware you are using for 
debugging.  You have GDB-5.0.  This is the _software_ that is running 
the debugger, you still need some way of interacting with the 
hardware.  What is the name of the box that plugs into the 16 (or so) 
pin header?

You haven't correctly answered my question on the state of the RSTCONF* 
pin (C5 on the MPC823).  This pin allows you to force a default reset 
config word to be 0x0000 (if it is high) or the MPC823 fetches the Hard 
Reset Config from memory if you have this pin low.  If you have this 
pin high, the processor will ignore your HRCW in flash.
--------
 From the manual:
Reset Configuration

This input signal is sampled by the MPC823e during the assertion of the 
HRESET signal. If it is asserted [active low - gvb], the configuration 
mode is sampled in the form of the hard reset configuration word driven 
on the data bus. When this signal is negated, the default configuration 
mode is adopted by the MPC823e. Notice that the initial base address of 
internal registers is determined in this sequence.
--------

Something isn't consistent here.  You have your ISB set to 11 
(0xFFF00000 initial PC in your message, I assume that is a typo, it 
should be 0xFFF00100), but your register dump shows SRR0 to be 
0x00000100 which is the hardware reset vector if the initial PC is 
prefixed with zeros.  Maybe this is OK, but it seems quite suspicious.

What is your JTAG debugger configuration?  It may be setting a 0-prefix
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jure Menart | 1 Oct 2001 21:41

[Ppcboot-users] problems with ide read/write functions

Hi all,
when we use functions ide read/write we get back error:
	(example:)
	ide read 200000 0 16
	5: blocks read ERROR
it happens every time when we use ide read or write function.
Does anyone know what could the problem be?

Thank you, Jure
Permalink | Reply | 3 comments |
headers
Manuel Tovar Dall'Orso | 2 Oct 2001 01:00
Picon

[Ppcboot-users] Flash Booting problem


> You still haven't told us what JTAG hardware you are using for
> debugging.  You have GDB-5.0.  This is the _software_ that is running
> the debugger, you still need some way of interacting with the
> hardware.  What is the name of the box that plugs into the 16 (or so)
> pin header?

The JTAG hardware is a 10 pin interfase header in the board, their signals
 are DSDI, DSD0, DSCK, /SRESET, /HRESET, FRZ#.  The wired was a denx design
Printer Port	JTAG (10 pin interfase board)
DO .............................. DSCK
D1  ............................. DSDI
PAPER  ..................... DSD0
SELECT# ................... HRESET#
BUSY    ...................... FREEZE (FRZ)
ERROR  ...................... FREEZE
ACK     ........................ VDD1
AUTOFEED# .............. SRESET#

The RSTCONF pin (C5) is set to 0
It's used a system with tri-state for upload the data bus the word 0x41E0
in the Hard Reset time.

> Something isn't consistent here.  You have your ISB set to 11
> (0xFFF00000 initial PC in your message, I assume that is a typo, it
> should be 0xFFF00100), but your register dump shows SRR0 to be
> 0x00000100 which is the hardware reset vector if the initial PC is
> prefixed with zeros.  Maybe this is OK, but it seems quite suspicious.

Which are the steps that permit the FLASH bootoloader be written in the RAM
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stuart Hughes | 2 Oct 2001 15:29
Picon

[Ppcboot-users] putting the environment in the same sector

Hi,

Has anyone successfully made a version of ppcboot where the code and the
non-volatile environment reside in the same sector in Flash ??

Looking at the code, it seems like there is provision for this option
(CFG_), but the code itself doesn't copy the ppcboot code from RAM to
the Flash sector.

Although I understand this is a little risky, it would save a lot of
space.  On the board I have, the Flash sectors are 256k, and I'm using 2
of them (one for ppcboot, and one for the environment).  When I look at
the actual size needed, ppcboot takes up ~ 130k and the environment just
a k or so.

Does anyone have any ideas on this ??

--

-- 
Regards, Stuart
Permalink | Reply | 9 comments |
headers
Jerry Van Baren | 2 Oct 2001 16:26

Re: [Ppcboot-users] putting the environment in the same sector

I have no experience but do have an idea to toss out...

Flash can be programmed at a bit-by-bit level from a '1' bit to a '0' 
bit, but a whole sector has to be erased to get the bits back to 
'1's.  If "we" (that's you, Stuart :-) enhanced the environment saving 
code somewhat, we could invalidate an old environment and append a new 
environment to where the old environment was, we could store a whole 
lot of changes before having to erase the sector and start over.

My thought is to have the environment storage start at a fixed place, 
as it is now, and have one additional variable in the environment 
structure: a "next environment" pointer.  If the "next environment" 
pointer is 0xFFFFFFFF, then this is the active environment.  If it is 
not 0xFFFFFFFF, it is a pointer to the next environment so you would 
have to dereference it and repeat the process.

Since the "next" pointer is 0xFFFFFFFF in the active environment, and 
thus is still writable, you can find the end of the current 
environment, write the new (changed) environment at the end of the 
current environment, and then change the 0xFFFFFFFF to point to the new 
one.

typedef struct environment_s {
         env_t   next;                   /* Next env area if not 
0xFFFFFFFF      */
         ulong   crc;                    /* CRC32 over data 
bytes                */
         uchar   data[ENV_SIZE];
} env_t;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stuart Hughes | 2 Oct 2001 17:23
Picon

Re: [Ppcboot-users] putting the environment in the same sector

Hi Jerry,

That makes a lot of sense.  I guess I need to find some spare time to do
it :-)

Regards, Stuart

Jerry Van Baren wrote:
> 
> I have no experience but do have an idea to toss out...
> 
> Flash can be programmed at a bit-by-bit level from a '1' bit to a '0'
> bit, but a whole sector has to be erased to get the bits back to
> '1's.  If "we" (that's you, Stuart :-) enhanced the environment saving
> code somewhat, we could invalidate an old environment and append a new
> environment to where the old environment was, we could store a whole
> lot of changes before having to erase the sector and start over.
> 
> My thought is to have the environment storage start at a fixed place,
> as it is now, and have one additional variable in the environment
> structure: a "next environment" pointer.  If the "next environment"
> pointer is 0xFFFFFFFF, then this is the active environment.  If it is
> not 0xFFFFFFFF, it is a pointer to the next environment so you would
> have to dereference it and repeat the process.
> 
> Since the "next" pointer is 0xFFFFFFFF in the active environment, and
> thus is still writable, you can find the end of the current
> environment, write the new (changed) environment at the end of the
> current environment, and then change the 0xFFFFFFFF to point to the new
> one.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane