RISC OS Build On Touchbook

...putting the OMAP into a deep sleep state instead of turning it off entirely…

If this is implemented some time in the future, am I right in thinking the RTC would continue counting? If so, this RTC mod wouldn’t be so relevant for RISC OS users.

And would it also be appropriate to suggest the deep sleep in this bug report? [Edit: maybe already referred to but the poster is “not sure about [their] kernel”.]

This should do that for you, though I’ve not tested it on OMAP:

http://www.effarig.co.uk/riscos/download/keymap.zip

There’s a slightly newer (and 32bit safe) version of MouseKey at http://www.mybigideas.co.uk/html/software.php if you need it!

Both of these work fine with the OMAP port, and (as per the included docs) map keys according to the Internal Key Numbers.

As the mouse movement and Sel/Adj are already handled by the trackpad, MouseKey’s use of a ‘trigger’ key will be a little slow in use (however, I’m sure it’s possible to amend the source so no trigger is required). Therefore I’m using KeyMapper.

I’m mapping Adjust to Menu and R.Shift to Adjust. (Also a good idea to map Menu to Adjust, in case you actually do plug a mouse in while the keys are remapped.) Alternatively, mapping key 77 to Menu works with my external USB keyboard, but on the Touch Book, the key marked \ | gives # ~. Is there any way of mapping the keyboard ‘Menu’ or (Touch Book) ‘AI’ keys under RISC OS?

[Edit: I see that AI list Android as using two clicks at the same time to activate the menu. I know that RISC OS can recognise both clicks together, so perhaps what would be useful is remapping this.]

There’s another Touch Book up for auction, if anyone fancies a cheeky bid. (The UK page includes a note about international postage in English.)

It looks as if the AI are moving to support OMAP4 (as discussed on the AI forum).

Trevor, none of the links you provided seem to indicate that AI is working on it. There is just some discussion about the panda board but no discussion about a new product. The pandaboard seems to need modification which is not what AI is working on them selves. Still i would love to see an OMAP4 version of their product :-)

...none of the links you provided seem to indicate that AI is working on it.

Well perhaps I’m jumping to conclusions. But there are references to Pandaboard on their source code page.

[Edit: Previous OMAP4 stuff was AFAIK outside of AI. But the Panda stuff is from Gregoire.)

Most likely Gregoire has acquired himself a pandaboard.. The availability of OMAP4 processors is not yet such that a company like AI can start with producing boards anyway. Even the pandaboards have a back-order of at least 1000. which makes waiting periods of 2 to 3 months quite ‘normal’ with the pandaboard. Let’s hope you’re right and we will see :-)

Following a full Touch Book charge, I’ve experienced the following – in connection with changing mode because I somehow had an issue with icon display in Andrew Conroy’s AlignEx (which he’s aware of and mysteriously seems to have disappeared). Note – unfortunately I’ve not been able to reliably repeat these, but will keep working at it.

• 32-thousand colour mode with all-black mouse pointer, after changing from 640×480 (I could have taken a screen grab but as the pointer is usually omitted, I didn’t think it’d be worth it – that’s what mobile phone cameras are for, I hear you say… but I rarely use it and wouldn’t know where to find the correct cables to upload, so it’d be a camera photo of a mobile phone photo of a screen)
  • Andrew suggested that it may possibly be a case of the palette not being copied properly between modes
• Power-off on changing screen resolution, although the TB v1 isn’t known for its excellence in battery circuitry!
  • I’ll see if I can repeat this with it plugged in to the mains

Power-off on changing screen resolution, although the TB v1 isn’t known for its excellence in battery circuitry!

While spending the past few days trying to measure the effect of running at different CPU speeds, I’ve discovered two things related to my touchbook:

• The current tablet battery charging scheme RISC OS uses (which is basically just “leave it on auto”) isn’t good enough to actually recharge the battery. In fact the voltage very slowly drops over time, even with the system in a low power mode (sceeen off, audio off, CPU @ 125MHz).
• The battery voltage drops significantly whenever the battery is under load. Having the screen on seems to cause a drop of around 0.5V, which is quite significant, considering that at best the battery will start at about 4.1V (at zero load), and the system will shut down once it hits 2.7V.

Of course it’s a bit hard to tell if these problems are just problems with my touchbook (e.g. dodgy batteries), or general design flaws (e.g. at some point I found a page on the AI wiki with instructions on how to boost the performance of the tablet battery charging circuit), or perhaps things that can be fixed through better software (Maybe there’s some power-hungry hardware which we should be turning off, or maybe software-controlled battery charging can cope better with bad batteries).

In a day or two I’ll hopefully have an answer to the question of whether implementing Portable_Speed will help or hurt battery life. Once I’ve sorted that out I’ll release the first update to the Portable module, and a copy of my battery monitoring program, so I can get some battery life/charging results from other people’s touchbooks. Plus of course the program will work as a stopgap !BatMgr until I get round to integrating everything with the Portable module.

[...] trying to measure the effect of running at different CPU speeds, I’ve discovered two things related to my touchbook: [...]

That’d explain why mine died so unexpectedly the other day!

general design flaws (e.g. at some point I found a page on the AI wiki with instructions on how to boost the performance of the tablet battery charging circuit)

This fix? I’ve not tried it yet. If I do, then I guess I could leave enough slack in the wire to cut it and comfortably add a switch in the future.

I’ll release the first update to the Portable module, and a copy of my battery monitoring program, so I can get some battery life/charging results from other people’s touchbooks.

I’ll look forward to being able to provide some meaningful feedback for you on that.

This fix?

Yeah, that’s the one. I might have to give it a go some time, although the fact that they say that it only helps “a little bit” doesn’t fill me with confidence!

Over here you can find a copy of my battery monitoring program. It has a few different features, controlled by the variables at the start of the program:

• How often to update the iconbar icon/log file
• Whether to monitor the tablet battery (enabled by default)
• Whether to monitor the keyboard battery (enabled by default)
• Whether to monitor Portable_Speed/Portable_Idle (requires a debug build of the Portable module, so disabled by default)
• Whether to monitor power consumption using the beagleboard method (disabled, since it doesn’t seem to work on touchbooks, and doesn’t seem to work properly on BB-xM’s either)
• Whether to log everything to a file (disabled)

Assuming the keyboard’s conected, and the relevant monitoring options are enabled, the icon bar icon will show two values. The first will be the tablet battery voltage. The second value depends on whether the keyboard battery fuel gauge IC has had time to calibrate or not. If the IC is calibrated then it will display the percentage of remaining charge in the keyboard battery. If it isn’t calibrated the nit will just show its voltage. I’m not 100% sure but I think the fuel gauge will only flag itself as calibrated when the battery reaches the almost-empty state. There are a couple of things that can cause the gauge to become uncalibrated, but apart from taking apart the keyboard and unplugging the battery I think the only one you’re likely to see is where it triggers an automatic recalibration once every 32 charge/discharge cycles.

I think the main thing I’m interested in finding out is whether the tablet battery charging actually works or not. So if you can enable the logging and then leave the machine idle for a few hours and send me the log file then that would be great. You may also want to do some tests to see if you’ve got the same problem I have where the battery voltage drops significantly when the screen is on.

A couple more notes:

• Although the icon refreshes on a timer, you can force it to update immediately by Select-clicking it
• Adjust-clicking the icon will kill the program
• Today I fixed a bug in the IIC driver where the RX/TX FIFO’s weren’t being flushed after an IIC error. This means that unless you get a new ROM image, if you’re running the program with the keyboard disconnected, then when you (re)connect the keyboard it will report invalid values for the keyboard battery status. Although you’d probably want to get a new ROM image anyway, since it’ll contain my Portable_Speed stuff, and a fix for that screen shimmering bug you spotted.

battery monitoring program

Great. I’ve run it and will have a couple of logs to send you later on.

You may also want to do some tests to see if you’ve got the same problem I have where the battery voltage drops significantly when the screen is on.

This is presumably without being wired up to the mains.

Whether to monitor Portable_Speed/Portable_Idle (requires a debug build of the Portable module, so disabled by default)

Now I’ve built the ROM (untested but at least created this time), do I enable debugging by changing something here and building that component alone? And I then *RMKill and *RMLoad the replacement PortableHAL module?

You’ll need to set DebugSpeed to ‘true’ in PortableHAL.s.GetAll. Then it’s up to you whether you do a regular ROM build (i.e. ‘Make ROM’, ‘Install ROM’, ‘Join ROM’) or just softload a replacement PortableHAL (The ‘MkSA’ script should hopefully build a suitable version of the module for softloading, but I don’t think I’ve ever actually tried it)

(The ‘MkSA’ script should hopefully build a suitable version of the module for softloading, but I don’t think I’ve ever actually tried it)

do mkdir -p o.CortexA8._Messages_
create o.CortexA8._Messages_.Portable
IfThere LocalRes:Messages Then copy  LocalRes:Messages o.CortexA8._Messages_.Portable FR~C~V~N
IfThere LocalRes:CmdHelp Then tokencheck LocalRes:CmdHelp
IfThere LocalRes:CmdHelp Then print LocalRes:CmdHelp { >> o.CortexA8._Messages_.Portable }
do mkdir -p o.CortexA8
objasm -Stamp -quit -depend !Depend    -o o.CortexA8.PortableSA GetAll.s -PD "standalone SETL {TRUE}" -PD "MergedMsgs SETS \"o.CortexA8._Messages_.Portable\""
ARM AOF Macro Assembler 3.32 (Acorn Computers Ltd) [20 May 2010]
do mkdir -p rm.CortexA8
link -rmf -o rm.CortexA8.PortableSA o.CortexA8.PortableSA 
modsqz -f  rm.CortexA8.PortableSA
modsqz: 'rm.CortexA8.PortableSA' is not a moduleAMU: *** exit (1) ***

AMU: *** 'standalone' not re-made because of errors ***

(Yes, I remembered to do the grep fixes first.)

modsqz: ’rm.CortexA8.PortableSA’ is not a module

Interesting… so what is rm.CortexA8.PortableSA? I just tried the MkSA script myself, and it seemed to work fine.

Also thanks for the logs you’ve sent me so far. The good news is that your tablet battery is charging, but the bad news is that the keyboard battery fuel gauge doesn’t seem to know how much charge is left in the battery. My theory is that because the tablet battery always dies first, the fuel gauge never gets to see the keyboard battery on a low enough charge for it to start giving accurate charge measurements. I’ll do some experimentation over the next few days to try and work out whether that’s true or not.

Also I’ve just applied the charging fix and apart from being easier than I expected it looks like it’s solved my battery charging problems. I’ll have to leave it overnight to be sure though.

It sounds like some corruption has sneaked in during the link stage there. No idea how. It’d be interesting to have a copy of that file to look at.

Also what version of modsqz have you got installed?

[…] the keyboard battery fuel gauge doesn’t seem to know how much charge is left in the battery.

Under AIOS it seems to show mainly either 25/50/75/100% for the keyboard battery, which seems broadly consistent with not having much info to go on!

It’d be interesting to have a copy of that file to look at. Also what version of modsqz have you got installed?

I’ve sent that off, for when you find the time to have a peek. modsqz should be the ‘Thu Mar 17 16:34:03 2011’ version as the sources I’m using came from the ‘2011-03-21 03:41:12’ tarball. It doesn’t seem to report a version number, but I’ve included it in the email for reference.

Something odd happened because the module is fine. The error it should have reported is that it’s too small to squeeze. In fact, that’s exactly what the version of squeeze reported when I tried it with your module. Odd indeed.

Thanks so much for looking inro this.

Something odd happened because the module is fine.

I agree. I’ve just tried again and now have:

Portable: standalone module built

(Issue followed up in Problems building OMAP ROM.)

Whether to monitor Portable_Speed/Portable_Idle (requires a debug build of the Portable module, so disabled by default)

I have 4 (short) log files:

1. bcilog_std_speed_false
2. bcilog_debug_speed_false
3. bcilog_std_speed_true
4. bcilog_debug_speed_true

(3) and (4) have additional output for FastTime, SlowTime, ChangeTime, FastIdle, SlowIdle. There seem to be no dummy values contained in (3). Shall I generate and send any more logs for the moment (without the battery mod, which I’ve not yet attempted)? I’ll still verify the voltage with the screen on/off, as previously mentioned.

There seem to be no dummy values contained in (3).

Yes, that’s normal. bcimon wasn’t designed to cope properly with having Portable_Speed logging enabled but a non-debug version of the Portable module loaded (I’m surprised I even chose to use the X form of the debug SWI!)

Shall I generate and send any more logs for the moment?

You can send me a copy of log 4 if you want, but I don’t think there are any extra logs that I need, thanks.

(without the battery mod, which I’ve not yet attempted)

A note about this – if you’re wondering where to get hold of the recommended 28 AWG wire, try checking any old IDE cables, serial ribbon cables, etc. I reused the remains of the 40-pin IDE cable that I’d butchered for connecting up a serial cable. The only downside I found was because it came from a ribbon, the wire wasn’t round enough for me to pass it through the JTAG holes, so I had to go round the edge of the board instead.

Also what version of modsqz have you got installed?

[…] modsqz should be the ‘Thu Mar 17 16:34:03 2011’ version […]

How does this compare with the modsqz source?