Beagleboard Xm

The only reason I tried soldering the top side as well was because the bottom joint didn’t seem to provide much stability – a gentle poke was all that was needed to push the battery to one side.

The question, then, is whether you heated the joint up enough for the solder to flow properly. If you did, the battery’s tags shouldn’t move in the holes, and that’s as good as you can get. We all have to realise that the battery chosen for the XM has poor stiffness, it’s inherent in the design of the battery, and there’s nothing we as users can do about it. Just don’t subject the board to huge impact after the battery has been soldered in :-)

But if you (or anyone else) think (or know!) that people might have done this, then now is the time to speak up! It would be a bit of a pain from the user’s perspective, but we can always make the RTC battery charging fully configurable.

Well, I don’t know what the situation is with the xM, but certainly different IGEP users seem to be using all sorts of components! I don’t have time to check the hardware ref. manual right now to see what it recommends, but anyway the reality is that different components are going in. I think it’s another example of something that could do with being passed as a command line parameter when RISC OS starts up.

I’m worried by some of the recent comments about batteries and charging them.

One thing: there’s no such thing as a 3 V MiMH battery – it’s impossible. The chemistry of NiMH means that they come in increments of 1.2 V. Anything else is impossible. (You’ve heard of “physically impossible” – this one is “chemically impossible”!)

But mainly: traditionally, rechargeable RTC/CMOS batteries have been on permanent trickle charge. The current is fixed by design; it’s high enough to charge the battery for all reasonable on and off times, and it’s low enough to not damage the battery. Do the BB and BBXM have fixed or variable charge currents? I can’t access the schematics right now, but I would be surprised if there were any choice of current – it would be the first time I’ve ever seen it.

If the current is variable, you’re into a charge manager, which is a whole new ball game, as they say.

I would be surprised if it were anything other than the traditional model: one current fits all, permanently on. It’s simple and it works well.

The question, then, is whether you heated the joint up enough for the solder to flow properly. If you did, the battery’s tags shouldn’t move in the holes, and that’s as good as you can get.

The solder joints looked good enough, I think I was just hoping for a little more stiffness from the battery itself.

Well, I don’t know what the situation is with the xM, but certainly different IGEP users seem to be using all sorts of components!

OK, that’s good enough for me. Now onto the next question – where do people think the best place is to store this setting? (Battery charging needs to be restarted each time the machine turns on)

• We could store it in the 8-ish bytes of battery-backed CMOS RAM in the TPS (but there’s no guarantee that Linux won’t inadvertantly overwrite it, or corrupt the setting without triggering a checksum failure)
• Or we could store it in RISC OS’s CMOS RAM (once we have it – which sounds like it could be soon!)
• Or we could get u-boot to pass the setting on the command line at startup (not particularly user-friendly, especially since SDCreate is designed to hide the boot scripts from the user)
• Or we could resort to only having it set as part of the boot sequence (not so convenient for someone like me who typically uses the same USB stick with three different machines! although since only one of them has an RTC battery fitted, the battery detection code should make sure that only the machine with the battery will get the charger enabled)

Do the BB and BBXM have fixed or variable charge currents? I can’t access the schematics right now, but I would be surprised if there were any choice of current – it would be the first time I’ve ever seen it.

There are four choices of charging current, between 25mA and 100mA IIRC. There are also four voltages to choose from – although I can’t remember whether the choice affects the charging voltage, end-of-charge voltage, or both. I think the settings ranged between 2.5V and 3.2V. And since you can monitor the voltage directly using the ADC you can also implement your own cut-off voltage if none of the builtin ones are suitable.

We could easily go with the lowest common denominator, but since I’m not battery expert I’m not sure what the danger would be if someone had fitted a non-rechargeable battery instead of a rechargeable one.

There are four choices of charging current, between 25mA and 100mA IIRC.

Woa. Even 25 mA is way too much for a clock battery. Think in terms of 1 mA maximum.

I have to check out the schematics.

Yeah, maybe I’m getting confused with microamps! Just search for BB_CFG in the TPS65950 TRM :)

Just search for BB_CFG in the TPS65950 TRM :)

Not found :(

Just search for BB_CFG in the TPS65950 TRM :)

Not found :(

Maybe that term has been removed in the recent revision. But try section 8 ‘Battery Interface’ (from pg.115) – It refers to a 0.415mA to 1mA range for consumption with VAC/VBUS accessory supply mode. There are plenty of tables to refer to – so I hope the relevant info is there!

Yes, I’m looking at table 4-18, which lists typical charge currents in the 25 uA to 1 mA region. Those are plausible.

One thing for sure: NEVER attempt to charge a primary (non-rechargeable) battery. That can only lead to sadness when the battery explodes.

...table 4-18…

In my haste, I managed to miss that section!

I’m worried by some of the recent comments about batteries and charging them. One thing: there’s no such thing as a 3 V MiMH battery

Of course you’re right, Dave. Sorry for my sloppy writing. I’m not a battery expert; I was really just trying to illustrate the point that different people might have installed different battery backup solutions on their boards, not necessarily following the HW manual’s advice.

On that note, I’ve now checked the IGEPv2 (Rev. c) HW ref. manual, and it does recommend a particular cell (or capacitor). The cell is a nominal 3V lithium (not NiMH ;) job. This doesn’t change the fact that I know from reading the IGEP forums that people are using different solutions that (apparently) require different setups of the BB_CFG register. So I think it would be a good idea to store this information somewhere rather than hard-code it.

Perhaps, Jeffrey, a compromise solution is to opt for the u-boot parameter method, but make the parameters optional and default to the values recommended in each board’s HW ref. manual? Alternatively, if we get CMOS implemented soon, that seems like the obvious choice. (Not that u-boot parameters are even an option at present, right?)

As an aside, the details of the BB_CFG register in the latest (I believe) TPS TRM (swcu050f) are on page 328. The charging currents are between 25uA and 1mA; the voltages 2.5V to 3.2V.

(Not that u-boot parameters are even an option at present, right?)

And on that note...

What happened to reading the u-boot parameters? It sounds like something with potential for a fair few long-term benefits. Are there any current physical barriers to implementation, or is it just waiting for a the developer with spare time to add extra code to the start of the kernel?

What happened to reading the u-boot parameters? It sounds like something with potential for a fair few long-term benefits. Are there any current physical barriers to implementation, or is it just waiting for a the developer with spare time to add extra code to the start of the kernel?

No physical barriers per se; it’s more down to a lack of spare time/constantly shifting priorities. Apart from modifying the HAL/kernel we’d also have to make sure that the ROM images are packaged as u-boot uImages – which would (most likely) involve adding an extra step onto the end of the ROM build process, adding mkimage (and its source) to CVS, modifying SDCreate, etc.

Also if we’re going to do anything that requires a parameter to be passed as a boot parameter then we have to think about how people are going to be able to specify those parameters. At first I was a bit worried about this, but then I remembered that the FrontEnd module allows users to save their settings – so we could just have an extra box in SDCreate for entering boot parameters, and make SDCreate generate an appropriate boot script instead of using pre-generated ones. As long as users remember to save any custom settings they used then those settings should still be there the next time they go to build a new SD card.

...next time they go to build a new SD card.

Does the entire SD card need rebuilding each time? Can’t the ‘RISCOS’ ROM image file just be replaced for subsequent builds.

It depends what machine type it is – for the TouchBook you’ll need to rerun SDCreate (or run mkimage manually), since the ROM image gets converted to a uImage. For other machine types it should just be a case of replacing the ROM file.

...Wait. So the ROM image already gets converted to a uImage in the process of building the SD card for the TouchBook? Wasn’t that the main barrier you mentioned above to reading the u-boot parameters?

Could the SD cards for other machines like raw BeagleBoards be modified to work in this way too? Then, assuming that everyone uses SDCreate to update their ROMs (I would hope that any other way is deprecated by now), that hurdle could be jumped without worrying about modifying CVS. (CVS would be a more efficient way of doing it, but you have to be pragmatic about your spare time.)

Of course, then the HAL still needs modifying, which will probably need a new API to read the parameters, but it would still be a start.

Could the SD cards for other machines like raw BeagleBoards be modified to work in this way too?

Yes. But instead of costing me time it would end up inconveniencing users by forcing them to download and install mkimage when they first use the new version of SDCreate, and limiting them to only being able to replace existing ROM images using a machine with mkimage installed (e.g. Windows users may have difficulty creating cards manually).

Plus it would have the danger of making ROM builds a little bit more tedious since I’d have to run mkimage manually or recreate the full image using SDCreate for each new ROM.

Do others get any sound from their BB? Mine’s totally mute, no beep, nothing. There doesn’t seem to be any obvious problem but of course I could have damaged my audio cables or the onboard sockets. It’s a rather snug fit and for some reason the 3.5 mm plugs specified in the manual don’t seem to make a very good connection. So either it’s got something to do with RISC OS needing something or I’ll have to disassemble everything. Don’t fancy that really.

Sound works fine for me. The plugs I’m using aren’t a particularly tight fit, but they do need a bit of a push to click into place.

I don’t think the signal the BB produces is very powerful, so you might want to make sure you’re using powered speakers. And you might also want to check in the sound setup configure plugin that you haven’t got the headphone output muted! (Although that setting shouldn’t affect the startup beep)

Mm sounds like a hardware problem then. Blast. Guess it’ll have to wait until my RTC battery arrives as the board will have to come out then anyway.

Argh just bought a wireless mouse that doesn’t work at all with my BB. Unsurprisingly it does work perfectly with SWMBO’s laptop which at least allowed me to reclaim the other mouse. Thought wireless or not wouldn’t make any difference? For what it’s worth: it’s a Microsoft wireless 1000. Any ideas or hpeless case?

Whether the mouse is wireless or not shouldn’t make a difference. It might be that there’s a bug in the USB drivers, or it might be that there’s a bug in the mouse itself (There are probably thousands of USB devices which advertise themselves incorrectly or aren’t properly spec compliant).

Can you plug the mouse into the BB, run *usbdevices, then *usbdevinfo X (where ‘X’ is the device number of the mouse) and let me know the vendor & product IDs? Then I can check if any fixes for that mouse have been made to any of the BSD/Linux USB stacks.

The vendor ID is 045E Product ID 0745

Full list:

• USB release 0200
• device class 00
• dev subclass 00
• dev protocol 00
• max packet size 40
• vendor ID 045E
• prod ID 0745
• dev ID 0656
• manufacturer Microsoft
• product Microsoft 2.4 GHz Transceiver v.8.0
• serial num of configs 1

Sounds like:

045e Microsoft Corp.; 0745 Nano Transceiver v1.0 for Bluetooth

Sound works fine for me. The plugs I’m using aren’t a particularly tight fit, but they do need a bit of a push to click into place.

Sound now working. Almost had to force the jack in until it clicked into place. Most definitely nothing I’d want to do often. But then who knows, probably easier next time.