Mobilepro 900c and linux is possible?

yeah, thats what i thought too. i'm confused though, because i cant even get the thing's ID by querying 0x08001000. or anything if i try to read the registers at 0x08000000. that is interesting because in the bootloader, you can see references to it.

btw, my bsquare phh does give me back 0x40 as the ID, but in the bootloader it doesnt look like it uses the same register stuff as in the datasheet (except for the ID register and control register 1006/76). why is that? can the OEM configure it so much different? (this is the device iwant to read the nand of)

hey cosmo0

i'll try this with an agere based card later

as for jtag... i dont think its the ram... i cant even write into the registers, PC or anything. doesnt look like memory timing to me.
exams are over. but thanks

oh, 1 question, what's at 0x13080000?

Whew! after 2 days, its done. Built a clone of my j7xx icewm userland for xscale, and made some 900c specific changes. This image uses a tweaked kernel config and because of this, there are numerous modules for wifi/network cards and other odds and ends.

Firefox *still* wont start in under 18 minutes, but whatever, thats another issue for down the road. Mini-browser and dillo should tide you all over for now.

Anyway grab it here: http://devfiles.jlime.com/900c_Henchman_1.0.0-Testing/

Cheers.

You probably need to unlock the DOC with a pasword - this should be somewhere in the bootloader code.

Anyway - windows uses a normal TrueFFS driver according to the registry, so I doubt the OEM did much about the rom itself.


I found a duscussion the 'ROM unlocker' at http://forum.xda-developers.com/showthread.php?t=225271

You might want to check that.

cool.

oh btw is that really 18 minutes? wow.. you are so patient that you did time it..





uh, the 900c doesnt have an extended rom... that is just a ppc phone specific thing. on the 900c, you can enter the "internal disk" (the DOC) fine and read it and write to it.

what i meant is that i can't read its control etc registers. i.e. the ones at 0x08001000.

as for my other question - the bsquare phh, why does it use nonstandard register addresses? can the OEM configure the msystems DOC hardware differently? forgive me if this is a silly question but i'm confused.

Edited by cmonex 2007-06-26 9:33 PM

cmonex: It may be that the PHH does not use the standard DOC adressing, but implements Datalights FlashFX on
the DOC in some way - Bsquare is an OEM for Datalight. Then I am out of my depth. See
http://www.bsquare.com/products/driversandmore/flashmediamanagement.asp
for info.

thanks for the tip.

i hope they have some specs somewhere... i really want to dump this nand.


just fyi, the registers it uses to read the flash in the bootloader: 1006/76, 1002, 1020-22-24-26-2A-2C and 1078 (the data is read through 0x08000800, obviously.) only 1006/76 seem to be used the same way as specified in the datasheet

i'm also attaching a register dump (from 0x08001000 to 1100), made while running winCE

i would try the bootloader code just afraid to mess with this without even knowing which register is for what (especially as the read in the bootloader happens when the system starts booting up, for example the control registers are explicitly used to enable the normal mode, etc.)


sorry for the off, maybe it helps with the 900c too, though don't forget it was made by bsquare! they share much of the bootloader and OAL (oem specific hw abstraction layer) code as well!

Edited by cmonex 2007-06-27 2:30 PM




Attachments
----------------
ROM-08001000_0x100.dump (0KB - 8 downloads)

Updated icewm yet again. Many improvements and bug fixes. You now have the ability to log into X as a user, though im still working on perfecting it. Also added a nice wireless configuration utility which can be found in Accessory --> Wifi Setup.

Check the url above often, as i update images quite a bit.

And now a screenshot for the masses.



Cheers.

Wouldn't it be faster to dump the wince trueffs.dll and analyse that? All addressing should be happening there.
Any symbolic Xscale dumper around?

what do you mean by "symbolic xscale dumper"?

my real problem is.. don't expect a stupid driver to use addressing directly and explicitly. you have to dig and dig. also i don't think the OS is trueffs, thats just the userdisk. no? i can be wrong.
anyway as an example,
i looked in the bsquare's trueffs.dll now, if i search for the registers in there, i do find them, but then it just gives me nice BX Rx instructions in the next lines and of course without a debugger no way of knowing what is Rx. good luck tracing that. so you need to read all the 150k code (bsquare's trueffs.dll is 150k).. doesnt seem like a fast method...
(ok of course not *all* of the 150k but still not so fast)


some good news: the 900c's trueffs.dll looks very similar to bsquare's. so they are the same.

Edited by cmonex 2007-06-30 7:07 AM

Hey folks,
I got Linux running too (after I realized by reading through the manuals, that 64 MB CF isn´t actually enough for X and bought a 1 GB CF). I tried Opie and Icewm. And yeah - I´m also impressed of how fast things seem to develop.
I´ve got a question anyway: One of you said earlier here, that the ts-calibration is a problem. Is that still the case?

And if so, is that the reason, why I´m having some difficulties with the TS? (Pointer not always moving, where I want to move it and problems especially in the very upper right corner of the screen.)

Best regards
Jens

Calibration is fine, its the 900/900c to blame. If your 900c is like mine and many many others, everytime the screen is moved/adjusted to a different angle, no matter how slight, it loses calibration. I've taken mine apart completely, cleaned the cable connection, reinserted it etc etc, and the problem still persists. The only solution is to use a usb mouse like i did in ce.net. The only problem with that is usb support is minimal in the early stages of the 900c kernel development. Eventually in time as everything comes together it should be possible.

For the record, mine also has issues with the upper right part of the screen, which happens in both ce.net and linux. So its hardware related.

Cheers.

i've not seen such a 900 ("many 900c's", readjustment does fix it for most of them, sorry to hear it didn't help with yours

Jens: do you have this problem only with linux calibration?

Yes. The calibration in ce.net is just fine. And the upper right corner there also works with almost no problems (so I don´t have problems to close programs and so on).
So I guess it has to do something with Linux?

Hm, so the earlier problems with touchscreen calibration made it unusable, anyone else having probs similar to Jens. I assume you've re-run the calibration app, is it always the same behaviour?

I haven't implemented pressure sensitivity yet, maybe something to do with that? If this problem doesn't go away we may be able to get more idea what's going wrong from the output of xev (logs X events) or I've made 'debugging' versions of the ts driver to output more info on what ts data the kernel receives...

RTFM - I'm downloading icewm Henchman image to give it a try, glad you got the kernel compilation to customise

All I've tried so far with the DOC is reading from physical address 0x08001000 (result 0x40), and reading from 0x8001046 (toggle bit register) returns 0x87/0x83 on succesive reads (oh and I did try putting the 0x08000000 offset into the kernel config, caused a kernel panic )



Interesting question, I wish I knew so I came across references to 0x13000000 in the bootloader asm. The memory region is part of the PXA's Static Chip Select 4, ROM is at CS0 (0x00000000) the DOC at CS2 (0x08000000) the LCD controller at CS3 (0x0c000000), the PCMCIA/CF controllers at weird places in CS2 above the DOC (0x09000000, 0x0a000000) --- hmmm, something interesting is connected there but I have no idea what ?

And I've started building a jtag cable so I can try that out. One thing - I think I forgot to mention the nRESET signal which should connect to pad J13 on the PXA I suspect pin 2 of the 12 pin header is nRESET...