Hi Ken,
I am confused by your references to different model numbers.
If you check:
http://pdadb.net/
http://www.handhelds.org/moin/moin.cgi/HpIpaqHx2000
You will see that the hx2000 series are all related:
MHz RAM FLASH WIFI
hx2110/5 312 64 64 no
hx2190/5 312 64 128 no
hx2410/5 520 64 64 yes
hx2490/5 520 64 128 yes
hx2750/5 625 128 128 yes
hx2790/5 625 128 192 yes
cpu: PXA270
wifi: Samsung SWL-2360C (Texas Instruments TNETW1100BGHH?)
bluetooth: TI BRF6150
Don't confuse the hx2000 series with the h2200 or the hx4700.
The h2200 is a different device with a PXA255 CPU @400 + HAMCOP controller.
The hx4700 is different again with a [EMAIL PROTECTED], a different touchscreen
interface
(although probably related), and an ASIC3 controller.
[EMAIL PROTECTED] wrote:
Thank you, I think you are just the person I can bounce ideas off and know what will work on the Ipaqs.
I did a little work on Linux on the Palm LifeDrive..but we couldn't get
WiFi going and my LD finally bit the dust...and the project slowly died.
--Kernels are not my strongest area but I'm learning.
http://www.handhelds.org/moin/moin.cgi/RamdiskRescue
Nice prog. Haven't tried it but looks very good. Well, you appear to know a
lot about the Ipaq and how they boot, etc.
Getting better ;)
My simple goal of getting the project moving keeps getting bigger.
-- From what I've seen the 2200/2400/4700 branch is both one device yet
three different configs. The issue I've run in to in my little project is
that the zImage I use doesn't recognize all the various media that holds the
VFAT and EXT2. -- The software will work, but only if you are using a
supported brand of CF.
Hard to tell what the problem is here.
This is where Ramdisk Rescue should help ... helping to bridge the
gap between users and developers with the ability for an "involved"
user to provide developers with meaningful feedback.
BTW: yes I do format all my CF cards as EXT2, it's just habit that I refer
to it as EXT3..[which is what I work with during the day on i686 servers]
(but EXT2 kernels can still read EXT3 volumes and just ignore the journal).
Bad habit ;) ... will only cause confusion.
Anyways after looking at your work... you have already achived a lot of what
I want to do... recognize media.
That's really a kernel issue, and not my doing.
I will dig through your sources and look for clues on how to make a
mini-kernel (1st stage).
Ramdisk Rescue, you will probably be shocked to realise, is a couple
of ash (busybox) shell scripts wrapped up in an initrd. It's intention
is to be machine neutral, so that a suitable kernel for your device
*should* be the only thing required to do something useful. However,
the kernels produced by most projects are unsuitable as they do not
have essential modules built statically into the kernel, eg: ext2,
ide_cs, pcmcia*, mmc* ... etc. So, my "major" work as far as RR goes
is to compile such kernels for each device.
My goal was to make a zImage that would work on all the various Ipaq in the
common hardware 2400/4700. You mentioned the 2200, are they on a simular
platform as the hx2495?
Paul Sokolovsky (psokolovsky) has mentioned this in the past ... "a
generic arm kernel" (for example), however, this involved a complete
restructure of most of the drivers required, so I'm not sure how/if
he has progressed at all in that direction. Try asking on kernel-discuss@
or #handhelds-kernel.
Is there a way to make a mini kernel that would run on almost any ipaq
hardware? -- I have a feeling I'd have to make 20 different one. (like a 1st
stage boot) -- I'm guessing you solved this issue already with your ramdisk
boot.
If you look at the "Download Matrix" on the RR wiki you will see I haven't.
I think what I'm reinventing is GRUB in a way. Get a boot menu displayed
showing what media is bootable and proceed to mount it and hand control over
to a smarter kernel on that media.
That would involve a lot of trickery, and kexec functionality.
Although it might be possible, I'd suggest it would be a long way
off at this stage.
I think you'd be better off having a look at LAB and attempting to
port it to the hx2000 series.
-- if only one EXT2 is found, automaticly attempt to boot it.
LAB uses a few extra tricks, but that's essentially the idea.
At least in convential linux setups there is a /boot/ folder that
has the 'smart' kernel for that device.
Would something like this work?
HaRET ->
1st-zImage(s) (load, detect all media, find all ext2 partitions:
Then display a boot menu of all valid EXT2 partitions)
Not without writing a driver for windows that can read ext2!
However, with kexec, a minimal initrd could quite possibly kexec
another kernel and it's associated rootfs. This should actually be
quite achievable with RR.
User selects which one to boot if more than one is located. --this could be a
pain because now you have to add TouchScreen or Button support in the
mini-kernel. --at this point I just need it to find ANY EXT2 and boot.
RR is even more basic than that.
The buttons are remapped to "real commands", framebuffer console
(no graphics), and the graphics you see are handmade screen dumps
(then modified) and dumped back into the framebuffer when needed.
With directfb I guess this could actually be quite neat (aka pretty)
however, I haven't gone in that direction because of the limits
imposed by the size of (the extracted) initrd in memory.
Then the next step would be the big kernal (on the EXT2) which could discard all the info from the mini-kernel --maybe retain the media mount driver.
google for kexec
This would be the one that everyone would be interested in,
add as many modual/drivers for all the ipaqs, etc. It would be nice to have
a modular detecting hardware system simular to desktop boots.
Even with the advent of a generic kernel, RR (or any initrd with kexec)
would probably not be able to hold the number of modules to make this
feasible. Basic functionality (inc. boot menu) is certainly a possibility
and I will look into this for the upcoming version of RR.
Just rolling ideas, (and all I originally wanted was wifi, lol)
heh :)
decided to help everyone else that was having trouble just booting.
cool
I don't know if this is a step backwards by making a
universal zImage that will attempt to be ipaq/media friendly.
forget universal/generic atm
I just can't stand that there are so many zImages floating
around and you have to find the one that works for each situation.
consolidating resources is this best way to reduce this.
Thank you,
Ken
np.
Marcus.
ps: remember to CC to the list so that others can learn
Hi Ken,
I am the author of Ramdisk Rescue:
http://www.handhelds.org/moin/moin.cgi/RamdiskRescue
I have access to a hx2110 (if I can prise it out of g/f's hands;) which
I would like to include as a supported machine. If I can do that, I think
you'll find a vast increase in willing testers/users.
For suggestions, have a browse through the RR source on sf.net:
http://ramdisk-rescue.svn.sourceforge.net/viewvc/ramdisk-rescue/
I've commented most of the source.
Additional suggestions:
- use ext2 instead of ext3 filesystems on cards.
- jffs2 is only used for flash, not cards.
- use bitbake to build
(see http://www.openembedded.org/wiki/GettingStarted)
Regards,
Marcus.
Ken Lyons - SplinterFL wrote:
Well, after talking to several user it appears my zImage doesn't work
for everyone. So I went on a testing spree and
found that the zImage I use works great if you have a
SanDisk/compatible CF card. My EXT3 files appear to be fine,
trouble is just getting linux to boot and pivot the root to the EXT3.
I downloaded GIT in preperation to start compiling a new kernal --with
every driver known.
I've compiled kernels for MIPS and x86, but this will be my first ARM
project (a little new to this arch). I'm looking for
someone to actively assist in helping to create a new kernel or enhance
the existing ones.
--- I see great potential, just the project seems stalled.
I have tested several other zImages and couldn't get my extra 1GB flash
to be recognized... failed when it can't pivot.
-- the two others I tested had a corrupt EXT2 Ramdisk built in which
would fail to initialize.
If anyone on the list has compiled kernels for this series I'm
interested in your setup/files/sources and could use some pointers on
anything you've learned.
* * * If you are interested in helping, I'm willing to test more
zImages and post working combinations.
Just email me your zImage & default.txt to my private email (max
5MB/ea) gz/zip.
If anyone has any ideas on the best approach for this super boot
kernel, I'm all ears.
I know partitioning CF / SD cards is a pain, but I don't see a more
effiecent way to give linux a dedicated space without
doing a FS inside a file, on the VFAT . (essentially using a ZIP
file to be the rootfs ).
After spliting several cards last night, I've learned the fastest way
which seems to work for me. I'll post my results later on my site.
http://www.bees-garden.com/linux/
FYI: CF cards act like ide hard-drives, can be partitioned as such and
have wear-leveling built-in to the card. (no os involvment).
So I guess my first goal (constantly shifting TO-DO list ).
1. Make a simple HaRZET, default.txt, zImage combination that
has the most drivers for booting on
ANY of the series devices using ALMOST ANY CF / SD card.
I currently try to avoid jff2 on CF, but it seens required for SD cards
to improve performance.? (correct if this is wrong)
Ken
------------------------------------------------------------------------
_______________________________________________
Hx2000-port mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/hx2000-port
-----------------------------------------
This message sent by OakMailer. Hosted by Graphix Wizard Hosting.
Anti-spam notice, this message originated from IP Address:
70.10.162.6
-----------------------------------------
_______________________________________________
Hx2000-port mailing list
[email protected]
https://www.handhelds.org/mailman/listinfo/hx2000-port
