Software testing help wanted for Raspberry Pi

Minor display bug with !Packman itself.
With the main package list window open, resize as big as it will go.
With the vertical scroll bar at the top, so “AlephOne” is visible at the head of the list, resize into the left and back out again. There is no description text redrawn if it extends beyond the grey bar at the top.
“Cache” is the first obvious casualty.
If the vertical scroll bar is not at the top, it does seem to redraw correctly.

The blackscreen and beep crash thing is not limited to one package.
Anagramarama, Blackbox and Flobopuyo also have the same effect.

“Update lists” does not come up with todays ROM etc. No problem, I’ll update them manually.

*Edit – Nevermind, there isn’t one for today! That’ll be why then.

Just been working through some of these. A thought occurs. Are you in ARMv5 compatibility mode? The CPU option in Configure should be set for ARMv5. If you don’t have a CPU option in Configure, you may be in the wrong mode and ARMv5 things may fall over.

I can’t repeat the above display bug in PackMan 0.7. I think the window resize is due to AlephOne having the longest description in the list.

I’ve been using Raspberry Pi and latest distro, ROM image etc I can get at the time, but haven’t done anything with any compatability mode. Should be “straight out of the box.” Even reflashed the SD card to make sure.

I have nothing relating to a CPU option in !Boot.Loader.CONFIG/TXT as supplied.

What might need to be there, and is this something to consider as standard for the next release?

I meant the RISC OS configuration – click menu over the task manager icon on the iconbar (it’s a raspberry in recent versions) and Configure… Then check if you have a CPU button. I can’t remember what’s been released when (this is the same issue as the ‘rotated loads’ mentioned in the first post of this thread, but the first cut of the plugin was a bit confusing and I’m not sure what the correct settings are).

If you don’t have the latest plugin, you can find it here CPUsetup . That’s a temporary version – it’ll come in the full distro.

Quite keen for any more feedback on packages, by the way :)

I think the full official release for the Pi should be code-named ‘Asymptote’ (a line that continually approaches a curve but never reaches it).

Just used the latest firmware (the 192 split) and I’ve got my Pi clocked at 1GHz ;-) No overvoltage or anything, which is lovely.

Malcolm, are you still running it overclocked? Has it been stable?

I’ll be honest, not been using rotated loads thingy in general.

Taskmanager.Configure:-
Plug-in not there. Downloaded and merged with !Boot.
Re-Booted and now an option on Taskmanager.Configure
Top option, ARMv5 already selected.

Just to throw another spanner in the works, re. CPU configure, bottom buttons, got “Default” and “Cancel”, but there is a third that doesn’t appear fully in the window. Looks like it may begin with “S” but not visible. Assuming it is “Set”.

After that…

Tried BlackBox again. I think there is a bug in the gameplay, where it doesn’t always recognise a solution with the lasers in the left hand corners. But that may be another issue!

Tried the resize to 800×600, then quit game, then resize to 1920×1080. Still falls over. Black screen and needs power off reset.

Also noticed, when I click on !Packman icon on Iconbar, a new window opens each time.
Still have the same !Packman display issue.
Click on iconbar icon for fresh !Packman list window. Drag resize button right and text for “Cache” (in white window, not lower grey one) stops at “applicatior”. Letter “n” not fully formed. Scroll bar down and back up, full text appears.

While I’m conducting these tests, I’m trying to assume the position of a new user, using the latest software/distro as is and reporting things I find that might put them off, rather than hunting for solutions.

On an aside, my Brother has my other RPi. Still waiting for his from RS. Will have to get him to try the same when he has time.

Re. BlackBox gameplay bug, !Taskman.Configure.CPU display bug and !Packman display bug. I hope this screenshot works!

!Packman display bug

The truncation of the descriptor field in !Packman (as shown for the Cache entry) has been present from the earliest version of !Packman, and occurs on the Iyonix and BB as well.

I thought I’d sent Theo a fix for the CPU Features display bug, it needed a tweak to the Templates file. Did you get it Theo?

Meantime, I’ve uploaded a fresh copy with the template tweaked here Let me know if this cures the problem for you.

I merged in the templates file in with the official distro, so that should be included. The version I pointed to here is a zip that’s been lying around my webspace – I wasn’t sure if it was the latest, it was easier to link to that than pull it out of the distro. So apologies if it was older than I thought. Andrew, are you officially maintaining CPUsetup? There was a patch for it, but I wasn’t clear on what to do with it.

PackMan display bug: ah, I understand, I’ve seen that before. Now added it to the list (which, for the time being, are PackMan frontend issues, packaging system issues, (things being installed wrong, etc) and packaged software issues ). Also added the multiple windows thing (more of a problem when running multiple PackMans on the same database).

Thanks everyone for the reports, by the way, they’re really appreciated. We’ve had our hands full trying to fix critical bugs, so haven’t been able to test everything as much as we’d like. So every little helps :)

Andrew, are you officially maintaining CPUsetup?

Sure, I’m happy to do that. Is it in the autobuilder thingy, or best kept on my website?

It’s not in ROOL CVS yet, so if you want to keep track of things on your website that would be easiest for the time being. It would be good to have it in CVS at some point though… (CVS for BASIC programs is slightly awkward, I don’t know if there’s an easy solution for it)

There are plenty of BASIC programs in CVS. The general approach is to store it as text without line numbers, for easy diffing. It then gets numbered, tokenised and crunched during the build to produce the output BASIC file.

Gavin: I’d missed the force_turbo off my config at 1GHz, however I have it running at 900MHz without any issues, 930MHz seemed to be my limit.
I did get some heat sync’s for it though, not sure if they are needed, but they look kind of cool!
I’ve ordered a 512MB Pi, and my current one is a rev1 version with the Hynix RAM.
So I’m hoping that I can overclock to 900MHz and this time speed up the RAM etc. without overvolting.

I’m really hoping someone writes a cpu scaling module.

I figure this is highly unlikely, but this isn’t “THE Gavin” is it? The one who was teaching ARM assembler at computer camp many years ago?
Or maybe that should be who was ARM assembler ;-)

I’ve ordered a 512MB Pi, and my current one is a rev1 version with the Hynix RAM.
So I’m hoping that I can overclock to 900MHz and this time speed up the RAM etc. without overvolting.

Can you let us know how this works out? (This is quite a change from the past when we had to wait years to get an upgrade like this in our hardware…)

I figure this is highly unlikely, but this isn’t “THE Gavin” is it? The one who was teaching ARM assembler at computer camp many years ago?

Unfortunately not! The only assembler I’ve done was Z80! I stick to BBC Basic/Toolbox stuff and Xcode/Cocoa/Objective-C these days…

Gavin: It would be great to get him back on the scene….I’ve tried to contact him, with no luck :-(
I’ve just got my new pi, but it doesn’t boot at all using the SD card I have for RISC OS, so I’m downloading the latest debian image and going to try that.
Just get the PWR Led red and that’s it :-(
It works fine with Linux, just dies with RISCOS :-(…. More digging needed I think

It looks like my v1 Pi supports my super duper SD card but the latest Pi doesn’t :-(

Well at least I’ve got RISC OS running with 384MB which is nice :-D

As far as overclocking goes, I can only get to 800MHz and be stable, however I have sdram_freq and core_freq set to 450 and it seems to be stable.
Which it wasn’t on the v1 Pi, so it looks like the Samsung memory is better than the Hynix.
I maybe able to get 900MHz stable again once the artic silver sets properly, as it does boot at 900 – it just overheats quickly.
I’ll run some benchmarks once it’s all tweaked and settled.

UPDATE: 900MHz seems a no-go for me, however I’ve got 850MHz stable and with memphis on boot and the memory tweaks I’m more than happy.

CPUSetup

Would this be an appropriate place for things like clock speed, voltage settings, memory split between CPU & GPU etc. to go, do you think? I could see it making sense in here rather than as a separate plug-in, or just leaving people to edit their config.txt file.

It might be. We should probably avoid putting things in config.txt as much as possible, because that will interact in dual-boot scenarios. It might also be good to keep the plugin useful on non-RPi platforms like OMAP – some settings will be common and some will be different.

Firmware memory split is awkward, because it interacts with both RISC OS and Linux upgrading the firmware files. And there may not be enough space in the boot partition to keep a full set of start.elfs.

And there may not be enough space in the boot partition to keep a full set of start.elfs.

Is it important that the full set is there?

As long as there is a known good version always available on the DOS partition, for repairs, everything else could live in the plug-in’s folder.

(P.S. – to Theo any luck with Finch?)

things like clock speed

@Andrew

If you think it would be any use to you, you are welcome to have the source, etc, of my CPUSpeed app and plug-in. However, it is written in C + OSLib, while I think CPUSetup is in BASIC.

Thanks Chris, you’re right it is written in BASIC, it’s all I know. Presumably it just has to make changes to the config.txt file though, doesn’t it, which should be relatively straight forward once I look up what changes need to be made.

The bigger question is whether people think this sort of think should be in there?

For as much as possible, we probably want to using the VideoCore messaging protocol rather than config.txt – so we don’t mess with the Linux options. If we can get that into BCMSupport then that will provide an API. For CPU/GPU split, that’s just been changed from umpteen start.elf variants to a config.txt setting – if that works, we’ll need to set that in config.txt as there’s no other interface.

Jess: I’ve had my hands very full recently, so no time to look at Finch, sorry.

It may have ‘just changed’ but it doesn’t work yet – with the new firmware the Pi just sits there with the red LED lit and does nothing. It doesn’t even flash the green LED which shows that bootcode.bin is running.

It has worked for me, eventually.
I found I needed fixup/dat and bootcode/bin as well as start/elf for it to work.
Didn’t find any problems booting each time either.