A Model Code In The Firmware?

[A_SN]

Last year when messing around with that LCD colour correction daemon I made for MKIIs I contemplated an automated way to tell if the machine was a MKII or not. Someone found a way to find the batch number in some register but that was of little help. Ultimately as it turned out there was no way, and that was quite embarrassing.

So here's my question to the makers of the Pandora, will there be any way a program could determine simply and reliably enough the model of the Pandora? I think it might be quite useful as new models come out with different features and that a programmer might want to run different code depending on which model his program runs on.

 

[Sphinxter]

Could save a lot of hardware groping that.

 

[Trip]

I think it would be more useful for multi-player gaming on Pandora only servers. The server can check to make sure the games running on an actual Pandora machine before letting the player on.
This could help to keep the game fairer and make sure we don't get slapped about by PC players too much

 

[A_SN]

I think it would be more useful for multi-player gaming on Pandora only servers. The server can check to make sure the games running on an actual Pandora machine before letting the player on.
This could help to keep the game fairer and make sure we don't get slapped about by PC players too much

No no you really don't need that to do that. A simple #ifdef statement would suffice. Besides that's not the point of my idea at all.

 

[Trip]

I think it would be more useful for multi-player gaming on Pandora only servers. The server can check to make sure the games running on an actual Pandora machine before letting the player on.
This could help to keep the game fairer and make sure we don't get slapped about by PC players too much

No no you really don't need that to do that. A simple #ifdef statement would suffice. Besides that's not the point of my idea at all.

Fair enough, just an idea

 

[atomicthumbs]

There'll probably be a serial number access thingy somewhere in /proc

 

[WarmFluffyUK]

There'll probably be a serial number access thingy somewhere in /proc

A model number would be more useful than serial numbers.

 

[Firefox]

Perhaps we could have a cookie jar, like the later Ataris had?

There was a very simple API in the ROM code that allowed you to read "cookies" one by one. Each cookie told you something about the machine; what revision the ROM was, if the PCM sound chip was fitted, if the blitter was fitted, etc etc. It made it straightforward to work out what sort of machine your code was running on (and if there wasn't a cookie jar then that narrowed it down a lot, too).

 

[A_SN]

Perhaps we could have a cookie jar, like the later Ataris had?

There was a very simple API in the ROM code that allowed you to read "cookies" one by one. Each cookie told you something about the machine; what revision the ROM was, if the PCM sound chip was fitted, if the blitter was fitted, etc etc. It made it straightforward to work out what sort of machine your code was running on (and if there wasn't a cookie jar then that narrowed it down a lot, too).

Sounds great! I imagine such a thing would be great also for modded machines, like for examples if you had secondary shoulder buttons the "cookie jar" could reveal it and thus a program could automatically make use of them. Same for pretty much any feature.

I think a space in physical memory with a bunch of well documented words at specific addresses would do the trick.

 

[sindbad]

This is the type of thing the /proc filesystem is made for and it can be used without any special api, as all information is in files.

 

[basicmark]

/proc/cpuinfo has a machine description field which can be used to work out that's a Pandora.

/sys gives you lots of information about the various peripherals that are on the device.

 

[A_SN]

/proc/cpuinfo has a machine description field which can be used to work out that's a Pandora.

/sys gives you lots of information about the various peripherals that are on the device.

We don't care that the machine is a Pandora, of course it's a Pandora, everybody's gonna use something like -DPANDORA when compiling

As for the rest I'm not sure /sys would tell you whether you if you have secondary shoulder buttons or not. That's why I ask if the makers of this had any plans to do anything about it because clearly it won't autounixmagically happen on its own.

 

[sindbad]

Sure it will. You will be able to read info on the key controller and all keys attached to it.

 

[Nilsiboy]

I don't really see the point of this, honestly... IF there's going to be another Pandora "Model", it's not going to happen for a few years probably... and if it does, a lot of things will probably be different enough to tell by just that...

I do like the idea of detecting secondary shoulder buttons, though

 

[Squidge]

If your going to put a model code in, you shouldn't really put it in the firmware, as the firmware will likely work across multiple revisions of hardware. It would be daft to create different versions of firmware with different model codes in each and tell people to download the correct one when a single version will cover all.

Since some hardware can't be probed (eg. secondary shoulder buttons), I would propose that a resistor be placed across a analog input pin (if the OMAP has any, not sure). The resistor value could be checked on startup to be within a certain window to determine the hardware revision. The other solution would be to reserve some GPIOs which are pulled to VCC on revision 1 and you use them as a binary counter.

I do however think it's a moot point now however, as the boards are pretty much finalised apart from mistakes found (if any) on the MK0 by developers.

 

[A_SN]

I don't really see the point of this, honestly... IF there's going to be another Pandora "Model", it's not going to happen for a few years probably... and if it does, a lot of things will probably be different enough to tell by just that...

Wow, where do I start. You realise the idiocy of your comment, don't you? First of all the "other Pandora" model will be the first commercially available model since there's already a model out there. Secondly it might be something as simple as a different LCD because the first one isn't available or say a nub with a click, or whatever, it can be a minor change that you may want to know about from a program. Besides that's an incredible lack of foresight to go "oh well who cares, that won't happen before a long time anyways".

If your going to put a model code in, you shouldn't really put it in the firmware, as the firmware will likely work across multiple revisions of hardware. It would be daft to create different versions of firmware with different model codes in each and tell people to download the correct one when a single version will cover all.

Whatever you got my point, I don't know or care how it's implemented, I'm just saying it should be there, I don't care if some ROM or firmware takes care of this.

QUOTE

I do however think it's a moot point now however, as the boards are pretty much finalised apart from mistakes found (if any) on the MK0 by developers.


How's that a moot point?? It's not like the Pandora's hardware won't receive any sort of hardware change throughout its life, nor like because the first batch won't have such a model code thing that the other ones shouldn't either. And like I said it's not just about the optional shoulder buttons, it can be about knowing if the keyboard is different, of the LCD, or the speakers, or some internal chip or whatever. It might be useful, later, in the future.

 

[Squidge]

Yes, I agree, if the board is changed later that will impact applications or the kernel (ie, more shoulder buttons, etc) the there should be a way of checking the revision of the board.

I wonder if the BT/Wifi module has any kind of storage? Maybe a hardware rev# could be stored there if so.

 

[Nilsiboy]

I don't really see the point of this, honestly... IF there's going to be another Pandora "Model", it's not going to happen for a few years probably... and if it does, a lot of things will probably be different enough to tell by just that...

Wow, where do I start. You realise the idiocy of your comment, don't you? First of all the "other Pandora" model will be the first commercially available model since there's already a model out there. Secondly it might be something as simple as a different LCD because the first one isn't available or say a nub with a click, or whatever, it can be a minor change that you may want to know about from a program. Besides that's an incredible lack of foresight to go "oh well who cares, that won't happen before a long time anyways".


Okay, first off, obviously I did not realize the "idiocy" of my comment, otherwise I wouldn't have commented. I might, however, have written it in a way that didn't conveye my idea well enough.
What I was trying to say, basically, was that another Pandora "Model" would probably be as different from the current Pandora as that is from the GP2X, so the same programs couldn't be run without ANY adjustments anyway.

But I have to admit didn't think of the things you mentioned, like a different LCD. I remember that the different LCD on the GP32 BLU+ caused quite a bit of trouble, so yes, a model number thingie would be useful.

OTOH, as was said before, it would just make things a bit easier, since the OS should be able to provide you with in-depth information on the hardware, so if you knew there was a model with a different LCD/WiFi chip/keyboard/etc. then you could just leverage that information...

Disclaimer: As you can infer from my heavy use of the subjunctive clause, I am not sure about much of this at all. I also don't want to start a flame war.

 

[A_SN]

Okay, first off, obviously I did not realize the "idiocy" of my comment, otherwise I wouldn't have commented. I might, however, have written it in a way that didn't conveye my idea well enough.
What I was trying to say, basically, was that another Pandora "Model" would probably be as different from the current Pandora as that is from the GP2X, so the same programs couldn't be run without ANY adjustments anyway.

But I have to admit didn't think of the things you mentioned, like a different LCD. I remember that the different LCD on the GP32 BLU+ caused quite a bit of trouble, so yes, a model number thingie would be useful.

OTOH, as was said before, it would just make things a bit easier, since the OS should be able to provide you with in-depth information on the hardware, so if you knew there was a model with a different LCD/WiFi chip/keyboard/etc. then you could just leverage that information...

Well yeah basically you assumed that there would be no new batch of the Pandora before the Pandora II in 4-6 years. Which seems quite impossible.

And the OS won't provide you with the needed information if the makers of the Pandora don't do something about it. The GP2X ran Linux and didn't tell you a damn thing that allowed you to tell which model of LCD you had. So yeah basically my suggestion is necessary. I accept your apology .

 

[Vimacs]

if i remember right the omap has quite a few unused io lines, maybe they could just pull some low/high to encode the revision with that.

edit: oops, missed squidges comment, so forget that.