Two techie questions for Pandaboard (ES) owners

Here are a couple of questions for any Pandaboard (and ES) owners who have a few minutes and some technical mastery to be able to do a couple of experiments to re-test some of that port’s status . Don’t worry if you can only help on one of the two points – better to skip the question than guess the answer!

a) Did you ever previously suffer from not restarting with certain brands of SD card when pressing the reset button? Did the problem go away in ROMs dated after 23-Mar-2014? To be able to confirm or deny this, you’ll clearly need to have been unlucky enough to have an SD card from a problematic vendor, and a (backup) ROM from before the mentioned date.

b) Can you see green speckles on your monitor at 1920×1200? I suggest using this standard image for the test, and also stating what refresh rate display manager says, and how you connect to your monitor (VGA adapter, HDMI adapter, DVI cable, whatever).

Many thanks in advance for your help.

How urgently do you need a response?

How urgently do you need a response?

Some time in July would be fine. Ideally 3 or more people will try out, and the answers will be unanimous, so that the port status can be updated (or an investigation triggered to the causes of (a) and (b)).

I have RISC OS 5.21 (21-Apr-2014) from PandaLand and if I press the Reset button the screen just goes blank – on the serial port nothing happens, no x-loader, nothing. If I unplug the SD card (a Sandisk 32G Extreme class 10 45Gb/s) and plug it in again, then one of two things happens:
EITHER the green LEDs light but no sign of the debug code for module initiation. I have to power off.
OR it starts up OK.

CTRL-SHIFT-f12 gives me the ‘Restart/Shutdown/Cancel’ option and ‘Restart’ works fine.

If I load the 16-Jul-2014 development ROM instead and press the reset button, the screen just goes blank – on the serial port nothing happens, no x-loader, nothing. If I remove and replace the SD card then it carries on, module init code and desktop. CTRL-SHIFT-f12 gives just the single option ‘Restart’ which works OK.

My monitor is native 1920×1080 but at 1920×1200 I can’t see green speckles.

1/ Reboot was impossible on my configuration in january. Seems OK today, but with ‘abort on data transfer’ on some applications. Not every time. System seems to be very stable now. See (and follow) http://www.riscos.fr/cgi-bin/uptime

2/ 1920×1080 is OK here. 1920×1200: I don’t know, but I think OMAP4’s GPU is not really good for this. I hope that dual 1920×1080 will be possible one day (and will pay for this, since I really need it).

Not much help from me I’m afraid. I use a PandaRO, and have always used the SD card as supplied by CJE, updating the OS every week or so. Machine is on 24/7, but do need to reboot sometimes when a development prog goes belly up, or OS is updated, etc. Never had any problem – I always use the reset button (after a C-S-F12 if that is still responding) and I think it has always rebooted correctly. I have got in to the habit of rebooting this way on PB, BB, RPi and Iyo, because the Iyo is sometimes temperamental.

My display is 1920 × 1080 so that is rock solid – the only 1920 × 1200 display I have is an old analogue monitor, which is now out of use.

I used to suffer from the reset problem with my SD Cards (SAN Disc Extreme), it’s been working for awhile now – not sure when it was fixed, but March sounds about right.

I don’t have any speckling with the image on 1920×1200 at 60Hz, 47Hz or 40Hz. However at that resolution you need to go for 40Hz otherwise you will get random colour strangeness.
They are usually blue “bleeds”, it seems to revolve around number of colours.
It shows on the rool forum, on the |Home|News| bar. You get blue effects on the text and separators.
Or on this graphic for one:
Motoko Kusanagi

Not a good likeness, but it shows the blue hue effect on her chin

The image test doesn’t show it up, but if you go to the BBC News website, or use my NewsUK app ;-) those graphics usually do show up the strange effect.

It happens noticably at 60Hz, at 47Hz it still happens but much less.
At 47Hz I can just see it looking at “Theend” digital blasphemy photo. at the bottom left of the sun there is a line artifact.
At 40Hz I’ve yet to see any issues.

Dual 1920×1200 would be lovely, not 1920×1080 as I like to do work rather than watch movies all day ;-)

When we designed the PandaRO the received wisdom was that reset pins on the PandaBoard did not work reliably so we programmed the power control PIC to turn the power to the Pandaboard off for one second and back on again if the reset button fitted to our PandaRO’s was pressed.
We have now redesigned the PCB and offer the option of pressing the RESET button to reset the OMAP chip or doing a one second power off, with a default of resetting the CPU.

So existing PandaRO users can’t do sprow’s test ‘a)’

n.b. Our power control board for the Raspberry Pi can have a reset switch attached to it in which case the power control PIC will turn the power to the Raspberry Pi off for one second and back on again or for MK2 Pi’s it can be connected to the motherboard reset (Confusingly marked as ‘RUN’ on a B+)

I used to have the reset issue with the Pandaboard ES. I’m using a 16GB Sandisk Extreme card. The reset issue seems fixed now! (Not sure exactly when this changed)

I’ve connected my Pandaboard to a Samsung S27C450 monitor via a HDMI to DVI cable.
Running at 1920×1200 at 60Hz (This monitor refuses to do 40Hz)

With the test image that Sprow linked to, I have a single turquoise line in the grey test pattern.

I can photograph this, if it would help?

Sprow: Not seen the SD card issue with my cards, but unable to test the latter as I can only test on 1080p (which seemed stable). Unfortunately testing on the Panda has for now been relatively infrequent as my primary monitor is VGA-driven, and the software I need has been bought on NutPi so remains Pi-only.

Does firmware issue make a difference? Not sure whether the Panda’s firmware has developed as frequently as the Pi, but the Pi has certainly seen RISC OS-side benefits from firmware developments.

For the green blobs – worth checking with the EDID code in (when that goes into the codebase let’s see whether the green blobs have gone) as that way we should know that the monitors are being driven with the correct parameters (probably reduced blanking). I did find that I personally got better monitor stability with EDID as the MDFs were often best guesses or were non-reduced-blanking when they should be reduced-blanking etc. Is the 1900X1200 being used by people from an MDF file in !Boot, or one derived from the actual monitor’s parameters?

We have now redesigned the PCB and offer the option of pressing RESET to reset the OMAP chip or doing a one second power off, with a default of resetting the CPU.

I see my wording was poor, by reset button I meant the push switch S1 on the circuit board, not the reset dialogue provoked by Ctrl-Shift-F12.

Chris Hall’s post suggests it’s still a problem and he has distinguished between the two methods. Malcolm & Rob could you say if your comments refer to button S1 being pressed? If it is the pre-RISC OS loader getting stuck, have you ever changed those files on the SD card?

I don’t have any speckling with the image on 1920×1200 at 60Hz, 47Hz or 40Hz

You sure you can get 60Hz? There should be smoke at that pixel rate! Again to clarify, the problem noted is artefacts at 1900×1200 not other resolutions. If you do see imperfections, perhaps share the lines from the MDF so William can take a look.

I see my wording was poor, by reset button I meant the push switch S1 on the circuit board, not the reset dialogue provoked by Ctrl-Shift-F12.

Now my turn to admit poor wording. Talking of the PandaRO I was referring to the case RESET button or the RESET button we fitted on our I/O shield. I’ve edit my reply above to clarify and now says:

When we designed the PandaRO the received wisdom was that reset pins on the PandaBoard did not work reliably so we programmed the power control PIC to turn the power to the Pandaboard off for one second and back on again if the reset button fitted to our PandaRO’s was pressed.
We have now redesigned the PCB and offer the option of pressing the RESET button to reset the OMAP chip or doing a one second power off, with a default of resetting the CPU.

Sprow: Amazed that 1900X1200 is so unobtainable, yet the device has two possible HDMI inputs. Is there really such a big difference in GPU performance that the Pandaboard can’t cope with 1920X1200@60Hz, yet you can now run a Pi at 4k@30Hz! If correct, that makes for an interesting ‘high end’ platform choice in RISC OS land now:

- Panda: fastest raw ARM performance, supports hot-swap dual HDMI. Dual-core (but unused).
- Pi: greater resolution support, greatest breadth of 32-bit software support, greatest hardware expandability. Much cheaper.

In a sense that’s actually really frustrating as the case for work towards multi-core would be strengthened if more people were using a multi-core machine that only employed a single core. It also makes the justification for the additional spend on a Pandaboard quite a leap. (I was fortunate and a random scout of eBay turned up a non-ES Pandaboard for a complete steal).

I manage at 40Hhz perfectly, and it’s usable at 46 or 60Hz at 1920×1200.
The speed difference between the Pi and the Pandaboard ES is fairly significant having used both the Pandaboard was worth the money for me.
IMHO dual core won’t help in 90% of cases. The major issues are core RISC OS issues and are easily solved, more resources, full time staff.
That will need one bad ass bounty :-(

This is the MDF for 60Hz and 46Hz – both of which show the strange artefacts, talking of which I’ve managed to get a fly inside my monitor – one of those tiny black gits.

1. 1920 × 1200 (46Hz)
   startmode
   mode_name:1920 × 1200
   x_res:1920
   y_res:1200
   pixel_rate:120000
   h_timings:32,80,0,1920,0,48
   v_timings:3,26,0,1200,0,6
   sync_pol:3
   endmode

1. 1920 × 1200 (60Hz)
   startmode
   mode_name:1920 x 1200 (16:10)
   x_res:1920
   y_res:1200
   pixel_rate:154000
   h_timings:32,80,0,1920,0,48
   v_timings:3,26,0,1200,0,6
   sync_pol:3
   endmode

As regards the reset, I was thinking about the shutdown reset not S1 reset.
But I do get problems with the loader getting stuck on normal boot occasionally and I have changed the files, but not recently.
If I had any idea & time how to get new ones, (I know Chris Hall is working on it) I’d experiment a bit.

Malcolm: The VESA standard for v_timings at 1900X1200X60Hz (reduced blanking) is: 6, 26, 0, 1200, 0, 3. Doubt it will make a difference (front porch and back porch are flipped) but probably important to ensure it’s correct.

The timings on 1. are almost certainly wrong – are they guesses or extracted from monitor data? I could calculate CVT reduced blanking calculations for 46Hz, but it would be wiser to see what the monitor reports to the Pandaboard once we’re there. I suspect adjusting pixel_rate alone is insufficient to actually reduce the frame rate and you may find your monitor is ignoring you and thinks you are just sending it 1900X1200X60hz anyway (most monitors support only ‘discrete’ modes so if it’s near enough it would still function at 60Hz).

Once we have a stable ROM image containing EDID it will be useful to see what modes you are offered.

Sprow: Not seen the SD card issue with my cards, but

How can the type of SD card prevent the x-loader from starting when the reset button is pressed (either the reset button on the circuit board or the CJE-supplied reset button on the back of the case), until you unplug and re-plug in the SD card? Also it seems that it was fixed before 23 April (see my edited post above).

It appears, therefore, that the failure to restart on reset is nothing to do with RISCOS. It is just the same if you boot RISC OS from SCSIFS – i.e. if RISC OS make no access to the SD card at all, you still cannot get the reset button to start the x-loader.

If this is what is stopping RISC OS being stable on the Pandaboot, then hopefully the fact that it is nothing to do with RISC OS might move this forward.

*** This is where it hangs ***

Texas Instruments X-Loader 1.41 (Feb 27 2012 - 11:44:12)
OMAP4460: 1.2 GHz capable SOM
mmc read: Invalid size
Starting OS Bootloader from MMC/SD1 ...


U-Boot 2011.12-00001-g8df5795 (Mar 31 2012 - 16:05:42)

CPU  : OMAP4460 ES1.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
checking for preEnv.txt
reading preEnv.txt

29 bytes read
Loaded environment from preEnv.txt
Importing preboot environment from mmc ...
Running preenvcmd ...
Hit any key to stop autoboot:  0
reading uEnv.txt

100 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading cmos

2052 bytes read
reading riscos

5242880 bytes read
## Starting application at 0x82000000 ...
OMAP4 HAL init
Board config=PandaBoard
HAL_Init
HAL initialised
IICInit
HAL_KbdScanSetup
HAL_CleanerSpace
InitCMOSCache entry
InitCMOSCache done
IMB_Full done
Keyboard scan complete
POR detected
InitDynamicAreas
InitVectors
InitIRQ1
IMB_Full
VduInit
ExecuteInit
KeyInit
MouseInit
OscliInit
Enabling IRQs
IRQs on
HAL_InitDevices
InitVariables
AMBControl_Init
ModuleInit

The 47Hz mode is reported as 47Hz by the monitor. (the MDF shows 46 but both RISC OS and the monitor show it as 47)
I changed the front/back porch round and that made no difference.
FYI my monitor is the Asus PA248
I’m missing a lot of modes for the low-res games modes for RISC OS, is there any documentation for constructing modes. I’ve managed to get a mode for James Pond after a hell of a lot of fiddling, but it was painful.
(Using MakeModes)

For the hang on reset, a relevant question would be: Does it also crash when running Linux? If it crashes after running RISC OS but not after running Linux then that suggests it’s something that RISC OS is (or isn’t) doing which is giving the board some difficulty. E.g. for OMAP3 if you use SmartReflex/DVFS you need to program a reset script into the power IC in order to make sure the core voltages get reset to their default levels when the reset button is pressed. And for soft resets (i.e. via the shutdown dialog) it helps to make sure you disable SmartReflex before resetting the SoC (soft reset and hard reset via the push button do reset different things)

For the hang on reset, a relevant question would be: Does it also crash when running Linux?

Yes. Exactly the same effect. Press the reset button after booting the Linux kernel (uImage) and you have to unplug and re-plug the SD card for x-loader to start. Looks like it is a Pandaboard issue rather than a RISC OS issue.

OMAP4460: 1.2 GHz capable SOM
Starting OS Bootloader from MMC/SD1 ...


U-Boot 2011.12-00001-g8df5795 (Mar 31 2012 - 16:05:42)

CPU  : OMAP4460 ES1.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
WARNING: Caches not enabled
MMC:   OMAP SD/MMC: 0
Using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
checking for preEnv.txt
reading preEnv.txt

29 bytes read
Loaded environment from preEnv.txt
Importing preboot environment from mmc ...
Running preenvcmd ...
Hit any key to stop autoboot:  0
reading uEnv.txt

163 bytes read
Loaded environment from uEnv.txt
Importing environment from mmc ...
Running uenvcmd ...
reading uImage

4434784 bytes read
## Booting kernel from Legacy Image at 80000000 ...
   Image Name:   Ubuntu kernel
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    4434720 Bytes = 4.2 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

*** Now press RESET ***

*** Hangs here until SDcard is unplugged and replugged  ****

Texas Instruments X-Loader 1.41 (Sep 29 2011 - 10:43:53)
OMAP4460: 1.2 GHz capable SOM
Starting OS Bootloader from MMC/SD1 ...

(et cetera)

The green colour distortion occurs on all monitors above a certain pixel rate. It only happens on a band of colours (test in !Paint colour palette) at exactly half way. I guess it is 127/128 point on both R and B and any G value, but haven’t tested that. The problem vanishes below the magic rate. We developed ARMini and ARMiniX to cope with such things, but obviously if this turned out to be OS-fixable, that’d be fantastic.

Since it only happens on certain colours, many users would be oblivious to the problem until pointed out. Indeed, at shows I make a point of running with the fault visible, so that customers aren’t sold fake promises. To be honest, I don’t think anyone has ever noticed without me pointing it out.

Note that it also occurs at 1080p at 60hz and even 1680×1050 at 60hz.

It is 100% repeatable on every one of the “insert quite large number” pandaboards I’ve worked with, both via HDMI→DVI or HDMI→HDMI.

Please drop me private email if you want further experience/info/report with Panda :)

Please drop me private email if you want further experience/info/report with Panda :)

How about a photo for those of us without a Panda?

It appears, therefore, that the failure to restart on reset is nothing to do with RISCOS. It is just the same if you boot RISC OS from SCSIFS – i.e. if RISC OS make no access to the SD card at all, you still cannot get the reset button to start the x-loader.

That’s not necessarily conclusive, since even if you don’t mount the SD card from RISC OS the various HAL functions will have set up the controller during the early init on behalf of SDIODriver.

If this is what is stopping RISC OS being stable on the Pandaboot, then hopefully the fact that it is nothing to do with RISC OS might move this forward.

…or might not. Getting a stable badge should be hard, handing them out to half finished ports just devalues the “brand” by giving people who have spent many £100’s a poor experience. I’m sure those with long memories can name at least one computer that never really got finished and the effect that had.

I see from Chris H’s serial port log that the X-loader didn’t print its stuff out, so we can assume it’s somewhere in the ROM initialisation sequence. A quick internet search threw up a similar query in the TI forum in which a potentially related errata is mentioned – specifically i739.

A squint at the Pandaboard ES schematic shows the sysboot pins are set to 11???1?1 where a ? is a (slightly risky) floating pin. I assume they’re relying on a weak pulldown in the chip to make that 11000101 (try USB first then SD card).

There’s a teeny switch, SW1 that should swap the boot order to 11001101 (try UART first then SD card) which might be worth a try flipping that switch in case a UART timeout gives the SD card more time to be happy.

Does RISC OS mess around with the PAD settings for the sysboot pins? Perhaps it should? Would driving lows on the floating pins make it more reliable? What’s the voltage on VIO_1V8 during a reset? Is SDMMC1_VDS unstable and thus triggering the errata? Does the same happen with JTAG connected? What does the ROM bootloader trace area at 0×4030D040 show? Has anyone any more suggestions than these that I just came up with in 20 minutes?

The green colour distortion occurs on all monitors above a certain pixel rate […] I make a point of running with the fault visible, so that customers aren’t sold fake promises.

An honest salesman? You’re a rare creature.

Please drop me private email if you want further experience/info/report with Panda :)

Well, this does sound like it’s some combination of pixel rate or memory bandwidth that is causing the problem. One way to resolve that is impose an upper bandwidth limit in OMAPVideo just the same as a Risc PC wont let you change into big/deep modes without 2MB of VRAM. It’s not “fixing” it per se, but at least you can’t get to that mode in the first place.

Only problem with the “limit video” option is that the modes do display, and many users are quite content with it. Just had a happy email from a guy who took delivery in NZ last week. For obvious reasons, he bought a screen locally, and seems happy running at 1920×1200@60hz (despite being aware of the pitfall). It’s a tricky one, because really a lot depends on what pinboard backdrop you choose as to how obvious it is!

You’d effectively have to cap it 50k+ px rate lower, despite it putting out a picture at higher values.

It is a particularly odd problem for sure, because it feels like it is so close to perfect. Compare this to Beagle which just flaked out above 95k-ish and refused to display anything, and it feels a very different beast.

However, this is unfortunately why EDID isn’t too terribly helpful for Beagle and Panda, as the most suitable modes won’t be exposed by the EDID :(

On Beagle, you’d be effectively limited to 1280×800-ish, and on Panda you’d be at 1600×900 (assuming that’s in the EDID). Ho hum.

Beagle does, incidentally, set a hard 100k limit if memory serves (might be lower) due to the failure in the mid 90ks. It varied a bit from board to board though, as I saw some that struggled past 92k, whilst I think I had one reach 98k.

Panda is more cut’n’dried in that the fault point is repeatable, but with the fault being non-fatal, I’d find it hard to support a hard block.

I’ve uploaded some jpgs here
It only happens on some images, which is kind of strange, most are generally OK.
I’m lucky enough to have a monitor that will display at 40Hz, but not everyone is so lucky.
I was wondering if anyone has tried this on linux on the pandaboard?

I found the pics interesting, Malcolm, not because I have noticed it on the PandaBoard (mine runs at 1920×1080), but that I was viewing some jpegs in Netsurf on the BeagleBoard a few weeks back and saw some similar effects to the middle pic (green ‘lightning’ on the clouds) but simply put it down to iffy jpegs. The BB is also running 1920×1080. There is probably no connection but ….