Pandora Devkit Version Of The Official Pandora


esden

Still Fresh
Joined
Jul 3, 2005
Messages
11
Age
44
Location
Germany
Website
www.esden.net
Hi!

I am following the development of Pandora for quite some time now. Pandora seems to be on the brink of a release.

I am willing to port some real lowlevel stuff I am writing to Pandora and was asking myself if one will be able to access the JTAG interface, bootloader and so on.

I searched the forum for JTAG and the only answer I found for now was "What do you need it for! Unless you want to do some lowlevel kernel stuff..." as also the posts were several months old so they may be outdated anyways. Well I need it. And yes I want to do some real lowlevel kernel stuff. :)

So here are the questions, listed for easier reply :)

1) Is the JTAG interface easily accessable?
2) Will there be a special version of the Pandora packaging for developers who need such features? Just like it is the case with Freerunner?
3) Will this version be avilable through the preorder, or should I wait for a later release of a "lowlevel developer" version?

Cheers Esden

P.S. Sorry if the question was already asked and answered, and I am simply too stupid to use the search button. ^^
 
1) Last I heard, its pads on the board, so you'll have to disassemble the device and solder an appropriate connector (Pointless putting a connector on for the < 1% of users that want it, its just a waste of money).

I doubt 2) and 3) will ever happen. It would be an administrative nightmare for the number of products sold.

If you just want to upload code (not debug), you don't need JTAG - you can do that using an SD card. For kernel stuff, thats normally easier.
 
@Squidge

1) Ok, nice to know. So in my case I will have to mod the case so that I get better access to the JTAG. No problem at all... ;)

2), 3) I do not know if that would be really such a administrative nightmare... the Freerunner guys did it. But well perhaps it was a nightmare for them. ^^

@pbrook Don't worry I am aware of the beagleboard. But this thing does not have a case and an integrated keyboard and a display for hacking on the go. "That happens to me sometimes." (&copy; Gir from Invader Zim) And I wanted an ARM devel platform that consists of few loose parts and not tons of more or less big parts, that break easily while transporting from one place to another. Plus Pandora has power and everything I will need in the future for my project. But who knows some day I may also get a beagleboard. ;)

Cheers Esden
 
Consider this:

Craig makes 3,000 Pandora's, of which 500 are developer Pandora's. The first 2,500 go flying off the shelves, and there are several hundred other orders waiting. Should he force them to wait for more stock, or send them the more expensive ones? Assuming he uses the more expensive ones to clear up the backlog, what happens then when someone orders a developer unit? How many replacements should he order?

Having one type of product makes the entire thing much easier.

I think the best they could do is have a developer unit made on demand, and a charge of £25 or so for the parts and manual work involved. Alternatively, a developer could download a PDF describing the technique and required parts (which you would then obtain yourself).
 
Squidge said:
I think the best they could do is have a developer unit made on demand, and a charge of £25 or so for the parts and manual work involved. Alternatively, a developer could download a PDF describing the technique and required parts (which you would then obtain yourself).
Yeah, that's what I pictured - somebody would become an official (or unofficially official) dev modder. If you order a dev version, it'd be shipped directly to that person (assuming it wasn't the reseller doing it themselves), who'd affix the extra mods required, for an extra fee.
 
Last edited by a moderator:
to be honest however, do you know of any cheap Cortex-A8 JTAG devices? That may be more important first. Last time I looked, none of the "usual" jtag'ers supported the A8.
 
Squidge said:
to be honest however, do you know of any cheap Cortex-A8 JTAG devices? That may be more important first. Last time I looked, none of the "usual" jtag'ers supported the A8.

There's been some progress in the past few weeks: http://elinux.org/index.php?title=BeagleBo...p;printable=yes
I don't know it that means it's in any way usable now as I have never done any JTAG debugging :)
 
Last edited by a moderator:
Well I did not expect the guys to create two different versions of Pandora from the hardware side. I was thinking at the beginning that they will make the JTAG interface easily accessible from the beginning. If that would be the case then a version for developers would differ from the consumer one only through additional things in the package, like an adapter from the pandora JTAG connector to a standard one or something. But as it is not this way I can perfectly understand that there is no such differentiation.

Well I have to admit that I did not have a look at JTAG adapters for the Cortex A8. I was expecting that it will be already integrated in OpenOCD due to the Beagleboard effort. Reading the page you posted Laurent it does not look so bad. It seems that the basics are working already. Reading the Beagleboard mailinglist only confirms that.

I hope that in time there will be a useful support of the Cortex A8 in OpenOCD so I can use the AmontecKey I already possess.

Cheers Esden
 
I think the reason why the JTAG port was not made more accessible is that throughout the Pandora development life, there was only a couple of A8 compatible JTAG'ers around, and they were all around the $3000 mark. No one was going to spend that kind of money to "play".
 
Still, it would be nice to buy at least the expansion connector (or two) together with Pandora. Guitar pick is not needed :)
 
Squidge said:
I think the reason why the JTAG port was not made more accessible is that throughout the Pandora development life, there was only a couple of A8 compatible JTAG'ers around, and they were all around the $3000 mark. No one was going to spend that kind of money to "play".

Mumm if Jtag is used only to restore the Bootloader, you can use Jtag interface with only some resistor ... connected on // port !!!

regards
 
Last edited by a moderator:
Souldream said:
Mumm if Jtag is used only to restore the Bootloader, you can use Jtag interface with only some resistor ... connected on // port !!!
What?

Secondly, JTAG isn't required to restore the bootloader. You can do that with an SD Card. As I've already stated above.
 
Last edited by a moderator:
Squidge said:
Souldream said:
Mumm if Jtag is used only to restore the Bootloader, you can use Jtag interface with only some resistor ... connected on // port !!!
What?

Secondly, JTAG isn't required to restore the bootloader. You can do that with an SD Card. As I've already stated above.


So we are clear -> there is no way to brick the box by erasing the bootloader ? and if no erasing ? no upgrade of Bootloader ...

Does it mean there is like 2 boot loader ? = Early stage and second stage loader ?

regards
 
Last edited by a moderator:
Souldream said:
So we are clear -> there is no way to brick the box by erasing the bootloader ? and if no erasing ? no upgrade of Bootloader ...
Yes, it's in ROM. But it so minimal that you will never need to upgrade it, main (only?) thing it does is loading next bootloader from flash, SD, USB or serial (I think?).

Souldream said:
Does it mean there is like 2 boot loader ? = Early stage and second stage loader ?
Actually right now there are 3 of them. First one in ROM, second basic one is < 64kB in size to fit into internal SRAM, and the final one is big full-featured one.
 
Last edited by a moderator:
Souldream said:
So we are clear -> there is no way to brick the box by erasing the bootloader ? and if no erasing ? no upgrade of Bootloader ...
Does it mean there is like 2 boot loader ? = Early stage and second stage loader ?
Sure, because bootloader is in ROM and it is not upgradeable. Bootloader load OS from NAND or from SD [or USB - I'm not sure here]. So even if NAND will be scratched, you still can boot from SD card = unbrickable.
 
Last edited by a moderator:
Yes, the OMAP3 has a built-in bit of code called x-loader. That bootstraps uboot which bootstraps the kernel which bootstraps itself. Now if something goes wrong when re-flashing x-loader, then you're stuffed. So I guess the answer is, don't update x-loader. :)

I believe currently the beagleboard OE system builds x-loader for you and the wiki tells you to flash it every time. IMO this is pretty dangerous. Personally, even on OMAP3, I only update uboot if I _really_ have to and I never update x-loader.
 
Tom Cooksey said:
Yes, the OMAP3 has a built-in bit of code called x-loader. That bootstraps uboot which bootstraps the kernel which bootstraps itself. Now if something goes wrong when re-flashing x-loader, then you're stuffed. So I guess the answer is, don't update x-loader. :)

I believe currently the beagleboard OE system builds x-loader for you and the wiki tells you to flash it every time. IMO this is pretty dangerous. Personally, even on OMAP3, I only update uboot if I _really_ have to and I never update x-loader.
x-loader is stored in flash, not the OMAP, and can be updated quite easily without bricking the system. Also, it's optional on some bootloaders which configure all the memory/etc themselves. If something goes wrong when re-flashing x-loader, you can use the builtin bootloader to reflash x-loader/uboot via SDCard or other means (uart, USB, etc).

The Pandora boot sequence is therefore Internal bootloader -> x-loader -> uboot -> kernel
 
Last edited by a moderator:
Squidge said:
x-loader is stored in flash, not the OMAP, and can be updated quite easily without bricking the system. Also, it's optional on some bootloaders which configure all the memory/etc themselves. If something goes wrong when re-flashing x-loader, you can use the builtin bootloader to reflash x-loader/uboot via SDCard or other means (uart, USB, etc).

The Pandora boot sequence is therefore Internal bootloader -> x-loader -> uboot -> kernel
Wow. Thanks for clearing that up! So x-loader is not the internal bootloader at all, but something else entirely? Is there any way to accidently wipe the internal bootloader?

What's the purpose of x-loader? Surely uboot doesn't have very high requirements? I don't know about the OMAP3, but I seem to remember the Freescale i.MX31 configures the L2 cache on reset so that it never gets flushed to memory (write-back mode?). uboot then executes directly from flash (which I think is set up by a tiny internel bootloader in the SoC) and uses the L2 cache for it's stack. uboot is then the one which configures the SDRAM controller and brings up the rest of system memory so it can load the kernel. (This may be wrong as my memory is a bit hasy).

Are you saying it is x-loader which configures the SDRAM controller on the OMAP3, not uboot?
 
Last edited by a moderator:
It's not possible to accidentally, or even to forcefully wipe the internal bootloader. It is strictly read-only.

The purpose of x-loader is that uboot is too big, so it needs a smaller bootloader to load it into memory. You could write your own bootloader than booted linux instead of loading uboot, but that would restrict your options quite a bit, so it's much easier (and the standard) to just launch uboot and that take care of everything.

x-loader does indeed configure the ram, and then loads uboot from flash into ram and runs it.
 
Back
Top