Benchmarks

Why won’t it work (I haven’t tried it yet but perhaps M2 is already unity and can’t be reduced?)?

For starters, the memory addresses you’re trying to access are physical addresses. They need mapping in before you can get at them. Use OS_Memory 13 to do that. If you want to do this in BASIC, you’ll also need to set the access privileges to give you write access in USR mode.

And if you’re adventurous like Chris G. then I’m sure you’ll be able to work out how to alter the code to allow running at 1GHz+.

I haven’t had any stability problems running at 1GHz so far. Started getting filecore in use errors at 1.2GHz.

I noticed on the box it says BB-XM-00 which according to the manual means it has 200MHz memory. Don’t know how to tell for sure.

Interrupt the start up on the serial port and try the command ‘nand erase’ – if it has (unsupported) nand memory it is the XM A2-01 (Numonix 166MHz memory). Otherwise it is the A2-02 (200MHz memory, no nand) I think.

New opp.bas program here. Should work OK on both xM’s and non-xM’s.

Why won’t it work (I haven’t tried it yet but perhaps M2 is already unity and can’t be reduced?)?

There are three reasons why it won’t work:

• As pointed out by WPB, you need to use OS_Memory to map in the physical addresses before you’ll be able to use them (although my code uses OS_Memory 15 rather than 13)
• In all the cases I’ve seen, the DPLL is configured so that the system clock (which is 13MHz on all OMAP machines I know of) is reduced to 1MHz by the N divisor, and M2 is set to 1. This means that the M value directly specifies the CPU frequency in MHz. So your tactic of reducing M2 further definitely wouldn’t work.
• Changing from one OPP to another (which is what you’ll be doing, according to the tables in the datasheet) often entails altering the voltage of the VDD1 power rail. And in order to do that you need a whole bunch of extra code to talk to the TPS65950 I/C over I2C.

There are also a few other things to be aware of when changing CPU frequency (M2 must be >= 2 when in OPP60 on the AM/DM37x, the DPLL must be put into bypass mode before altering M or N, etc.), but since your code was only attempting to switch from OPP100 to OPP130 by altering M2 they shouldn’t have any bearing on why your code won’t work ;)

I noticed on the box it says BB-XM-00 which according to the manual means it has 200MHz memory. Don’t know how to tell for sure.

If you’re wondering whether it’s running at 200Mhz or 166MHz, I think the only way to be sure would be to check the TRM and peek at the timing registers using *memory p. I know I saw some code in x-loader that would detect the two different memory types and set different timing parameters, but I don’t know whether those timing parameters were for 166MHz or 200MHz, or whether that code is even in the version of x-loader that was shipped with the boards.

(deleted, wrong thread!)

I’ll have a look at the datasheet for the xM and see if I can figure out what the problem is. I don’t have an xM myself, though, so I’ll need a brave person to test it out for me!

Whilst comparing page 923 of the OMAP35xx TRM to page 2606 of the AM/DM37x TRM I noticed that the temperature data is held in bits 0-7. So EOCZ is bit 8 and SOC bit 9. I hacked !CPUTmpMon to allow for this. Whilst idling at 1GHz the temperature is showing 39.9C. Goes up to 45.6C in use.

Whilst comparing page 923 of the OMAP35xx TRM to page 2606 of the AM/DM37x TRM I noticed that the temperature data is held in bits 0-7. So EOCZ is bit 8 and SOC bit 9. I hacked !CPUTmpMon to allow for this. Whilst idling at 1GHz the temperature is showing 39.9C. Goes up to 45.6C in use.

Urgh. How woefully slack of me to miss that! Thanks, Chris, for pointing it out. When you hacked CPUTmpMon, did you also change the (undocumented) lookup table of ADC values → mid-range temperatures? If not, the readings you’re getting won’t be right.

You’d have thought that allowing an extra bit for the ADC value would mean they’d doubled the resolution of the temperature measurement. However, despite it now being 8 bits wide, still only values from 0 – 127 are valid. There’s a little note under the table in the TRM that reads: “ADC code values in the subrange 128-255 are reserved for future use.”

Annoyingly, despite the “valid” range of ADC values being the same on the OMAP34x, 35x and DM37x, the translation from those values to temperatures is different!

I’ll prepare a new version of CPUTmpMon as soon as I can and upload it. I suppose it’ll have to include some CPU sensing code now then!

Hi guys, as I said I tried to code a version of my Mandelbrot Bench that is a bit more loop unrolled and reordered regarding the instructions, so may be the Cortex-A8 would benefit from that. Can somebody try it and post the result ? Link

You enter the MHz of your CPU in the beginning, so the efficiency result can be directly calculated in [1000 Iter per second per MHz]. My old StrongARM 233 delivers an efficiency of 44,67 and is finished in 9,01 seconds.

SMULL 3,2,0,1 = &E0C23190 according to BASIC 1.37, not &E0C27190 as encoded in the EQUD. Why the EQUDs anyway? Anything that has SMULL will have a BASIC able to assemble them.

Thanks for the hint…comment was wrong, code correct…oh my god, the last time I had my hands on that was 9 years ago…and somehow back in time I think the code wasn’t able to compile with ‘SMULL’, may be Risc OS 3…now it does even on my old Risc OS 4.02…I corrected the code and uploaded it to the same link…anyone some results ?

Results on a beagleboard XM @ 1.2GHz

44.65
1.75 seconds

Thanks ! So efficiency is totally the same for raw no-memory-access-calculation power…as I looked it up in the technical reference documents on the processor datasheets and instruction timings, there’s not much new for the ALU/MUL/LS units. Basically the 2 instruction pipelines (0 and 1) didn’t change too much, so still the same code dependencies, just much more clock speed :-)

Trying to figure out the best way for CPUTmpMon to detect if it’s running on an OMAP35x or a DM37x. Could someone with a BBxM please post the output of the following:

*memory p 48002000 +4
*memory p 4830a204 +4

Thanks in advance!

I’d recommend using 4830a204 (aka CONTROL_IDCODE). Bits 12-27 are the ‘hawkeye number’, which identify the OMAP type. The latest version of HAL.OMAP3.hdr.omap3530 has the relevant info for all the OMAPs I’ve looked at the TRMs of (although I’m not 100% sure about the OMAP34x). This is how the HAL and the latest version of opp.bas detect the OMAP type.

; CONTROL_IDCODE fields:
; bits 31-28 give the silicon revision
; bits 27-12 give the hawkeye number (OMAP family)
; bits 11-0 are 0x02f
HAWKEYE_OMAP35x_ES10  *   &B6D6 ; spruf98g. Also OMAP34x ES1.0?
HAWKEYE_OMAP35x       *   &B7AE ; spruf98g. Also OMAP34x >ES1.0?
HAWKEYE_AMDM37x       *   &B891 ; sprugn4
HAWKEYE_AM35x         *   &B868 ; sprugr0

Thanks for that, Jeffrey. I’d picked up on the CONTROL_IDCODE register by looking at U-Boot and other Linux code. Certainly that seems like the most obvious way to go. But I’d still be interested to see the output of the CONTROL_REVISION register (48002000) on a BBxM. That’s supposed to indicate the version of the SCM, and since the bandgap temp. sensor is part of the SCM, I’d expect to see a difference there. On my IGEPv2, it gives &00000010.

On an XM.

*memory p 48002000 +4

Address  :     3 2 1 0     7 6 5 4     B A 9 8     F E D C :    ASCII Data
48002000 :    00000010                                     : ....

Thanks, Chris. Well, CONTROL_REVISION is about as useful as a chocolate teapot for my purposes, then! I guess it’s intended for revisions within the same chip implementation.

I’ll use CONTROL_IDCODE as Jeffrey suggests and try to have a new version of CPUTmpMon up soon. I’ve made the new lookup table of temperatures already, so it shouldn’t take long now.

If these different SoCs are going to continue to share the same HAL, there’s probably an argument for the HAL being able to report information about what chip it’s running on to RISC OS, no? Via OS_ReadSysInfo or the like. What are people’s thoughts on this?

...the HAL being able to report information about what chip it’s running on… OS_ReadSysInfo

The -xM appears to not yet have a Machine ID

If these different SoCs are going to continue to share the same HAL, there’s probably an argument for the HAL being able to report information about what chip it’s running on to RISC OS, no? Via OS_ReadSysInfo or the like. What are people’s thoughts on this?

Yes, we definitely need some way of indicating the machine type. At the moment there’s no sensible way for a program to work out if a RISC OS 5 machine is IOMD-based, an Iyonix, or an OMAP board. So that’s the first thing we should sort out, especially since it could be important to some code (e.g. detecting whether LDRH/STRH are safe to use – or deciding whether CPUTmpMon should be allowed to run or not).

Then we’ll have to start deciding on the other stuff – OMAP type/revision detection, board revision detection, etc. But beyond programs that report system info, I’m not really sure if such information is needed – in an ideal world the HAL would do all the OMAP & board detection, then expose to the OS the right set of HAL devices for that board, using some device-specific method to indicate version numbers where appropriate. But of course we don’t live in an ideal world, and sometimes it’s easier to write something quick and nasty in BASIC and worry about adding it to the HAL later ;)

I’ve got no complaints against adding more detailed machine information to OS_ReadSysInfo if people want it, I’m just worried it will do us more harm than good if people start relying on it instead of using the more fine-grained approach of checking individual HAL devices. E.g. if lots of software checked the machine type to see if it was a beagleboard, and then a new, 99%-beagleboard compatible machine appeared (with a different machine type), then all the software which was checking for ‘is this a beagleboard’ would suddenly refuse to run. But if they instead used the more sensible approach of checking individual HAL devices or the ARM architecture version for the specific features they needed then it should only be the pieces of software that are affected by the hardware changes that will refuse to run.

The -xM appears to not yet have a Machine ID

AFAIK they aren’t intending to give it a new machine ID; the Linux kernel can easily check the OMAP type (or the board revision detection GPIOs) to work out if it’s an -xM or not. And of course RISC OS has never used the Linux machine ID (except for booting Linux, or for the bit of code that allows the OMAP ROM to be used as a uImage), so the fact that the BB-xM reuses the BB’s machine ID doesn’t really affect us.

Sometimes it’s easier to write something quick and nasty in BASIC and worry about adding it to the HAL later ;)

Like CPUTmpMon ;)

I think in terms of the HAL and OS we should more or less go down the “ideal world” route. It would be nice, to aid and abet those “quick and nasty” BASIC programs in a uniform way, to have some access from the OS to machine-indicative codes like the Hawkeye number. But programmers who use that method probably need to be aware that to support new hardware they’re constantly going to be having to add new checks to their programs.

It seems like the “proper” way of doing it is by HAL devices, like you say. CPUTmpMon shouldn’t be reading hardware registers at all; it should be talking to the HAL. The temp. sensing needs a HAL implementation, which is something I’ve been thinking about quite a lot. At first I was thinking the HAL should expose quite a high-level API along the lines of “Temp_GetCurrentSiliconTemp” – but as temp. sensing typically requires an A-D conversion which takes (in computing terms) quite a long time, that would involve either the HAL blocking for ages (not good) or the HAL calling back into the OS to say, “Ping! Temperature’s ready!” But that seems too much like OS functionality to put in the HAL. Now I’m thinking that a better approach would be for the HAL to expose a lower level API with “Temp_StartTempReading”- and “Temp_PollReady”-like functionality and implement a complementary module OS-side to wrap that all up in a neat “Temp_GetCurrentSiliconTemp” API for lazy applications to use. The HAL’s “Temp_StartTempReading” could return a flag to indicate that it already knows the result of the temp. sensing for HAL implementations that have some other method of temperature sensing that doesn’t require any significant amount of time to complete (like using the OMAP’s continuous mode, for example). Maybe after I’ve got the next version of CPUTmpMon out, I’ll have a look at HAL-ing it.

Could someone with an xM get in touch to test a new version of CPUTmpMon, please? The email address is in the !Help file. Many thanks!

I was hoping to do this for you tonight but it’ll have to wait a little longer, or someone else can beat me to it… Sorry.

...test a new version of CPUTmpMon, please…

Newer than v.1.00 ? This version (with/without logging enabled by editing !RunImage) shows a constant temp of -40.0°C. I’ll email you regarding the new version.

TI have moved the documents around (again) and the AM37/DM37x TRM is now on rev.C.

fn1. No longer available, AFAICT.