[Hpipaq21x-devel] boot observations

[Oliver Ford]

Giovino, Jeffrey D. wrote:
> Thank you for the courteous reply. 
> It was refreshing to see somebody actually consider the topic before outright dismissing it!
>   
I'm an experimental scientist by profession, I'm used to trusting 
observations over my existing beliefs.
> Can you try again and make a copy of the partition table (512 bytes from 
> the start of the overall device), e.g.
> "dd if=/dev/sdb of=mbr.bin bs=512 count=1" but replace /dev/sdb with the 
> device (like /dev/sdb without any number, not like /dev/sdb1)
> before and after writing the tarball to the ext2 partition.
>
> Hmm, very odd one that.
>
> ... I will put this on my todo list. Will need to ramp up on dd however first.
> ... is this an experiment or a fix?
>   
Experiment, I'm trying to figure out what could possibly be changing to 
upset the boot ROM.

> ... following up on your thoughts above:
> 	1) fdisk - Format one large SD for 1 cyl (255x63) fat16 and remainder ext2
> 	2) mkfs.ext2
> 	3) un-tarball rootfs
>  	4) fdisk for only partition one with dormant ext2 filesystem
> 	5) have u-boot or the kernel modify the partition table and add back the ext2 second partition.
> 	6) this won't survive a reboot, but might provide insight.
>   
Might work, but it really shouldn't be necessary.

> ... I also noticed that when formatting the SD card it 
> ... was necessary to run mkfs.ext2 -L <ANGSTROM? /dev/db2;
> ... BUT running mkfs.msdos [-F 16] -n BOOT /dev/sdb1, although 
> ... intuitively correct, caused it to fail at boot time.
>   
I don't follow, are you saying the volume labels matter, or am I missing 
something?

> ... the wiki could use a step by step fdisk/mkfs.ext2 procedure as well; I would be happy to provide
>   
Yes, that'd help a lot.

> Yup, that's a good procedure a few other people have had to use before. 
> If you have time, could you (or anyone else who feels like volunteering) 
> write something about that on the wiki?
> ... I would be glad to. Please point me in the right direction; Or should I simply send you a html/text file?
>
>   
Either add it to this one:
http://www.handhelds.org/moin/moin.cgi/HpIpaq214HowTo

or make a new page, something like 'HpIpaq214FAQ' or 
'HPIpaq214Troubleshooting'.

You have to sign up to the wiki to edit, but anyone can do it.

>
>   
> Not sure exactly what you mean they do. Some people often do stuff with 
> loading a small rootfs to start with that has all the kernel modules 
> which can then access the big partitions. They do it to keep the kernel 
> small enough to store in flash. We don't have that problem because the 
> kernel contains all the drivers (because I never got the hang of working 
> with modules) and can be as big as we want since U-boot takes it from 
> the FAT16 partition.
> ... this topic addresses the ability to boot from large SD cards.
> ... this device mentioned can boot at least 2G SD cards that I have tested.
> ... here is a link to what I was referring to:
>  http://groups.google.com/group/beagleboard/msg/18b3c91e659ea206
>   
That seems to be because U-boot requires their RAM to be setup so that 
have a separate piece of code to do that first. Actually, the ipaq is 
similar since there is already a piece of code that runs before U-boot 
called the OBM (OEM boot module). It is that code which tests for the 
0-1 buttons and boots from the MMC card accordingly.
> ... this might have something to do with topic one above
> ... Is the dd procedure you mentioned already the way to get large SD cards to boot?
>
>   
No, that was just to make a copy of the SD-cards MBR to see what is 
happening.
> ... I am working toward building my application from source using your Angstrom hpipaq21x and the gnu-eabi-gcc
> ... I have already ran a hello world compiled with this compiler from another arm device
>   
OK, I'll be interested to here what you're building and how far you get.

If you're thinking of doing any serious embedded development though, 
It's definitely worth the time installing and getting used to 
openEmbedded. It also lets you edit all the existing apps.

> The term 'xscale' refers to a huge range of processors. It's possible 
> that their advert refers to a much higher spec model, or a software 
> openGL that uses the main CPU optimisations. If you find anything out, 
> let us know!
> ... please let me know if this is the processor:
> ... http://www.marvell.com/products/processors/applications/pxa_3xx/PXA310_PB_R4.pdf
> ... see page 2 para 1: 'ecosystem'
>   
Yes, thats the one. It definitely  does have the graphics acceleration 
and both windows and that directFB driver use it. I'll keep pushing my 
stuff up to date with the mainline kernel every few months so maybe 
sometime later this year it should just magically turn up. Still needs 
an X11 server for it though, unless someone wants to try switching us to 
a distro based on directFB rather than X11?

Oliver