Re: [Ppcboot-users] PPCBOOT activities

[Murray J. <Mur...@cm...>]

On Wed, 05 Jul 2000 11:17:36 +0200, Wolfgang Denk <wd...@de...> writes:
>> S-records is "just another protocol". You can load data into memory using
>
>Right. I just happened to have existing code I reused :-)

Fair enough - the GDB stubs code is also existing code and readily
available (I believe).

>> Why not? One doesn't really need the tftp/udp/ip overhead, especially if
>
>I have customers asking for BOOTP, so we HAVE to do that anyway.  And
>once you have TFTP and BOOTP available, there is little justification
>for another, proprietary protocol.

Again fair enough - but you might have a light-weight host with a very slow
cpu (e.g. palm pilot or something similar) where removing the TFTP/UDP/IP
protocol overhead might be a big win. I threw that one in just as food for
thought really.

>> I have actually done this part (at least sort of) and can send you some samp
>le
>> code to illustrate what I mean, if you like.
>
>I do - a bit later, please. I'll come back on you about this.

OK, let me know. I might start hacking it in soon on my own anyway. We'll
see what happens.

>> And yet again, abstracted so that there is a generic "nvram" type device
>> that can be implemented however the board support code deems fit. For exampl
>e,
...flash...
>I am thinking about this, but it will be chip (and thus board) depen-
>dend
...rtc...
>Board dependend, again.
...dip switches...
>Or Board Configuration Registers like on  the  MBX  or  FADS  boards:
>board dependend.

The main point I was making is that you could consider all these to be
of generic type "nvram". i.e. an area with a few bytes of non-volatile
memory where configuration data can be read from (and stored if it is
writable). Of course all these things are board dependent, but they are
not visible to the generic upper level monitor code - the code that
implements the "nvram" device will be a small "driver" in the "board
support package".

This abstraction should be done for everything that might ever be handled
by the monitor - including the CPU, RAM, clocks. Plus they all should be
effectively "pluggable" or "modular". Not dissimilar to the way Linux has
drivers as "loadable modules", except the monitor would be configured at
compile time.

Actually... why not have loadable "modules" in the monitor??? You could have
a bunch of different modules in flash and load them as required. He he - I
know. For the (far distant) future.

>> Why not? It is *really* simple to implement HTTP over whatever transport
>> mechanism (see above). The standard set of console commands could either
>
>I know. It just happens to be not top of the list of the prioritiues,
>which are largely influenced by some of my customers who pay some  of
>the effort going into this project.

But I think its neat and I might have some time on my hands :-) The main
point I keep making though is to abstract things so that a HTTP based
console could be substituted for a serial command line console with little
or no effort (other than the writing of the new console of course).

Again, all devices and services should be abstracted in this fashion. 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: Mur...@cm...  (old address was mj...@ml...)