ªL§Ó³Ó | 1 Oct 16:50 2000
Picon

[Ppcboot-users] How to decide MAC address ?

Hi everyone:
    I put ppcboot-0.4.4-pre1 on my MPC823 board.
It can run on my board. I can download hello.srec via loads command.
But it is too slow .I want download application(Linux) via net command.
But I find my MAC address is 00:00:00:00:00:00. It's right ? I doubt.
    I am not sure the whole procedure about BOOT/TFTP downloading app.
Can tell me how? Thank you very much !!!
 
Ken
Wolfgang Denk | 1 Oct 18:33 2000
Picon
Picon

Re: [Ppcboot-users] How to decide MAC address ?

Hi Ken,

in message <002c01c02bb6$eeb0cba0$8267608c <at> assassin> you wrote:
> 
> Hi everyone:
>     I put ppcboot-0.4.4-pre1 on my MPC823 board.

Great - did you need to modify anything? If yes, I'd appreciate  your
comments...

> It can run on my board. I can download hello.srec via loads command.
> But it is too slow .I want download application(Linux) via net command.
> But I find my MAC address is 00:00:00:00:00:00. It's right ? I doubt.

This is just an indication that  you  missed  to  set  the  "ethaddr"
variable  in  your  environment. This variable MUST be set before you
can use the network services.

>     I am not sure the whole procedure about BOOT/TFTP downloading app.
> Can tell me how? Thank you very much !!!

Umm... Just type "bootp 100000 image" followed by "bootm 100000".

Please note that I'm in the process of preparing an  updated  version
of PPCBoot (mostly changes to the network code, as well as adding the
IBM  40x  code  to the CVS version). I want to have this ready within
the week.

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
Dealing with failure is easy: work hard to improve. Success  is  also
easy  to  handle:  you've  solved  the  wrong  problem.  Work hard to
improve.
Wolfgang Denk | 1 Oct 18:33 2000
Picon
Picon

Re: [Ppcboot-users] How to decide MAC address ?

Hi Ken,

in message <002c01c02bb6$eeb0cba0$8267608c <at> assassin> you wrote:
> 
> Hi everyone:
>     I put ppcboot-0.4.4-pre1 on my MPC823 board.

Great - did you need to modify anything? If yes, I'd appreciate  your
comments...

> It can run on my board. I can download hello.srec via loads command.
> But it is too slow .I want download application(Linux) via net command.
> But I find my MAC address is 00:00:00:00:00:00. It's right ? I doubt.

This is just an indication that  you  missed  to  set  the  "ethaddr"
variable  in  your  environment. This variable MUST be set before you
can use the network services.

>     I am not sure the whole procedure about BOOT/TFTP downloading app.
> Can tell me how? Thank you very much !!!

Umm... Just type "bootp 100000 image" followed by "bootm 100000".

Please note that I'm in the process of preparing an  updated  version
of PPCBoot (mostly changes to the network code, as well as adding the
IBM  40x  code  to the CVS version). I want to have this ready within
the week.

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
Dealing with failure is easy: work hard to improve. Success  is  also
easy  to  handle:  you've  solved  the  wrong  problem.  Work hard to
improve.
Wolfgang Denk | 2 Oct 01:52 2000
Picon
Picon

PPCBoot-0.5.0 released

Hi Everybody,

I'm back from vacation, and try to integrated all the new stuff  that
several people sent me into PPCBoot.

There are two new versions of PPCBoot on the CVS  server,  tagged  as
PPCBOOT_0_4_4  and  PPCBOOT_0_5_0.  Also, corresponding tarballs have
beep put on our FTP server, see
	ftp://ftp.denx.de/pub/ppcboot/ppcboot-0.4.4.tar.gz
resp.
	ftp://ftp.denx.de/pub/ppcboot/ppcboot-0.5.0.tar.gz

Feature summary:

- version 0.4.4 has improved network code which provides BOOTP, RARP
  and plain TFTP support.

- version 0.5.0 has support for IBM PPC401/403/405GP CPUs
  (contributed by Stefan Roese)

From the CHANGELOG:

======================================================================
Modifications for 0.5.0:
======================================================================

* Added code for IBM PPC401/403/405GP (contributed by Stefan Roese)

======================================================================
Modifications for 0.4.4:
======================================================================

* Added Network support; allows:

  - Network Interface configuration using environment variables or
    RARP or BOOTP
  - image download and booting over Ethernet using TFTP
  - automatic booting over ethernet when "autostart=yes" and
    downloaded image is bootable

* Some code cleanup to make easier adaptable to different hardware

* Bug fixes, especially:

  - avoid clobbering the PLL divider in interrupts.c (thanks to Till
    Straumann)
  - make Ethernet code work on SCC1 or SCC2

======================================================================
Modifications for 0.4.4-pre2:
======================================================================

* Added Serial Download Echo Mode to allow switching off echo while
  serial download; configurable with "loads_echo" environment
  variable.

* Added CFG_LOADS_BAUD_CHANGE option to allow temporary baudrate
  change while serial download.

======================================================================
Modifications for 0.4.4-pre1:
======================================================================

* Cleanup: included needed header files instead of relying on the
  compiler to be a (cross-) compiler configured for a Linux system.

* Added test-version of networking code (file download using BOOTP /
  TFTP); tested on TQM823L, TQM850L and TQM860L. No error / timeout
  handling yet.

* Bugfix: The command table was not completely relocated, so when you
  erased the flash sectors containing PPCBoot (for instance to
  overwrite it with a new version) you couldn't execute any commands
  any more.

There are some more patches / modifications in my  queue  (especially
the  huge  (220k!)  patch  contributed  by Murray Jensen) - please be
patient with me that this will take some more time...

As always: comments and feedback welcome.

Happy hacking,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.
Wolfgang Denk | 2 Oct 01:52 2000
Picon
Picon

[Ppcboot-users] PPCBoot-0.5.0 released

Hi Everybody,

I'm back from vacation, and try to integrated all the new stuff  that
several people sent me into PPCBoot.

There are two new versions of PPCBoot on the CVS  server,  tagged  as
PPCBOOT_0_4_4  and  PPCBOOT_0_5_0.  Also, corresponding tarballs have
beep put on our FTP server, see
	ftp://ftp.denx.de/pub/ppcboot/ppcboot-0.4.4.tar.gz
resp.
	ftp://ftp.denx.de/pub/ppcboot/ppcboot-0.5.0.tar.gz

Feature summary:

- version 0.4.4 has improved network code which provides BOOTP, RARP
  and plain TFTP support.

- version 0.5.0 has support for IBM PPC401/403/405GP CPUs
  (contributed by Stefan Roese)

>From the CHANGELOG:

======================================================================
Modifications for 0.5.0:
======================================================================

* Added code for IBM PPC401/403/405GP (contributed by Stefan Roese)

======================================================================
Modifications for 0.4.4:
======================================================================

* Added Network support; allows:

  - Network Interface configuration using environment variables or
    RARP or BOOTP
  - image download and booting over Ethernet using TFTP
  - automatic booting over ethernet when "autostart=yes" and
    downloaded image is bootable

* Some code cleanup to make easier adaptable to different hardware

* Bug fixes, especially:

  - avoid clobbering the PLL divider in interrupts.c (thanks to Till
    Straumann)
  - make Ethernet code work on SCC1 or SCC2

======================================================================
Modifications for 0.4.4-pre2:
======================================================================

* Added Serial Download Echo Mode to allow switching off echo while
  serial download; configurable with "loads_echo" environment
  variable.

* Added CFG_LOADS_BAUD_CHANGE option to allow temporary baudrate
  change while serial download.

======================================================================
Modifications for 0.4.4-pre1:
======================================================================

* Cleanup: included needed header files instead of relying on the
  compiler to be a (cross-) compiler configured for a Linux system.

* Added test-version of networking code (file download using BOOTP /
  TFTP); tested on TQM823L, TQM850L and TQM860L. No error / timeout
  handling yet.

* Bugfix: The command table was not completely relocated, so when you
  erased the flash sectors containing PPCBoot (for instance to
  overwrite it with a new version) you couldn't execute any commands
  any more.

There are some more patches / modifications in my  queue  (especially
the  huge  (220k!)  patch  contributed  by Murray Jensen) - please be
patient with me that this will take some more time...

As always: comments and feedback welcome.

Happy hacking,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
A meeting is an event at which the minutes are kept and the hours are
lost.
Murray Jensen | 2 Oct 07:33 2000
Picon
Picon

Re: [Ppcboot-users] adding to board.c

On Thu, 28 Sep 2000 10:29:54 +0100, "Rob Taylor" <robt <at> flyingpig.com> writes:
>I've been thinking on this. I think that what you're suggesting would be rather
>an overkill.

I suspected as much - but I'm still not certain it is.

>(our linker scripts are messy enough already ;)

I didn't think the linker scripts were messy. Aren't they very simple?
The objection I thought that would be raised is that the linker scripts
shouldn't be deciding the order of execution of code - this should be
in the domain of the program source code.

I thought of another way. Have something similar to the Linux/PPC struct
machdep_calls ppc_md. i.e. define a list of possible platform dependent
function calls which get called at various stages by the common board_init_f
and board_init_r routines. Thus this:

    if ((dram_size = initdram (board_type)) > 0) {...

changes to this:

    if ((dram_size = (*ppc_md.initdram) (board_type)) > 0) {...

The first thing the monitor does is call a platform dependent function to
initialise this structure, or it could be statically defined as initialised
data.

Optional calls would look like this:

    if (ppc_md.preserial != NULL)
	(*ppc_md.preserial)();

and on your platform, the preserial function would initialise the winbond
thingy. All other boards would leave this NULL.

>Perhaps a better solution would be to have
>board_init_f, board_init_r in the per-board directories, but take out code
>that's common to all boards and have these as functions that the boards
>initialisation code calls in it's own board_init_f.

This is a good idea also, and I actually did this in the early days, but I
found that there was a lot of duplicated code in each of the board dependent
directories, plus it was a pretty major change to the current source code.

>P.S.
>
>while I'm here, I was just thinking that perhaps placing cpu directories under
> a
>'cpus' directory and the board directories under a 'boards' directory would be
> a
>helpful organisational tool. whaddya reckon?

This is also a good idea. Perhaps the following:

	arch/
		ppc/
			boards/
			cpus/
			common/		<= same as current top level "ppc" dir

then you could have:

	arch/
		alpha/
			boards/
			cpus/
			common/

etc. again, taking the lead from the linux kernel. Or you could just have:

	arch/
		ppc/
			cogent/
			common/		<= same as current top level "ppc" dir
			etx094/
			fads/
			mpc8xx/
			mpc8260/
			tqm8xx/

because the extra directory level would be perhaps going too far.

Let's keep the discussion rolling - this is all good stuff. Cheers!
								Murray...
--

-- 
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen <at> cmst.csiro.au  (old address was mjj <at> mlb.dmt.csiro.au)
Uwe.Girlich | 2 Oct 11:44 2000
Picon

[Ppcboot-users] debugging after relocation

I'm currently porting PPCboot to a custom board made by Speech
Design and need to debug my code. I do this remote with the
ABATRON BDI2000.

After relocate_code() (more exactly after in_ram), all symbols are
wrong because the .text segment starts at the EPROM start. So I print
now out the new base address before relocate_code()

printf("addr_moni=0x%08x\n", addr_moni);

and do a relink with the ELF file:

powerpc-linux-ld -Ttext <new base address> ppcboot -o ppcboot.rel

This works fine and I can now find out, where my code is hanging
but I don't get the full debug information (code line/address-table)
because the .stab section won't be affected by my linker command
and continues to point into the EPROM.

Is there a special parameter for ld to correct this behaviour?
Should I link the whole stuff again with the new base address so I
get also the code line information directly from the compiler?
This should work but may bring in other problems.
Is there a simpler way to debug with symbols after relocation?

Thanks a lot,
Uwe Girlich
Wolfgang Denk | 2 Oct 12:52 2000
Picon
Picon

Re: [Ppcboot-users] debugging after relocation

In message <39D842D90000010E <at> mail.epost.de> you wrote:
> I'm currently porting PPCboot to a custom board made by Speech
> Design and need to debug my code. I do this remote with the
> ABATRON BDI2000.

Same as me...

> After relocate_code() (more exactly after in_ram), all symbols are
> wrong because the .text segment starts at the EPROM start. So I print
> now out the new base address before relocate_code()
...
> and do a relink with the ELF file:
...
> This works fine and I can now find out, where my code is hanging
> but I don't get the full debug information (code line/address-table)
> because the .stab section won't be affected by my linker command
> and continues to point into the EPROM.

I'm using a much simpler approach:

* If I'm debugging parts of PPCBoot that run _before_  relocation,  I
  just call "powerpc-linux-gdb ppcboot" as usual.

*  For  parts  of  PPCBoot  that  run  _after_  relocation,  I   call
  "powerpc-linux-gdb"  _without_  arguments, and source the following
  definitions:

	# "pitti" is the hostname of my BDI2000 box
	target remote pitti:2001
	#add-sym ppcboot 0x7c0000
	#add-sym ppcboot 0x7e0000
	#add-sym ppcboot 0xfc0000
	add-sym ppcboot 0xfe0000
	display/i $pc

	#Macro for reset
	define reset
	  detach
	  target remote pitti:2001
	end

Then you can set breakpoints and debug as usual...

The only disadvantage of this solution is that you need  to  know  in
advance how much memory you have, and how much memory is reserved for
PPCBoot.

Hope this helps,

Wolfgang Denk

--

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd <at> denx.de
When you say "I wrote a program that crashed  Windows",  people  just
stare  at you blankly and say "Hey, I got those with the system, *for
free*".        - Linus Torvalds in <3itc77$9lj <at> ninurta.fer.uni-lj.si>
Rob Taylor | 2 Oct 13:43 2000

[Ppcboot-users] pci devices

Righty.. I'm up to the point of writing an eepro 100 driver for my
Sandpoint-8240 system. What I'm wondering is if anyone has any thoughts on a PCI
layer in ppcboot. I'm thinking maybe of ripping out linux's PCI functionality
and sticking it in ppcboot, making porting drivers from linux a wee bit easier.

Any thoughts?

Rob Taylor
Flying Pig Systems
Rob Taylor | 2 Oct 13:47 2000

[Ppcboot-users] RE: pci devices


> Righty.. I'm up to the point of writing an eepro 100 driver for my
> Sandpoint-8240 system. What I'm wondering is if anyone has any
> thoughts on a PCI layer in ppcboot. I'm thinking maybe of ripping out
> linux's PCI functionality and sticking it in ppcboot, making porting
> drivers from linux a wee bit easier.

I just wanted to add that I'm worrying that this would take adding too much
cruft from the kernel, you'd at least need to dummy up some of the resource
allocation stuff.

Rob Taylor
Flying Pig Systems

Gmane