[ipxe-devel] serial arrow keys broken

Tue Apr 22 11:30:39 UTC 2014

Thanks Peter. Commenting out cpu_nap() worked for us, so if anybody is
looking to get the arrow keys on a menu working via Dell Serial over LAN
(SOL) via iPXE, that is what you need to do.

This might be a dumb question, but do we really care about power usage
during the menu stage of a PXE operation? Obviously, we can just comment
that line out, but if the only downside is a slightly higher CPU usage
during menu versus keys not working it seems that erring on the
always-works option by default might be sensible.

Either way, thank you for your help!

-Alex

On Thu, Apr 17, 2014 at 3:24 PM, Peter Pickford <peter at netremedies.ca>wrote:

> HI Alex,
>
> That means its sending an escape sequences but the <esc>] bit is being
> lost.
>
> I believe this is due to only having a single character available to read
> from the serial UART (the last one received) after the system generates an
> interrupt to bring it out of it out of the cpu_nap sleep routine
>
> That thing I tried was
>
> ipxe/src/core/serial.c
>
>         /* enable and reset fifos, set threshold to max for escape
> sequences */
>         uart_writeb(0xc3, UART_BASE + UART_FCR)
>
>
> This seems to work for me, holding down the arrow key can occasionally
> result in an esc being read on its own which causes a menu exit.
>
> Enabling read interrupts has no effect but it doesn't break ipxe either.
>
> If I get past that then holding down an arrow key in grub causes and exit
> from the menu I was editing (this is a grub problem not ipxe but is
> suggests that even this code isn't perfect - maybe rts/cts needs to
> beenabled but then that prevents boot if there's no serial connected)
>
> Commenting out the cpu_nap i core/getkey.c should also work but that will
> cause the cpu to constantly poll for characters and use more power.
>
> Michael Brown mcb30 at ipxe.org, had a concern over resetting the receive
> and transmit fifos by using 0x03 instead of 0x01 but the code immediately
> following it drains and pending characters anyway. 0xC0 octet sets the
> thresholds as high as possible but this is probably more about delaying
> interrupts than making the fifo buffer any quicker and as interrupts are
> disabled this probably has no effect.
>
> values to tried all seem to work
> 0x01 enable fifos only (this is probably enough)
> 0x03 reset and enable fifos
> 0xc3 set fifo thresholds reset fifos and enable fifos.
>
>
> My system is using a motherboard serial device accessed from a direct
> serial cable, you are using an Dell iDRAC via java or activex which has
> more things to go wrong I guess.
>
> Jarrod Johnson jarrod.b.johnson at gmail.com, pointed out that some vt100
> mode keys send <esc> O A instead of <esc> ] A this that is what is
> happening the ipxe will not recognise it but I thing you would get at least
> OA printed if the input routine sees all three chars of the escape
> sequence. I think the first problem is that its not seeing all the
> characters.
>
> Michaels patch didn't work for me and I didnt try adjusting
> #define GETKEY_TIMEOUT ( TICKS_PER_SEC / 4 )
>  The suggestion was to change this to 2 which would make it 1/2
> sec until read timout instead of 1/4 sec I don't think that will work as
> the problem is that 3 chars are received while waiting for
> an interrupt and only the last character received is seen as there is no
> buffer in the hardware, interrupts are not enabled and there is no isr even
> if they were (but it would trigger and immediate exit from cpu_sleep when a
> character is received but that still does not seem to be enough .
>
> Porting the interrupt driven serial code from linux is a lot of work and
> not worth the effort for input, as Michael pointed out keyboard input is
> not performance sensitive,
>  but perhaps output would be significantly faster -- still not many ppl
> spend all day in ipxe menus.
>
>
> Thanks
>
> Peter
>
>
> On 17 April 2014 05:10, Alex Davies <alex at davz.net> wrote:
>
>> A, B, C and D. Here I pressed the key after each word (e.g. “u”, “p”, <up
>> arrow”):
>>
>>
>>
>> iPXE> up A down B right C left D
>>
>> up: command not found
>>
>>
>> The graphical console looked like the screenshot below when I entered the
>> keys via SOL:
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 9, 2014 at 11:48 AM, Peter Pickford <peter at netremedies.ca>wrote:
>>
>>> If you exit the menu and got to the ipxe command line what do you get
>>> when you press the arrow keys?
>>>
>>>
>>> On 9 April 2014 03:41, Alex Davies <alex at davz.net> wrote:
>>>
>>>> Hi All,
>>>>
>>>> We had the same problem using SOL on Dell hardware.
>>>>
>>>> I tried both your patch Michael and the divide by two suggested at the
>>>> top of this thread, without joy.
>>>>
>>>> Interestingly, pressing the arrow key does stop the countdown timer,
>>>> but the menu selector does not move, so iPXE is getting something. What
>>>> debug flag should I enable to see what it is getting?
>>>>
>>>> The menu is working nicely with color and if I connect to the 'full
>>>> console' via the DRAC, and move the arrow key, the SOL menu refreshes
>>>> correctly.
>>>>
>>>> Thanks!
>>>>
>>>> -Alex
>>>>
>>>>
>>>> On Thu, Mar 27, 2014 at 2:46 PM, Michael Brown <mcb30 at ipxe.org> wrote:
>>>>
>>>>> On 27/03/14 08:36, Peter Pickford wrote:
>>>>>
>>>>>> The arrow keys would not work in my ipxe serial console.
>>>>>>
>>>>>> The following seems to fix it but causes a busy wait while reading
>>>>>> escape sequences.
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>
>>>>> Arrow keys over serial works for me.  Could you try the attached
>>>>> (untested) patch, which preserves the cpu_nap() while changing the ordering
>>>>> of events such that a keypress arriving during the cpu_nap() will be
>>>>> detected even if the timeout has expired?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Michael
>>>>>
>>>>> _______________________________________________
>>>>> ipxe-devel mailing list
>>>>> ipxe-devel at lists.ipxe.org
>>>>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Alex Davies
>>>>
>>>> This email and any files transmitted with it are confidential and
>>>> intended solely for the use of the individual or entity to whom they
>>>> are addressed. If you have received this email in error please notify
>>>> the sender immediately by e-mail and delete this e-mail permanently.
>>>>
>>>
>>>
>>
>>
>> --
>> Alex Davies
>>
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they
>> are addressed. If you have received this email in error please notify
>> the sender immediately by e-mail and delete this e-mail permanently.
>>
>
>

-- 
Alex Davies

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the sender immediately by e-mail and delete this e-mail permanently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20140422/bbd14bf8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 20033 bytes
Desc: not available
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20140422/bbd14bf8/attachment.png>