Pandaboard Support

@Jan: Thank You!

The OMAP4 rom is back, but can’t be overclocked to 15000 anymore, it crashes then just after “init mod Blendtable”.

Surely the new rom cannot be overclocked to 1500 anyway, because even if you use MLO1500 the SmartReflex driver overrides this and switches between 350MHz and 1200MHz in any case.

I’ve updated pandaboot.zip to include a utility that can be used to clock the CPU at 1500MHz on a Pandaboard ES using a SmartReflex enabled rom.
I’ve also updated the included !CpuTmpMon so that it also displays the CPU speed in GHz.

I tried last nights build no crash on boot but and at the predesk stage (I think!) I got Disc Error on the SDCard and then found that various directories were broken. Replaced ROM with a version about a month old. SD card still with Broken Directories. That is the first ever corruption I’ve had on the Pandaboard.

.

Hmmm! I’ll wait until this is sorted before trying the latest rom on my main SD card.

However I have just tried the 06-Nov-2013 OMAP4 rom (on an expendable card!) and it seems to work OK.

With RISC OS 5.19 (06-Jul-2013) the shutdown option (CTRL-SHIFT-f12) gives me a window offering the ‘Are you sure you want to shut the computer down?’ window with ‘Restart’, ‘Shutdown’ and ‘Cancel’ as the options. Choosing ‘Restart’ does, indeed, cause the Pandaboard to do a power-on restart.

I had been using RISC OS 5.21 (03-Sep-2013). When selecting CTRL-SHIFT-f12 I would get the message ‘Your computer is ready to be switched off’ offering just the one option ‘Restart’ which no longer worked (the computer just freezes). Although the 06-Nov-2013 rom still just offers the single choice, it is now working again.

Why is the shutdown option now just offering the single choice? What was in 5.19 seemed better?

Although the 06-Nov-2013 rom still just offers the single choice, it is now working again.

Not quite – the 06-Nov-2013 version produces the window ‘The computer is now ready to be switched off’ with a single option ‘Restart’. If you click the ‘Restart’ button with the mouse, it does indeed do a power on restart. If you press ENTER instead, which is what I normally do (which should be the same thing) it just freezes.

Thanks for the CPU scaler, it’s nice to get 1.5GHz ;-)

I am using ROM v5.21 of 2/11/2013 on my Pandboard by copying it ‘over’ the previous version. I now want to copy in the files in Chris Gransden’s pandaboot, but in what order? Should I start afresh, delete what’s in the bootloader partition (after taking copies) and then copy in the pandaboot stuff in the order MLO, MLO1200, MLO1500, MLO_1500_466, MLO_1600_466 and then all the other files (I may omit the last 2 of these 5 MLO files) except, of course, the smartreflex directory?

You just need to copy MLO, u-boot.bin, preEnv.txt and uenv.txt. The SmartReflex rom now takes care of setting the CPU speed. If you want 1.5GHz you also need to copy the smartreflex folder into predesk.

I found that the ‘MLO’ was already the same anyway (there is an apocryphal story that MLO must be the first copied over). My method for certainty is to place the SD card in a Windows machine, do a quick FAT format (which does not disturb the partitioning), copy over the ‘MLO’ file first and then the rest. That works every time.

90% of the time, copy and rename using DOSFS via the image file $.!Boot.Loader work fine. Occasionally an upper case 8.3 filename gets treated as a non-upper case/long filename and appears as FILE~1.XXX to the Pandaboard/Beagleboard but FILEX.XXX to the RISC OS DOSFS. Most annoying. Everything looks right but the machine won’t start up! Make sure the filenames are in upper case before you copy them and most of the time you will be OK. Occasionally the two FATs become inconsistent and the contents of the card look different on different machines. Even more confusing!

With RISC OS 5.19 (06-Jul-2013) the shutdown option (CTRL-SHIFT-f12) gives me a window offering the ‘Are you sure you want to shut the computer down?’ window with ‘Restart’, ‘Shutdown’ and ‘Cancel’ as the options. Choosing ‘Restart’ does, indeed, cause the Pandaboard to do a power-on restart.

This change has never been in the ROOL sources. You must have received the rom from elsewhere.
Shutdown→Restart still has problems when using the ROOL rom. Also Ctrl-Break more often than not results in a freeze. The only reliable way of restarting without removing power is to press the ‘Reset’ button on the board.
See the OMAP 4 port status page.

This change has never been in the ROOL sources.

Ah! Hadn’t realised that. I was going to look through the sources to see why it was changed – that saves me the effort. It was from PandaLand by RComp.

@Chris Gransden
Thanks for help and thanks for the pandaboot files. It’s good to have these files all in one place. Panda is running more like a Puma than a Panda. Perhaps I will rename it Pumaboard. Although I am unsure as to what I will need the extra speed for other than the demos of the hardware floating point, e.g., !CubeDemo and Mandelbrot set.
I am still waiting in hope that someone will sort out the other clock, the RTC, as I already have the hardware on my Puma.

Can anyone solve the following problem. I have a FAT formatted USB stick with 13 objects on it (5 directories and 8 files). If I mount it by clicking adjust on its icon I see all 13 objects; but, if I mount it by clicking select on its icon, I see only 8 objects (all 5 of the directories and 3 of the files). Weird or what?

With RISC OS 5.19 (06-Jul-2013)

You must have received the rom from elsewhere.

Yes, that number/date pair isn’t valid since 5.19 was discontinued on 01-Jun-2013 .

Was nothing learned from the ROL/Castle wars? Or is another OS fork what’s needed?

As I happen to have been conscripted to review some of the submission backlog, I know that the two unresolved SmartReflex questions are blocking a change to the HAL audio to swap L+R over, and HAL clock to support for the CJE micros addon. The extra mouse click to shutdown has never been added as it serves no purpose – it doesn’t magically fix whatever is happening when the chip is being shutdown and I get the impression that kicking such problems under the carpet isn’t ROOL’s style. Hence, no stable badge on your lapel.

The current RO release from R-Comp for the ARMiniX identifies itself as 5.19 (06-Jul-13). IIUC this is because Willi had been continuing to call his releases thus far for the ARMiniX ‘5.19’ despite having some features which elsewhere have appeared in ‘later’ OS-numbered versions. I guess he saw this as more of a ‘bugfixer’ release than an upgrade.

The main ‘headline’ change I was aware of in the above was the removal of the low audio sample rates as they weren’t working correctly. Also it provides SharedSound 1.12. But there are other changes over older releases. The audio ones are what I’ve been most interested in.

BTW I just checked. The L and R channels are still reversed on the output socket of my ARMiniX running the above OS version. I only installed it a short while ago and have been distracted by trying USB Audio on the Iyonix. FWIW I normally use an external headphone amp/filter with its leads switched over to correct this. But I just checked using a pair of phones with LR labels plugged directly into the ARMiniX’s output.

Jim

Was nothing learned from the ROL/Castle wars? Or is another OS fork what’s needed?

[…]

IIUC this is because Willi had been continuing to call his releases thus far for the ARMiniX ‘5.19’

Where are you guys getting your date information from? Given the “shutdown” options/behaviour, it might be that you are using a newer version of RISC OS with an older version of Switcher; and so looking at the version/date there might be inaccurate.

There are two ways to deal with a shutdown methodology that is not the same across versions of RISC OS (for instance, there appears to be no power off or opportunity for such in the Pi build, however such hardware does exist).

The first way is to trap service calls and such and work around how RISC OS behaves. It’s a little bit grotty, but it slots in and does its job and can easily be removed if and when RISC OS is able to support such a thing for itself. Moreover, it is not integral. If you don’t run it, your power button stops working, it isn’t the end of the world. [ http://www.heyrick.co.uk/blog/index.php?diary=20131027 – halfway down after the iMac stuff ]

The other way…is to patch Switcher. A seemingly more logical approach (patch the shutdown code itself) until you realise that it is a fairly integral part of RISC OS, and thus is a tad…messier. In, like, my humble option, or something.

The ‘Are you sure you want to shut the computer down?’ window is fairly standard – that is the message I get every time on Virtual Risc PC and so it seems fairly familiar and sensible.

Moving from 5.19 (30-Sep-2012) [the version from PandaLand] to 5.21 (03-Sep-2013) causes the sound to be much worse – rather than just getting the timing wrong, the pitch is now worse.

Does this mean that the SmartReflex driver has a negative effect on the sound part?
Could you please clarify?
This worse is currently blocking any further update for OMAP4 HAL.

My recollection of what I said nearly two months ago is that the removal of the ‘kludged’ 22kHz sound sample rate (which happened between Sep 2012 and Sep 2013, see below) meant that voice handlers which expected the buffer period to be 100cs (and applied amplitude and frequency modulation increments each buffer period) would now apply these at the wrong intervals and make the sound appear even worse. There is also a timing problem in that the BASIC SOUND command fifth parameter (start beat) which says that the sound should start that many beats later and that a beat is, by default, 10ms means that the timing of sounds is wrong. The pitch itself is correct, subject to the limited resolution of the sample period at higher sample rates (expressed in whole numbers of microseconds). This means that voice handlers need to be recoded and recompiled to work at different sample rates. Also that the SOUND command in BASIC will not work as documented as the beat rate ends up much faster, affecting the ‘start beat’ parameter.

For the OMAP4 port a HAL change in April 2013 (version 1.14) is probably to blame for this 'bug':

s/Audio:

    changed recovering from error conditions

    disabled kludge for supporting non native samplerates (44.1 + 48k)

I have raised a bug report for BASIC (but it is actually the sound system call it uses).

I am pleased to say that the stable build of 5.20 (10-Jun-2013) for the ARMini works correctly and does not suffer from this behaviour. I assume that the 5.20 builds for Risc PC and Iyonix will also be OK.

My recollection of what I said nearly two months ago is that the removal of the ‘kludged’ 22kHz sound sample rate (which happened between Sep 2012 and Sep 2013, see below) meant that voice handlers which expected the buffer period to be 100cs (and applied amplitude and frequency modulation increments each buffer period) would now apply these at the wrong intervals and make the sound appear even worse.

A complication here is that there are (at least) three different sections of the sound system which may be affected in different ways.

The removal of the ‘low rates’ should only mean for playing ‘16bit’ audio using PlayIt, DiscSample, etc, that you have to ‘interpolate’ and use double the rate for output.

For ‘8bit’ the situation may be different as that gets into the legacy of ‘wave generators’ etc.

For DRender (unix ports) the loss of the low rates means that DRender needs attention because it takes for granted that low sample rates are provided and hasn’t been able to ‘invisibly mend’ to interpolate. Hence the chipmunks effect.

BTW When I wrote what I did about OS version and date I was simply reporting what I get via the Info from the switcher icon. On an ARMiniX “5.19 (06-Jul-13)” is how the OS Version is listed.

Jim

Excellent news. Since June 2014 (see bug ticket #347, now fixed) the sound system on OMAP4 has been sorted out to correct the tempo problem. The 2007 version of my !SignalBox application (which uses 8bit voice handlers extensively) now works correctly on the Pandaboard ES and the specially kludged version for the ARMiniX is only required if the ROM is before June 28 2014. Note that current PandaLand ROMs are currently April 2014 and therefore require the kludged version.

I did get an abort at &FC136B44 (offset +1B414 in WindowManager 5.43) but this did not recur. Also I got an abort on data transfer at &FC027D20 (offset +88D6 in Utility Moduule 5.21 (16 Jul 2014)) once so it looks like there are still a few gremlins in the lastest development rom.

Nice to see the CPU speed stepping up from 0.35GHz to 1.5GHz whenever the signalman pulls some levers!