Hello,
I see in IEEE 1275 doc really nice commands for system debugging in the ``7.6 Client Program Debugging command group'' chapter. Unfortunately I'm not able to invoke randomly chosen from this list. Are they implemented or no? I'd especially welcome dis, registers display and breakpoints and stepping. Is it that much? :-)
Thanks,
Karel

Not in the Open Firmware currently. It has been suggested, but it is really only useful in the event of a total lack of serial port, JTAG, ethernet support in your debugging software, and other debugging options (i.e. legacy free consumer products). As long as you can fire something out somehow.

Pegasos has all of these, and Linux kernel debug and GDB are very happy to provide such functionality, which is a lot better than the one in the firmware docs, so there was little need to provide it in firmware - unless of course you have a dire need to debug the firmware with very simple applications!

Do you have a specific use for it? There are some Linux kernel patches from Ben Herrenschmidt which enable firewire debug in gdb for example; as far as I know it works perfectly on the Pegasos. At the end of the day most operating systems will let you output debug data, core dumps in a million different ways, far more than the firmware specification provides.

_________________
Matt Sealey

I'm just at the beginning of RTEMS port, so Linux tools will not help me and while I'm trying to get RTEMS serial configuration right neither serial debugging will help me, hence the question for simple firmware debugger.

Anyway, I'm curious are JTAG pins available on Efika somehow?

Thanks,
Karel

Nope, JTAG is only really useful for setting and catching breakpoints, coding brand new operating systems (you're porting), and on firmwares where they don't understand common executable formats :)

Once you get RTEMs up and running the software debuggers you have available will replace it quite simply. It isn't worth the cost, board space or hassle of conforming to some esoteric debugger you have (there are quite a few different kinds of 'JTAG' connectors, which one would you need? we can't make a board for each..) considering the other available features of the firmware.

Okay, so the firmware doesn't have the debugging functions, but that didn't stop the guys porting Linux, munOS or the NetBSD port (still going) did it? :)

The MPC5200B UART is well documented, and the firmware gives you both a ready-to-run-C-code environment, plus callbacks for most hardware discovery and PCI access (PLEASE use RTAS for PCI space access) why not just start by getting the kernel running (I am sure it supports a 603e and you can generate an ELF kernel) and write some simple UART code. At the end of the day the kernel debugging in most kernels is a 'printf' wrapper around a 'putc' command. You have a working serial port; the firmare has it set up for you, and it will tell you which PSC it's connected to in the device tree I think so you can get the base address fairly easily and go from there. Just poke away :)

_________________
Matt Sealey

JTAG is useful for a whole lot of other stuff ...

Debugging ISR is not that easy without it. Early debug, when nothing
is setup yet or when the memory map keeps changing
Or reset the board remotely. (Yes, I often work when I'm several
km away from the HW ...)

and it's _really_ annoying that the board doesn't have it.
The board space and different connectors is really an excuse,
You had the space to put a whole square of solder points ... and
there is a standard connector for this family of processor : The COP header found on the Lite5200 and Lite5200B.

Hi tnt, the EFIKA is a production card and not primarily targeted to a hardware development phase. We are already selling the card for $199 and fully expect to be at half that amount in six months. The alternatives you discussed are/were priced at multiples of that number.

As Matt explained, the firmware boots any ELF image, also raw binaries with a special header (just assembled code) over disk, network and so on. Our objective was that there would be no need to use JTAG once you have code running.

We may have something for JTAG users in the next production, but frankly there have only been a few requests (you, Grant, Kumar and Karel, who is a RTEMS fellow). If this creates too much of an annoyance for you, we can email you a shipping label for someone else. We will send you a future version with what you want later. Please let us know. Thanks.

R&B :)

_________________
http://bbrv.blogspot.com

Yeah but.. the firmware has set up 99.9% of what you need to start running user code anyway. This is the beauty of Open Firmware, here the entire system is brought up into a very well known and predictable state ready to boot a kernel.

If you were running on a system where you had no way of bootstrapping code, wiggling and using JTAG to start execution from a certain address works; this is how Sun expected they would start the Power OpenSolaris port. However considering they could just compile an ELF executable using their very own Open Firmware Client library.. what is the point of it? I personally think it slowed them down. We certainly don't get any better information from their JTAG debugging than we would from the firmware or OS serial output.
This really is an esoteric requirement!
Yep that's for the automotive guys to use the CAN bus though. There was a very good business case for adding that.

There's also a good design case not to make our board into the usual "bed of nails".
Yes, so it's only useful to the people who already have a 5200B development board or previously worked with Power Architecture (possibly even Freescale specifically) basically.

What if they are moving from ARM or MIPS or SH4 and all their cables for their current debugging solution don't fit the COP connector? Does that mean we got the connector wrong for these guys, or that THEY need to buy a new connector? What if they ask for one that meets their needs better?

And of course, once the board hits production on the back of a huge order from these JTAGers, will they complain if we have removed it, because they can't debug on a consumer-level board?

For something you will only truely need out of a bad embedded design habit, and even then only for a few days while you poke around and get a kernel to a good enough running state, it wasn't worth putting it on the board.

RTEMs already boots on a boatload of PowerPC processors from 400 series to the latest G4; with the stock code built as ELF you should be able to boot it from the Open Firmware just fine. It will need an OF entry point; this is pretty easy to code, and there is an example on the left hand side of the Power Developer homepage (or here for convenience, with BSD licensed code downloads.. there is also the Linux CHRP bootloader to look at.

This is a software problem, not a hardware problem. We solved 99% of anyone's need for a JTAG connector by providing a full-featured firmware. That is our view on it.

_________________
Matt Sealey

But JTAG (more precisely the COP protocol implemented over JTAG, not the boundary scan part) is useful for software development phase, at
least low-level software development phase. And don't tell me
you don't want people to devellop low level software on this
board, since a lot of those have been distributed for "OS related"
projects.
YES and it's really GREAT ! Frankly having this board on the market
is really cool especially in this price range.

That's exactly why I don't understand why you seem to insist on
preventing people from using it at it's full potential ?
A few example :
- no jtag (already covered in like ... the rest of this post)
- no I2C header (would be great to just plug in one of those
LCD display on I2C), even on PC you can find I2C headers on the
mother boards ...
- no gpio/spi/... Any expansion would be good. Looking at some
of the projects, especially the HW ones, I guess some people would find this useful. For example the very first project (actually an Example from Matt) : Kurobox competitor. It would certainly be useful to have some GPIO to blink some status leds.

Please don't misunderstand me, the board is great as it is for
users but why not make it even better and add a few bonuses.
Yes, once everything is running fine there is no need of JTAG ... but everything is not running fine yet and in the mean time people need
to do some work and devellopers tends to break stuff sometimes ...
Yes, people doing low level sw ... Now why do you want to prevent
those people to work efficiently in porting OS the Efika ...

And the "you don't need it" reason certainly doesn't convince me.
You don't *need* it on a iPaq, on a kurobox, on a settopbox, but
it's still there, without the header soldered but it's there.

"Board" space and cose isn't really convincing either. There are
plenty of spots on the PCB where you could have put it (you put in a square of soldering holes ...) and last time I added jtag to a board it may be took me 5 min in the schematic tool and 5 min to route it on PCB.

I think there may be another reason you don't want to tell.
Nice try ... but the annoyance is that is basically slows developers down so it takes longer to get things done (or even delay them indefinitly ...)

I ended up doing most of the actual developpment work on the Lite5200,
then just run the already tested driver on the Efika. Unfortunaly I have no other card with sound (lite5200b doesn't have ac97 codec) ...
But every one doesn't have those ... (well ... to be fair everyone
doesn't have a 2500$ hw JTAG debugger either ...)


Note: I don't really expect an answer as it's obviously going nowhere ...

Hello Neko,
that was just an question if it is JTAG available by a chance, no offence! :-) Well, I've been looking for some soldering points for JTAG, nothing more -- something you already did for CAN folks, which is really nice BTW.
Yes, I'm playing with SFW to get more and more from it. Currently I do have something which really loads and boots. The only issue is that I don't see any output since UART is misconfigured somewhere. But yes, this is just software issue which needs to be fixed. And I'm thinking about the way how to verify what's going wrong, if the mem map is wrong, if the UART config is wrong, if I use corrent UART, etc. -- hence my JTAG question.

Anyway, I enjoy the fun of PPC/Efika hacking. :-)

Thanks,
Karel

I will say that I do know you got a board under the premise of helping maintaining MPC5200B Linux support for the platform (as did Grant etc.)

If I am not very much mistaken, Linux does already boot, work pretty darn well on the MPC5200B and Efika, and so on.

Define 'low-level software' for me, I would love an example that doesn't include "porting some open source BIOS". Do you mean porting operating systems? That is considerably high level in my view. The Open Firmware interface is VERY well documented. We provided (via David's great article) documentation and examples, alongside the already very easily obtainable IEEE standards docs and recommended practises for the firmware.

How long does it take to port an OS to the Efika? Well, they got the OpenSolaris kernel booting in about a microsecond because of the firmware similarity with the Pegasos, and the fact that the MPC5200B is in a completely ready-to-use state.

There is very little "low-level" stuff to do. You don't need to touch any chip configuration or poke at the bus clocks, the firmware does it for you. The PSC's are set up where they are fixed function, for you. The RAM is done, the ethernet is ready, the disk controller turned on and detected some disks, lights are blinking and all manner of fun stuff.
Indeed and we don't see a problem. In thousands of sales of Pegasos, do you know how many of these developers, users, government contractors etc. and embedded systems vendors individually asked for a JTAG connector?

I can count them on one hand!

QNX have been working with us for a long while now. They NEVER asked for JTAG support. How come QNX can get along without it, but these developers can't?
You find SMBus headers, which is usually a seperate bus from the real I2C controller in the chip. In the Efika the I2C bus is connected to the RAM and the RTC/nvram PIC (iirc) - in our view letting people poke around on this bus is pretty dangerous. They can destroy the RAM, trash the code in the PIC, and end up with a non-booting board.

You can use I2S via the IrDA connector; put PSC6 into "Codec" mode et voila. I2S and I2C are for all intents and purposes the same thing (at least connecting one to the other is a matter of small amounts of thought and a little extra software).
The IrDA connector is PSC6 exposed; you can reconfigure it for 3 GPIO pins. You know the MPC5200B already, so this should be painfully obvious how to acheive.

We do admit we made a small error in judgement about the accessibility of GPIO pins; however you CAN reconfigure the PSC currently attached to the RS232 connector for GPIO (which also gives you a very nice, standard connector - actually a lot of robotics controllers do the same) and in a later revision of the board, we WILL have a seperate connector next to IrDA, with all the other PSC6-group pins exposed so you can have all 4 pins, and a clock source, and all that jazz as in the documentation.

Using any other GPIO pins would disable huge swathes of the board due to pin sharing on the SoC. Changing the behaviour of these would be rather dangerous, and considering the unpredictable nature of devices connected to either bus (imagine a disk on the ATA controller and a PCI card connected, while you reused the ATA/PCI pins for GPIO..).
They never needed it before. We aren't 'preventing' anyone from doing anything. There is always a way to do something that doesn't require JTAG.
I think we would do better to teach you all how to do software development without thousands of dollars of external/remote debugging tools, as I think it is a useful skill. We love the idea of 'native development' - compiling Power Architecture code on a Power Architecture development box. Using the Pegasos (RIP) for building Efika binaries. In fact the same kernel compiled for CHRP runs on Pegasos *AND* Efika. This is the beauty of the firmware.

Since Linux already works, you don't really have any problem with missing JTAG apart from your wont to travel and debug from hundreds of miles away. But GDB, a kernel debugger and a serial terminal wouldn't work for you? How would a JTAG debugger do better?
It really is simply not wanting the PCB to become a wirey mess of connectors people don't use. If you put in the JTAG connector and then someone wants a new feature for a large production, it's annoying to have to move it out of the way if it's already on the PCB. It's an extra part to consider when buying parts. It does cost money for people during manufacture to place these components on the board. Multiply the extra cent, the extra second, by a million units, and add in some engineer frustration having to move the JTAG connector to put another chip on the PCB :)
We have more Efika in the hands of Linux developers now, I think, than Lite5200B boards exist in the world - period.

I am fairly sure you can do all your work; perhaps not with your usual 'autopilot' you get with a well-trained and ingrained use of JTAG, without that hardware.

Considering those boards have gone to developers who simply do not have that hardware around ($2500 JTAG debugger and.. another PC to run that debugger on adds another few hundred dollars, plus the electricity... the hassle.. it mounts up :)

It would be so much easier if people found a nicer way. We think we did, it's called Firmware That Doesn't Suck.

_________________
Matt Sealey

Indeed, I agree with tnt that, just few soldering points to make the board more expandable would be great and even add value to the already great board. Well, just future "feature request" to Genesi. :-)
Thanks,
Karel

I don't want to get deep into an argument on this issue, but this is my position for the record:

JTAG is invaluable for more than just board bringup. I use it for device driver debug, it's a safety net if firmware ever gets trashed, and it is the easiest way to reset the board to a known good state (ie. w/ customer settings already in place).

I cannot speak for other developers, and who does or does not ask for JTAG. And while I'm disappointed that it is missing, I have no right to be upset about it. I can only speak for myself and my customers. I like the Efika, it is a nice little board. I really like the integrated harddrive mounts and the form factor. However, the lack of JTAG is a strike against it when making recommendations to customers, for all the reasons given in the above thread.

This post is not at all about the Linux support effort for the Efika; it is about whether or not I can recommend it to *my* customers. I fully accept that other people disagree. This is more a business decision; not a technical one.

In one project, I would like to hook up the MPC5200B to the Sony Unibus protocol so that the EFIKA board integrates with Sony car audio systems.

I also would like to use the IrDa header for PSC6 Codec mode (SPI), as SPI can be used for Unibus.

This is supposed to make 3 GPIO pins available as I understand from the posts above.

pin 1=Vcc
pin 2=?
pin 3=Rx
pin 4=GND
pin 5=Tx


What register bit is pin 2 attached to?

Also, I would need to know whether Slave Select (SS) is asserted (hardwired), as I would like to add SPI slave functionality.

Thanks,

Leon Woestenberg

I was quite disappointed by this myself also, but you can reset the board after a lockup and investigate with ldump.

Don't forget to disable the caches in HID0 because otherwise you will not see the "recent" data written to memory which is of course the most interesting.

This way I could walk up stack backtraces by hand and inspect global variables of the netbsd bootloader and kernel...

Aymeric

Disabling the caches is easily done like this (here scratching r1, which is not a good idea if you do it after setting up your stack):

It's PSC6 and is in the manual. Pin 2 is connected to the "CTS" line of the PSC6 while in UART mode. You can check this up in the MPC5200B manual in the relevant section; I think I noted out which part is which (this whole page came about because I researched the potential of PSC6 for GPIO for a customer, and the manual really has a broken index and very hard to read as a PDF.. I should order the paper version..)

http://www.powerdeveloper.org/efika.php

RTS isn't exposed on the pin header. Using SPI is not possible right now (clock is missing IIRC) unless you expose the pin from the point on the underside of the board; if you are desperate for this functionality we CAN tell you exactly where this is so you can solder a wire and a custom connector.

The next revision of the Efika board we are debating exposing the full PSC6 since we have had vastly more interest and as a unique, unshared PSC for GPIO and the codec functionality. It is a lot easier to expose than the others (which may destroy other features on the board if programmed to act any other way than we connected them up).

I need to check my notes and I will draw a full diagram of the PSC6 connections to the board and pin header, I did research this with Gerald in order to answer these questions but I wrote it down and put the paper in my pile of papers, my desk is a little nightmarish right now and the schematic looks like all the other schematics :D

_________________
Matt Sealey