Two techie questions for Pandaboard (ES) owners
Sprow (202) 1150 posts |
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. |
Chris Hall (132) 3548 posts |
How urgently do you need a response? |
Sprow (202) 1150 posts |
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)). |
Chris Hall (132) 3548 posts |
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: 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. |
David Feugey (2125) 2709 posts |
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). |
Chris Johnson (125) 825 posts |
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. |
Malcolm Hussain-Gambles (1596) 811 posts |
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. 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. Dual 1920×1200 would be lovely, not 1920×1080 as I like to do work rather than watch movies all day ;-) |
Chris Evans (457) 1614 posts |
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. 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+) |
Rob Heaton (274) 515 posts |
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. 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? |
William Harden (2174) 244 posts |
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? |
Sprow (202) 1150 posts |
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?
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. |
Chris Evans (457) 1614 posts |
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:
|
William Harden (2174) 244 posts |
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). 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). |
Malcolm Hussain-Gambles (1596) 811 posts |
I manage at 40Hhz perfectly, and it’s usable at 46 or 60Hz at 1920×1200. 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.
As regards the reset, I was thinking about the shutdown reset not S1 reset. |
William Harden (2174) 244 posts |
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. |
Chris Hall (132) 3548 posts |
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.
|
Malcolm Hussain-Gambles (1596) 811 posts |
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) |
Jeffrey Lee (213) 6048 posts |
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) |
Chris Hall (132) 3548 posts |
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.
|
Andrew Rawnsley (492) 1440 posts |
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 :) |
Rick Murray (539) 13759 posts |
How about a photo for those of us without a Panda? |
Sprow (202) 1150 posts |
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.
…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?
An honest salesman? You’re a rare creature.
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. |
Andrew Rawnsley (492) 1440 posts |
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. |
Malcolm Hussain-Gambles (1596) 811 posts |
I’ve uploaded some jpgs here |
Chris Johnson (125) 825 posts |
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 …. |