Build Your Own Linux Powered Pda

[Da_Blitz]

This page gives a good guide to the range and size of finger print read modules http://www.fujitsu.com/us/services/edevice...ometricsensors/

notice how small the strip one is

[dproldan]

Don't know if this has been posted on the forums.  it may be of interest to you:

http://www.theinquirer.net/default.aspx?article=32703

[speculatrix]

Don't know if this has been posted on the forums.  it may be of interest to you:

http://www.theinquirer.net/default.aspx?article=32703
[div align=\"right\"][a href=\"index.php?act=findpost&pid=133303\"][{POST_SNAPBACK}][/a][/div]

yes, it's the compulab one already mentioned

[Da_Blitz]

#$!~E@@#$!%$#X D^&$@IK&$%K@&!!!!!!!!!!

as i said that link will follow me to my grave, im supriesd it keeps coming up when there are options like gumstix

i guess it was because its recent news

[speculatrix]

I was reading the RadioScape website and one of their big integrators/OEM manufacturers is Namtai, who appear to build the sort of things we want.
http://www.namtai.com/corpinfo/products.htm

Might be worth putting together a bill of materials and asking them how much they'd charge fo r creatings boards to your specification?

[Da_Blitz]

i would hate to see the costs but i think that reselling the design under a diffrent licsence or selling it to a company such as the gpx32 or gumstix guys may be the way to get the numbers we need

[Ferret-Simpson]

Hmmm. . . I think the Open Source aspect of the PocketPenguin is important, because it will set a standard as well as a reference plat form for open source hardware development. After all, this is the first piece of fully open source computer hardware, right? (I know about the chips being closed. Term used in context.)

We'll have also built the first commercially available TuxPhone. ^^

I'm still looking at the Sharp 4" CG Silicon screen (Same as the 6000) That we already looked at. We'll need a supplier, but it's the best choice I've seen as of yet.

Also, on the point of manufacturing, I think that we can see at least 20 or so of these units in the first batch, which isn't enough for a big commercial sale. That'll push the cost up, but after the first batch is done and the reviews come in, the rest will follow!

RE the conversation with DBHI last night:

Made points of Casing and shielding. Looking at a Laser-Etched Carbon fibre case for strength and weight, with an earth-connected foil shield on back and front of the case. Also aluminium shield on the board itself, similar to the Universal (See the Handhelds.org new wiki Universalhardware page.)

Also made a point that the CPU can ACTUALLY handle 512mb of DDR, and we looked at using 2x2Gb standard DDR chips for a total of 512MB of ram. This of course will almost certainly use less power than the 8 MDDR chips that we'd otherwise need. (MDDR is max 32MB/chip.)

Also looked at the Freescale RFX300-20 chipset fr 3G/GPRS. Am emailing Freescale for more information on this chip: It is Quadband GSM with Class 12 GPRS and about 5 different "Broadband" wireless standards. We need to know if it acts completely as a Serial Modem, because if it does then no 3g stack will be needed and the whole chip can be used straight off. (If only the GSM/GPRS are serial controlled, then we will only have Phone/Narrowband until an Open Source stack is coded or we license a commercial one.)

Finally, on the point of the secondary screen for quick mobile-phone mode reference, We've decided on a 128x128 Nokia-type TFT, which has a very low power requirement, as well as an SPI interface, which will be connected to the onboard FPGA.

Currently, we need to know a Supplier for 2Gb DDR266 chips and prices, As well as for the 4" Sharp CG display mentioned earlier in this thread.

Update on the boot system:

Since the CF slot is 8 Bit ATA mode (To leave the DDR bus alone.), we will not be able to hotswap cards. For this reason the total flash memory will be quite small, in the region of 16-32MB. On this will be a Hardware locked bootloader with a personal encryption system, tied to the internal unique key of the system's iMX chip. This will kexec a 2.6.x kernel (Probably on the CF card) and the operating system. The bootloader will only load a signed OS, and the Drive will be encrypted, so he who steals your PP shall be screwed. Along with the Biometric reader, No one who isn't you can use or resell the PP.

Another function of this is the GSM/GPRS chip. It should be possible to put into the bootloader a function that traces the PDA via the Cellular network whenever an incorrectly signed ROM is loaded, or a SIM card is changed without entering it's details into some form of "Accepted cards" list. And yes, all of this should be configurable etc from GUI for myself and all the other simpletons. ^^

This could also access the Bluetooth/Wifi subsystems and use SMS to send the MAC addresses and names of any local hardware along with the trace data. This would enable the police to locate and recover the penguin safely, by providing them with a big fat arrow saying "CRIMINALS 'R' 'ERE". A happy thought, n'est pas? And yes, this could be set to redirect to one of your own phones, instead of to the police, if you're uncomfortable about possibilities of being traced yourself.

So this leaves as expansion:

2x SD, potentially SDIO sockets.
1x USB480 sockets, for your convenience.
1x Serial Port with JTAG port.
1x Bluetooth, with Serial Port profile etc.
1x HDTV 800x600 port.
Nx ridiculous Audio subsystem I/O.

Anyone got any problems with this?

Current Hardware plan.

Freescale iMX31 ARM CPU with 3D, 2D, Video Accelerator.
Freescale RFX300-20 Quad band 2G 2.5G 3G Cellular Chip.
Sharp 4" CG Silicon Display with Touchpanel, 640x480 with 320x240 support.
UNKNOWN User programmable FPGA as ASIC.
UNKNOWN 512MB (4Gb) DDR-266 memory in 2 chips.
UNKNOWN 16MB (128Mb) 8 Bit NAND bootloader flash.
UNKNOWN Laser Etched Black Carbon Fibre Case. (Foil shielded)
UNKNOWN 802.11G via Internal USB.
UNKNOWN Bluetooth v1.1 (4MBPS Max) via Internal USB.
UNKNOWN Internal ATA CF socket for use with user Supplied Storage (OS)
Nokia/SparkFun 128x128 SPI Graphical TFT for phone status info. (And flashlight. )
UNKNOWN Keyboard module
UNKNOWN 1800+ mAh Battery (Video Camera)
Illuminated Trackball with Select function (Power indicator )
UNKNOWN Scroll wheel with Select function
Fujitsu (UNKNOWN) Slide-bar Serial Biometric finger Scanner.
UNKNOWN IRDA for backwards compatibility?
UNKNOWN End-type speakers on edges of screen panel section of case.
UNKNOWN Microphone module.
UNKNOWN Internal Vibrator.
UNKNOWN Accelerometer for use with Trackball for Kicking serious butt on Quake.

Everything UNKNOWN still needs a Manufacturer/Supplier. I'm looking, but some (most) of you guys have better contacts than me.

Back to working on Case design, Stamp, how you doing with the keyboard panel?

Ferret.

[Ferret-Simpson]

Extra point, Forgot to mention:

Videomemory is shared between CPU and Internal Video.

With 512MB we can have 384 on CPU, and 128MB dedicated to Video.

Ok, ok, 448/64

In any case, I can see this being a pretty 31337 system. It looks to be more towards the price of the HTC Universal, at around £630 (950 USD?) After you add a 2gb CF card. Expensive, but the best piece of PDA hardware on the planet for the next 4 years.

If this is on sale, it'll force all the other Companies to buck up their ideas hardware wise, no?

VIVA OPEN SOURCE!

[speculatrix]

I'm still looking at the Sharp 4" CG Silicon screen (Same as the 6000) That we already looked at. We'll need a supplier, but it's the best choice I've seen as of yet.

I've been trying to get someone at
http://www.heroelectronics.com/
to respond to see if they will sell me a 6000 display which looks like this:

http://www.zaurus.org.uk/images/6000_screen_separate.m.jpg

here's a close-up on the part numbers:
http://www.zaurus.org.uk/images/6000_screen_codes.m.jpg

No response so far :-(

climbs on soapbox...

Oh yes, can I add one thing. BE VERY SURE THAT THE SPECIFICATIONS OF ALL THE CHIPS ARE PUBLIC. .. and that therefore the driver code can be fully GPL'd. Ensure that if you sign an NDA, it's purely temporary.

Why? Two Examples:

1] The 6000 uses a Toshiba companion chip and there is virtually NO documentation available (despite a LOT of effort) on the video acceleration and how to program it - result, the 6000 is not very good for movie playback.
2] a philips USB webcam driver was written for linux using specifications released under NDA.. the NDA expired and the driver had to be withdrawn and a new one reverse engineered

The original ATI W100 chip in the 750/750/860 also had similar problems, but luckily the demand was there and the skill on tap to create a good driver. The BVDD driver for the PXA270 came along rapidly and I guess it's because Intel have a positive attitude to publishing specifications and/or driver code.

I'll climb off my soapbox now

[Da_Blitz]

Might make some corrections to Ferret  simpsons post

ATA is 16 or 32 Bit an should be operating in UDMA mode, this means a minor speed increse over normal CF as well as much lower CPU overhead and NO memorey bus performance hit like the xscales, this is good news as the multimedia performance of this chip is quite good

flash is 8bit (not the HD) we could make it 16 bit but then it sits on the mem bus, as i said to feret i am aiming for battery life/performance first

one advantage this chip has is its IO capabilities are much better than the xscale so onboard video with shared memorey is not actually that bad, i cant wait to compaer this thing to a dell x50v, when i mean IO is good i mean it, you can read/write to flash, mem and the hard drive all at the same time (they are on diffrent busses) and the video card has its own dedicated bus to memorey so it dosent have contention over who can acssess the memorey controller

the NDA thing is a big isuue for me, i wont work with any chip that needs a NDA (i basically take them as meaning "our chips suck and we dont want you to tell anyone), open documentation is like playing poker with everyone able to see your hand (i mean that in a good way).

That said freescale has good documentation and could be compared to intel (there were no NDA isuues with BVDD, some one just had to sit down, read the docs and write the driver). i do belive that freescale has a libopengles libary, i must check the board support package they provide for that whoever they are known to be very open source friendly. one thing about the radio just bieng controlled by a serial port is that it should allow me to avoid NDA's as the RF stuff typically has that

the partioning of memorey is slightly worng as well, as far as i can see you dont partion it, you have an area for the frame buffer and allocate memorey as needed, whowevr i havent read the docs carefully enogh to be sure and it probelly depends an the driver as well (can anyone comment

next step is what software i use to design this, the current tools i have would allow me to work rapidly but i would only be releasing snapshots so the development model is slightly diffrent, one problem i can see is if someone wants to help then merging changes will be a problem. does anyone have any tools they would prefer or prefer to be seen bieng used (OSS?)

i was thinking of the most anoying production name i could come up with: harPWN3D  dont tell me what you think i get the idea , inspired by a harpoon missle

a little update on ferrets excelent post
accelerometer: freescale
gyroscope: freescale
fpga or CPLD: xilinx
internal ATA socket: dosent matter (generic)
DDR: infieon, hynix, samsung
flash samsung (hard to beat)

i updated these as they are all generic parts that i can get from places like digikey (very expensive compared to others) or several other manufacturers, where possible i am using freescale chips for several reasons (that i want go into)

keyboard pannel will be hooked to a 8x8 keyboard matrix scanner (on chip) so 16 pins + power (vcc, gnd) + LEDS (TBD, at least backlight (6 LEDs)+ 5 status LEDS, power LED, HD LED, i was hoping for multicolor backlighting so blue when typing, red with capslock or stiky shift on)

video out is still on but proper hdmi is out as there is no analog component to it, unless i can get a majic all in one chip that dose encoding of the signal for me (hdmi is a NDA thing), i was just hopping to use it as a VGA cable connector (means you have to wire your own) unless i can find a connector i am happy with or an encoder chip (personly i want an encoder chip). if we do go full hdmi then you lose the ability to plug it into a TV as well (throgh component or AV cables) without ethier a bulky adaptor or if the TV supports it

and for those who didnt guess DBHI is me  (Dablitz Heavy Industries)

[Da_Blitz]

. On this will be a Hardware locked bootloader with a personal encryption system, tied to the internal unique key of the system's iMX chip. This will kexec a 2.6.x kernel (Probably on the CF card) and the operating system. The bootloader will only load a signed OS, and the Drive will be encrypted, so he who steals your PP shall be screwed. Along with the Biometric reader, No one who isn't you can use or resell the PP.

Another function of this is the GSM/GPRS chip. It should be possible to put into the bootloader a function that traces the PDA via the Cellular network whenever an incorrectly signed ROM is loaded, or a SIM card is changed without entering it's details into some form of "Accepted cards" list. And yes, all of this should be configurable etc from GUI for myself and all the other simpletons. ^^

This could also access the Bluetooth/Wifi subsystems and use SMS to send the MAC addresses and names of any local hardware along with the trace data. This would enable the police to locate and recover the penguin safely, by providing them with a big fat arrow saying "CRIMINALS 'R' 'ERE". A happy thought, n'est pas? And yes, this could be set to redirect to one of your own phones, instead of to the police, if you're uncomfortable about possibilities of being traced yourself.

the phone home and track thing is not my idea but a reimplementation from xda-developers.org, i rolled a custom wince ROM for several XDA 2's (ie the himalayen) with this feature in it after reading a fourm post

the tracking function is quite limited but once you notify the police (at least in australia) there is the potential that they can acurattly track it, the best the pocket penguine can do at the moment is report which cell phone towers it can see and thier strength, and any location services your provider provides

the kernel signing thing is very simmilar to trusted computing (i "liberated" a few ideas from them), but its all done in software in user mode, basically the iMX3 decrypts and verifies the flash wihchi contians uboot and the bootloader kernel (the kexec one). then depending on options you have set it will go to the next stage, if you tell it no security then it looks for a kernel in a /boot folder (simmilar to how PC's do it) and execs that, note that the thing it exec's can be a program and may even be a script

if you have security enabled then things get more secure  it basically does the same as above except that it looks for a kernel that has been signed with a gpg key, you store your PUBLIC key on the device and keep your secret key secret. if it all matches up then the kernel will boot.

there will also be support for booting of an encrypted partion (that is the kernel to be booted is on the encrypted partion itself). because the kexecing kernel is linux, it has the linux crypto stuff so it can be told to get the decryption key, decrypt and mount the drive, copy the kernel to memory, then kexec the kernel

one cool thing about this chip is the built in encryption/decryption engine that uses a chip specific key, the program using the crypto module has no knowlage of the key. what this means is that you can store the keys in an encrypted form in flash. when the bootloader kernel boots it asks the crypto module for the keys which it uses to decrypt the partion and boot the kernel, then the loaded and gpg signed kernel boots and asks the crypto module for the unlock key again which it then uses to decrypt and start init.

the cool thing is that this can all be done without entering a pass phrase, however if you have root then you could comprimise the keys but even with normal crypto hard disks under linux this is posible, you might think that if someone boots thier own program then the can get the key without hacking your pda and getting root but thats where the gpg signigtures come into play (assuming your private key is kept safe)

works nicely , but dont forget there is the option to turn all this stuff off, the idea is that we use a linux kernel in a RO 16MB flash partion so we can easily write a bootloader in bash or simmilar, this makes Distro development alot easier as you can just have a distro on SD card and swap them as the distro kernel dosent need to be flashed but can reside on /

i really want to make it hard to brick the device, so if i can flash will be RO in hardwear and not by mount -o ro. i also wanted to make it easier for the distro people to make distros by removing the posibilty of bricking, kernel size not limited by flash, hot swapable (ie complete distro on SD, nice for dev work, reboot and kexec from CF to go to normal usage)

anyone care to comment or add to this, i know its overkill for all but probelly 5 people on this fourm but for those people it makes encryption alot easier (eg booting off encrypted /)

[Tom61]

For hardware write protection, you could have a jumper on the write line of the flash, and remove the jumper once you have JTAG'ed in the initial ROM. That'd make it unbrickable as a PDA, but give the option of reflashing later, should flaws in the bootloader be found, new features be needed, or when selling to another user (that way they aren't locked out by your key).

BTW, are you going to be making the initial ROM bootloader yourself Da-Blitz? I have an odd feature request for it: supporting loading from a set loop-back file on a FAT16/32 formated card. That way, it'd be easier to share the card with another device, or get a new card setup when you only have access to a Win based PC. I could see taking this on a trip as one's only PC-like device, where there is the possiblity of loosing or breaking the card would leave you with no way to get an image back on with anything but a coffee house PC or someone's laptop. Also, quickly switching the card into a camera when you don't have time to grab the pictures off the current one to get a few more precious snapshots would sometimes be handy.

One last thing, is there any ROM developers already considering porting to this OpenPDA? Getting a ROM developer interested early would probably be a good thing.

[Da_Blitz]

can do, in fact i suspect that many pepole would mant that as it allows you to boot into opie or gpe in OZ by doing that trick

the inital boot loader will be written by hand to load a linux kernel which then bootloads another kernel, this is for a number of reasons but it means bootloaders can be written in python/c/bash or whatever you feel like

i have made it easy for rom developers however i dont really see that as a problem to begin with as i suspect that the people who buy the first lot will be a bit more tech savy than most, if it ges bigger then we will need them

also remeber that there is no CF, there is however a CF socket internaly with an ATA interface so if you have a camera a usb cable might be a better idea

back to the pda, when everything is finalised and i can hand it off to kerenel devs than i will be hevily focusing on user space. i am thinking of using OZ as a base and doing some modifications (submitting changes back as needed) and writing some docs. i want to make it more like a modern PC distro (eg fedora, suse) where everything is well setup and there are standards. i feel the OZ packages are a bit inconsistent however the are trying to provide a modular aproch and i belive thats what causes it (eg few packages ship with config files)

please dont set HRW onto me for that, my design desions will be diffrent and thats because i expect to have a huge area for /, think of me as polishing the packages a bit

i never did consider the posibility of selling to another user but i will have to take that into acount, i am still trying to work out how to do the flash as it is a dificult problem, reflashing is needed in my opinion but how to do it properly and securyly is what i need to think about, idealy you can flash from inside the bootloader, but then there is the posibility of bricking the device, whereas if i use 2 flash chips i can use the second one as patch space for the first

[koen]

can do, in fact i suspect that many pepole would mant that as it allows you to boot into opie or gpe in OZ by doing that trick

the inital boot loader will be written by hand to load a linux kernel which then bootloads another kernel, this is for a number of reasons but it means bootloaders can be written in python/c/bash or whatever you feel like [...]
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Sounds a lot like what LAB (Linux As Bootloader) is doing right now. I'd advice you to look into that before reinventing the wheel. See [a href=\"http://joshuawise.com/contact]http://joshuawise.com/contact[/url] on how to reach the main developer.

[...] i am thinking of using OZ as a base and doing some modifications (submitting changes back as needed) and writing some docs. [...]
[div align=\"right\"][a href=\"index.php?act=findpost&pid=133648\"][{POST_SNAPBACK}][/a][/div]

I'd recommend using OE instead of OZ to have the same base, but leave out all the niggles and warts dictated by OZ's distro policy. Modifying binary images is what started the Z community, but it is definately not the way to go in the long run.
If you want to use an ARM core, please consider using EABI from the start, otherwise you'll end up with a big compatibility headache in a few months when debian-arm switches and the rest of the arm-dev world follows.

Oh dear, we are already discussing userspace issues when the hardware doesn't even exist yet

[Tom61]

also remeber that there is no CF, there is however a CF socket internaly with an ATA interface so if you have a camera a usb cable might be a better idea

Here in the US, CF is almost dead in consumer cameras (still doing well in prosumer, though), AFAIK. I could choose basically between XD and SD for media when I was last shopping for a camera. My current camera uses SD, and is about a centimeter taller than a CF card set on edge.