Re: Re: stuck on black screen

Hi Joshua,

Joshua Cummings wrote:
> Hi
>
> Thanks for your prompt reply.
>
> On Wed, 2007-06-06 at 09:51 +1000, Marcus Brown wrote:
>> Hi Joshua,
>>
>> The working, bootable 2.6 kernel is already provided in the tarball.
>> I would suggest that you have made an error somewhere.
>
> Hopefully that is the case, but I've followed every tutorial/howto/wiki
> page related to the h2200 I can find. A blank screen after haret is
> still as far as things have gotten (besides the desperate ramdisk rescue
> zImage attempt).

Following _only_ the RamdiskRescue wiki *should* give a bootable system.
Keep in mind that the first boot usually takes some time.
The only way to *absolutely* find the problem is to use a serial console:
http://www.handhelds.org/moin/moin.cgi/HpIpaqH2200SerialCable
(note that you would need to add another console stanza to cmd line)

>
>> When you say "watching the ramdisk rescue kernel fail to boot" are
>> you referring to the first boot (when booting to extract the image),
>> or the subsequent boots (when booting TO the extracted image).
>
> I'm referring to when I tried the zImage from ramdisk rescue as a last
> ditch effort to get anything to boot. It's the only kernel I've tried
> that's actually booted and displayed anything to the console. Failing to
> mount the ext2 filesystem is as far as it gets though

Trying to use the RamdiskRescue kernel to boot a gui *will not work*.
The RR kernel has been cut right down, and built for framebuffer console
only. Failing to mount the filesystem, however, does seem strange.
Can you verify the error, or use a Linux machine to fsck the fs?

>
> The actual RR installer works fine. Boots, installs everything fine,
> without any errors. After completing an RR install, I've modified the
> fstab to support card booting etc. I've tried different versions of
> haret with different zImages, including several builds/versions found in
> the official downloads for 0.8.4 and it's release candidates. Basically
> I tried any file(s) that might have h2200 support.

RR should be correcting the fstab for you automatically.
What/why are you changing fstab?
I'd suggest to you that your "stab in the dark" approach to this problem
is flawed, and will only net you a result by fluke! Following the RR
wiki and my suggestions above should provide you with either a bootable
system and/or the reason why your attempts haven't worked to date.

>
> I've tried using the iPaq file store method with a single 1GB CF ext2
> partition. Same results.

Again, you haven't diagnosed the root of your problem, so this step will
only confuse your attempts and dilute your efforts.

>
> Here is the content of my startup.txt, in case it helps.
>
> set KERNEL zImage
> set MTYPE 341
> set CMDLINE "root=/dev/hda2 rootdelay=5 console=tty0"
> bootlinux
>
>
> Increasing or decreasing the rootdelay count doesn't seem to have any
> effect.
>
> Contents of CF FAT filesystem:
>
> startup.txt
> haret.exe
> wrap-haret.exe
> zImage

wrap-haret is not required for modern versions of HaRET.

>
>> If it is the former, then I suggest you re-read the instructions, start
>> again ... and if it fails try to give a lot more detail before
>> attempting to "bump" a post in the list.
>>
>> If the latter, then I would suggest that something has gone wrong with
>> your image extraction. Some possibilities include:
>> card too small, card improperly formatted, card r/w errors, etc
>
> I'm using a working Kingston 1GB CF card, formatted with the appropriate
> filesystems. FAT filesystem is 48M and the ext2 is 922M. I've never had
> any sort of problems with this card.

Problems in mswin-based system? You wouldn't notice ;)
Problems in Linux? No such thing ... they're all "features" ;)
However, I would suggest (without better diagnosis, eg serial console!)
that you try reducing the size of the ext2 partition.

>
> Please let me know if anyone needs more information.

# e2fsck -f /dev/hda2 (or appropriate node on a host)
# fdisk -l /dev/hda2

You *might* be able to get more info using the RR-kernel on your card,
but I can't verify or support it.
RamdiskRescue should be able to give you all sorts of information if
you run through all the card-related tests and then save the syslog.
Posting the gzipped syslog with your next post *might* help.

Marcus.
Received on Wed Jun 06 2007 - 00:40:34 EDT