Release Beta Test: Upcoming (HF5) Firmware Image BETA 3

[skeezix]

I can set mmenu to 'on leave, set cpu to 800' and it works no problem. So that does bring up the big question.. you can clock to 800 stable, right?


I removed the tiny little bit of delay. Switched things around, so it wasn't necessary anymore, was just somethign I left in for a bit.


jeff

 

[ZXDunny]

I can set mmenu to 'on leave, set cpu to 800' and it works no problem. So that does bring up the big question.. you can clock to 800 stable, right?


I removed the tiny little bit of delay. Switched things around, so it wasn't necessary anymore, was just somethign I left in for a bit.


jeff

Jeff, just a quick (sort of) off-topic question: Are you responsible for the Atari ST emulator on the GP2X?


D.

 

[TJFBryant]

I had recently installed hotfix 5 beta 2 ... and for some reason. Some games (not all) but some... literally have no volume or sound at all.


With the games that do have audio you can distinctly hear the speakers turn on with a blip of white noise prior to game loading....and it works fine.


Games like Alienblaster, and Ken's Labrinth, psx4all, atari7800 and a few others have no audio... no matter the volume change.


Has this happened to anyone else... and does anyone think it has to do with Hotfix 5...?


Personally I don't believe it does.... but what else would cause this software issue in some games and apps over others. If it was the HF5 wouldn't it effect all apps and programs?

 

[notaz]

Hm haven't seen that one, does it help? I'll probably cherry pick this from mainline to retain attribution though, instead of using your version.

IIRC I had to do some changes to the function (adapt to kernel internal interface changes in time). But maybe you can work it out someway pretty, like do a set of commits retaining attribution, then one commit by you or me (I dont care for attribution that much, but whatever) doing the interface fixing.


Anyhows the randomly found-out workaround codepath is as follows:


1. Try to read big block (2 or more sectors)


2. Get spurious read error due to concurrent write on the other channel. (Why? - resolving this would be the real bug fix)


3. New code tries to find out what sector failed by reading the big block 1 sector at a time (old 2.6.27 code marked lots of sectors as bad at this point)


4. No sector fails (why does this work?, dunno but works), and code returns with success (as the re-reading is done with a flag and a goto to retry point - so it can also normally exit with success.)

This workaround works, applied related mainline patches, thanks!


ED: you'll need to do new beta soon, this might fix some nonworking cards too.

 

[Zenbot]

I can set mmenu to 'on leave, set cpu to 800' and it works no problem. So that does bring up the big question.. you can clock to 800 stable, right?


I removed the tiny little bit of delay. Switched things around, so it wasn't necessary anymore, was just somethign I left in for a bit.


jeff

I can apparently clock to 800 for individual apps, so as far as I know, yes. ED was asking this, too, but bear with me as I'm a rather non-technical user: Do some Pandoras have different max clock speeds? How can I tell what the optimum speed is?

 

[Eridger]

I can set mmenu to 'on leave, set cpu to 800' and it works no problem. So that does bring up the big question.. you can clock to 800 stable, right?


I removed the tiny little bit of delay. Switched things around, so it wasn't necessary anymore, was just somethign I left in for a bit.


jeff

I can apparently clock to 800 for individual apps, so as far as I know, yes. ED was asking this, too, but bear with me as I'm a rather non-technical user: Do some Pandoras have different max clock speeds? How can I tell what the optimum speed is?

Clock speeds for the Pandora are absolutely the same: 500MHz out of the shop, 600MHz with OPP5. Anything beyond that is overclocking, which means pushing the CPU beyond its specification. Not every chip is the same, even if it is made my a machine. Different quality levels in the material of each CPU means the results of overclocking vary wildly. The Pandora is the only device I've seen that typically can overclock to 2x the device's preset limit*. But of course that limit can't be reached by some Pandoras for the reasons I've just said- differences in build and material quality. Some can do 1.15GHz, some can do 800MHz. From what I've read, most devices can reach around 1GHz, but that's absolutely not a garuantee.


*TI states that the OMAP3530 is set to deliver 720MHz standard according to Wikipedia. I think OPT may be underclocking the devices, or the specs have changed for the OMAP3530 ("Hey Bob! These chips run way better than I thought!"). Either way, this is one hell of an efficient, durable chip.


Edit: Finding an 'optimum' or maximum speed for the Pandora is a guessing game. The best way to go about it is to up the processor speed by 100MHz increments and play some emulators in between. I'd say the N64 and PSx emulators right now use most of the features of the CPU, but it's your choice. The idea is to test the stability of the new clock speed. Wait until the system locks up or kernel panics, and go back to the last stable clock speed. Up by 50MHz increments from that stable speed (if you want to really stress the CPU. I don't recommend it). Keep halving that increment until you don't see any real results. That is your maximum speed at OPP3.


If you feel comfortable with it, go to OPP5 (I don't know the exact command). Now you're overvolting. Overvolting is sending a higher-than-normal current through your CPU to make up for the 'noise' made by overclocking. Think of that 'noise' as that little hissing sound you get when your listening to something through crappy headphones. The audio you want to hear is slightly louder than the hiss. When you turn the volume up (overclocking), the audio you want to hear goes up, but so does the hissing noise. That hiss can overpower the noise until it all sounds the same. Overvolting would be like using an equalizer to amplify the sound you want to hear- it works, but the hiss will just drown out the audio later.


Anyways, once you overvolt to OPP5, repeat the steps I mentioned earlier. You should be ready to go then. Just... don't overclock unless you really need to. It's not healthy for a CPU.


Oh, and it voids your warranty if you go over 600MHz.

 

[Zenbot]

Ah. That explains a lot. And much thanks for the heads up on warranty.


Soooo, what I'm hearing is that most of the bugs I reported are really just user error.


Right, carry on then!

 

[EvilDragon]

This workaround works, applied related mainline patches, thanks!


ED: you'll need to do new beta soon, this might fix some nonworking cards too.

Awesome


I got two cards that I have to insert a few times before they start working, might be related to this as well


Probably gonna spit out a new version tonight, just have to do some fixes on my CPU Script as well

 

[silver]

Hm haven't seen that one, does it help? I'll probably cherry pick this from mainline to retain attribution though, instead of using your version.

IIRC I had to do some changes to the function (adapt to kernel internal interface changes in time). But maybe you can work it out someway pretty, like do a set of commits retaining attribution, then one commit by you or me (I dont care for attribution that much, but whatever) doing the interface fixing.


Anyhows the randomly found-out workaround codepath is as follows:


1. Try to read big block (2 or more sectors)


2. Get spurious read error due to concurrent write on the other channel. (Why? - resolving this would be the real bug fix)


3. New code tries to find out what sector failed by reading the big block 1 sector at a time (old 2.6.27 code marked lots of sectors as bad at this point)


4. No sector fails (why does this work?, dunno but works), and code returns with success (as the re-reading is done with a flag and a goto to retry point - so it can also normally exit with success.)

This workaround works, applied related mainline patches, thanks!


ED: you'll need to do new beta soon, this might fix some nonworking cards too.

Great that this is fixed - was having lots of copy errors I could not attribute to anything (OS boots from large SD, so tend to copy lots).


It does look like it must murder performance though - it must be re-reading every large block sector-by-sector?


Also, speaking on SD's: Have also discovered (badly - reformatted 26GB of data) that the pandora will let /dev/mmcblk0p1 refer to EITHER SD slot, not always the left one.Anyone else had mmcblk0pX map to the right SD slot? Instructions on wiki imply it's fixed. Trying to see if I can always repeat it - it's happenened a few times - might be down to swapping the same SD from slot to slot, or from booting OS from SD...

 

[fr4n]

Anyone else had mmcblk0pX map to the right SD slot?

This happened to me the other day when I inserted the right SD card first. When I unmounted both and inserted the left one first the mappings fixed themselves.


Edit: This was on HF5 Beta 2.

 

[EvilDragon]

The Linux MMC driver maps to /dev/mmcblk0 whatever card is inserted first, it's not fixed to a slot.


If you give your card a name (i.e. Pandora1, etc.), then it will use the name of the card as mountpoint and therefore will always have the same mountpoint per card, regardless where you put it in.

 

[fr4n]

If you give your card a name (i.e. Pandora1, etc.), then it will use the name of the card as mountpoint and therefore will always have the same mountpoint per card, regardless where you put it in.

As in /media/NameOfMyCard?

 

[sebt3]

As in /media/NameOfMyCard?

If NameOfMyCard? is the name of your card, then yes. But I question the fact that the question mark (?) is actually valid as in a card name...

 

[fr4n]

If NameOfMyCard? is the name of your card, then yes. But I question the fact that the question mark (?) is actually valid as in a card name...

Sorry, that should have been NameOfMyCard\?

 

[skeezix]

I can set mmenu to 'on leave, set cpu to 800' and it works no problem. So that does bring up the big question.. you can clock to 800 stable, right?


I removed the tiny little bit of delay. Switched things around, so it wasn't necessary anymore, was just somethign I left in for a bit.


jeff

Jeff, just a quick (sort of) off-topic question: Are you responsible for the Atari ST emulator on the GP2X?


D.

Yep, that'd be me. OutCaST / CaSTaway (gp32, gp2x/wiz/caanoo, PSP, Palm, etc


jeff

 

[richiz]

wow new mmenu looks great. My wifi is working fine.


Havent noticed too much of a diff yet. when in mmenu i still cant toggle my wifi due to password manager though. would be great if it were possible as i hate xfc

 

[ardje]

I this error is repeatable. slot one to two gives an error, slot two to one works. I ve tried it with different target cards, problem persists.

Yo thanks! I was thinking I've bought yet again a bad sd-card. I was rsyncing from slot 1 to slot 2 and then it started getting bad.


But no... it was just the driver :-(.


(Sometimes I get the idea that people blame the sd-card while the driver might be the cullprit. On my HTC-dream filesystem corruption always happened upon reboot.)


And notaz, thanks for immediately fixing this ;-). And Urjaman, thanks for discovering the fix .

 

[silver]

The Linux MMC driver maps to /dev/mmcblk0 whatever card is inserted first, it's not fixed to a slot.


If you give your card a name (i.e. Pandora1, etc.), then it will use the name of the card as mountpoint and therefore will always have the same mountpoint per card, regardless where you put it in.

Thanks for clarity. I suspect the mix of some named/some un-named and card swapping lead to confusion. Although it may be worth highlighting on the wiki - I'm pretty sure the instructions for installing Linux to a SD on the wiki specifically state that /dev/mmcblk0p1 is the one to use for the left hand slot, it's what caught me out - even if /media/myname is the always the same...

 

[urjaman]

It does look like it must murder performance though - it must be re-reading every large block sector-by-sector?

In my dd trials it seems to be happening as a some form of race condition, eg. I only get the error messages to dmesg every so often (cant recall, something between twice per sec to once per two secs would be my IIRC), not as a constant flood (what it would be if every read failed).

 

[fanoush]

The Linux MMC driver maps to /dev/mmcblk0 whatever card is inserted first, it's not fixed to a slot.


If you give your card a name (i.e. Pandora1, etc.), then it will use the name of the card as mountpoint and therefore will always have the same mountpoint per card, regardless where you put it in.

Yes, sadly this by design. MMC slots are removable just like usb devices. IMO this was wrong design choice because only card is removed, not the slot. Imagine your cdrom or floppy device node vanishing when you eject cd or floppy.


However it is easy to patch in kernel, see https://bugs.maemo.org/show_bug.cgi?id=2747 With Nokia tablets it is even worse as they decided to fake device node names in userspace to keep the names 'consistent'.