[nzlug] linux on Compaq Evo T20

[Warren Boyd]

On 2006/Nov/24, at 10:59 , Karl. wrote:

>>> I'm trying to get linux to recognise the internal drive (flash) in a
>>> Compaq Evo T20.
> ...
>> IIRC - The kernel is loaded via the boot loader - in this case grub,
>> so to get your kernel up and running, grub needs to be able to find
>> it - so far, so good.  Next - is initrd, and, unless I've very
>> mistaken[0] - this is pointed from grub as well.
>
> Yes, that's right.  I am using a grub preset-menu to tell it to load
> the kernel and initrd from hd0,0.  I've not been able to get grub  
> to use
> a normal /boot/grub/menu.lst config file, but I've not pursued that
> route very far - instead I've been trying cmdline options for the  
> kernel
> I am booting - the point being that if I am successfully booting a
> kernel (which I am) then it is more important to get that to recognise
> the drive than grub (whose sole purpose is to boot the kernel,  
> which it
> is doing).  Fixing one may turn out to fix the other though...
>
> The system is a little inconvenient to debug because the only keyboard
> port is usb, and grub doesn't support usb keyboards, so I can't run  
> grub
> interactively.  As far as I can see, there is no conventional cmos  
> setup
> in which one could enable usb legacy keyboard support - this  
> appears to
> be a 'legacy-free' device.  Each test run of new kernel options  
> requires
> re-flashing the device.

Legacy free - that's what I read on the matter...  You might be able to
chain load etherboot for network booting (This is just from skim reading
some webpage).

>
>
> I've not succeeded in getting grub to fetch a config/kernel from the
> network either - I get a compile error when I try to build the  
> ethernet
> support into grub (main.c:57: error: static declaration of  
> 'bootp_data'
> follows non-static declaration) and I've not pursued fixing that.  It
> might be a good option to make experimentation easier.
>
>
>> So - that leaves the possibility that the kernel cannot see the drive
>> itself - which I would assume is due to missing module / driver in  
>> the
>> kernel itself.
>
> I think/thought (and might still think) that too, but since grub can
> load the kernel from the drive then it can't need anything too bizarre
> can it?  I am running DSL which runs on all sorts of things and I
> presume should be able to handle anything that grub can read...
>
> I do wonder if grub is blindly forging ahead with something and it is
> working, whereas the kernel is more carefully probing and not seeing
> what it expects to see and is therefore giving up (and if it blindly
> forged ahead then it might work too).  I have been experimenting with
> kernel options along these lines (hard-coding ide parameters), but  
> have
> not found success yet.

I thought grub blindly accepted what the BIOS told it?  In any case, the
kernel will definitely ignore the BIOS - iirc it uses the BIOS to gather
information, but doesn't actually use the BIOS calls for hard drive
activity.  Which makes me think - does the IDE driver have a switch  
(or an
there an alternative IDE driver) that tells the kernel to use BIOS calls
instead?  It *might* be slower, etc. but I hardly think that this  
application is going
to suffer too much ... ;-)

>
>
>> Hrmmm - sounds very much like there's something not quite right with
>> the drive, either the kernel not detecting it, or something strange
>> about the drive itself.
>
> I gather that the Geode/CS5530 is not entirely normal.  I tried
> re-flashing with the NTembedded image which is meant for the  
> machine and
> then ran the MS diagnostics prog WINMSD.EXE, hoping to find some
> interrupt or other info, but it didn't reveal anything much to me.
>
>
>> As an alternative - how about booting off the network?
>
> Yes, that works.  Before I got DSL running I did an etherboot/LTSP  
> setup
> (http://rom-o-matic.net makes it pretty easy).  My main objective is a
> standalone boot though - there are a couple of applications I have  
> where
> there won't be a server available.

I thought that could be the case ... :-)


>> ===========================================
>>> hda: C/H/S=27881/83/162 from BIOS ignored
>>> hdb: C/H/S=0/0/0 from BIOS ignored
>> ===========================================
>>
>> This is what worries me - these tell me the BIOS details are  
>> ignored -
>> but I cannot see any further detail about the drives?
>>
>> I would suggest that there is something in there that needs to be set
>> for the flash drive to be recognised.
>
> Yep.  That's my current area of guessing too.
>
> Thanks for your thoughts on the matter  :-)
>
> Karl.