Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
> On 29. Mar 2020, at 09:40, Ruslan Garipov wrote: > >>> >> >> That definitely can be the case. If you do not set any custom values, >> missing tem.* variables would confirm that. >> >> Now, there is still an question, why in your system that allocation does >> fail? > Is there a way I can help you to figure that out? I'm afraid I will not > have an access to my systems during the following week, but even so. Hi! Please test latest current:) thanks, toomas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
On 3/27/2020 8:07 PM, Toomas Soome wrote:
>
>
>> On 27. Mar 2020, at 16:39, Ruslan Garipov wrote:
>>
>> On 3/14/2020 11:36 AM, Toomas Soome wrote:
>>> Author: tsoome
>>> Date: Sat Mar 14 06:36:03 2020
>>> New Revision: 358989
>>> URL: https://svnweb.freebsd.org/changeset/base/358989
>>>
>>> Log:
>>> loader: add comconsole implementation on top of SIO protocol
>>>
>>> Provide comconsole on top of SIO for arm platforms (x86 does use bios
>>> version).
>>>
>>> Added:
>>> head/stand/efi/loader/efiserialio.c (contents, props changed)
>>> Modified:
>>> head/stand/efi/libefi/efi_console.c
>>> head/stand/efi/loader/arch/arm/Makefile.inc
>>> head/stand/efi/loader/arch/arm64/Makefile.inc
>>> head/stand/efi/loader/conf.c
>>> head/stand/efi/loader/main.c
>>>
>>> Modified: head/stand/efi/libefi/efi_console.c
>>> ==
>>> --- head/stand/efi/libefi/efi_console.c Sat Mar 14 05:57:22 2020
>>> (r358988)
>>> +++ head/stand/efi/libefi/efi_console.c Sat Mar 14 06:36:03 2020
>>> (r358989)
>>> @@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const void *buf __u
>>> {
>>> }
>>>
>>> +/*
>>> + * Set up conin/conout/coninex to make sure we have input ready.
>>> + */
>>> static void
>>> efi_cons_probe(struct console *cp)
>>> {
>>> + EFI_STATUS status;
>>> +
>>> + conout = ST->ConOut;
>>> + conin = ST->ConIn;
>>> +
>>> + status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
>>> + (void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>>> + if (status != EFI_SUCCESS)
>>> + coninex = NULL;
>>> +
>>> cp->c_flags |= C_PRESENTIN | C_PRESENTOUT;
>>> }
>>>
>>> @@ -889,15 +902,7 @@ efi_cons_init(int arg)
>>> if (conin != NULL)
>>> return (0);
>>>
>>> - conout = ST->ConOut;
>>> - conin = ST->ConIn;
>>> -
>>> conout->EnableCursor(conout, TRUE);
>>> - status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
>>> - (void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>>> - if (status != EFI_SUCCESS)
>>> - coninex = NULL;
>>> -
>>> if (efi_cons_update_mode())
>>> return (0);
>> Hello, Toomas!
>>
>> I have to return to this revision once again.
>>
>> Speaking in advance, the problem I'll describe isn't a fatal one. I
>> want to find a solution/root cause by myself... well, I had tried to do
>> that but failed, therefore, I need some tips from you, if you have free
>> time for that.
>>
>> The loader started to ignore teken.fg_color after r358989.
>>
>> I like to have green text on black console. Therefore, I have this:
>>
>> teken.fg_color="green"
>
>
> Oh cool, at least it is useful for someone:)
>
> I am sorry, yes this is my bug, I somehow missed the second probe and assumed
> we do probe only once.. And yes, your analysis is correct, the environment
> with callback should be treated carefully.
>
> What probe must do is to set up conin/coninex so the efiserial can use
> workaround for buggy SIO, the rest is not that important.
>
>
>>
>> in my /boot/loader.conf. Before r358989 everything worked just like I
>> wanted: not only vt(4) had green text on black, but the loader menu
>> also. After r358989 vt(4) still renders greeen text on black, but the
>> loader doesn't. It use default white on black. The variable is
>> assigned but doesn't affect the output:
>>
>> OK show teken.fg_color
>> green
>>
>> That started to happen after the changes from above: when code from the
>> efi_cons_init() was moved to the efi_cons_probe()
>> (stand/efi/libefi/efi_console.c). Therefore, if I revert those only
>> changes, the loader starts to draw green text on black.
>>
>> If I read the sources correctly, the cons_probe() function in
>> stand/common/console.c calls both those functions. Moreover, the
>> efi_cons_probe() is called twice: first time when the cons_probe()
>> probes all available consoles, and then when it searches an "online"
>> console. And then the cons_probe() calls the efi_cons_init(). I see
>> nothing between those calls which may cause the loader to ignore
>> teken.fg_color (or any other variable).
>>
>> I believe that the efi_set_colors() function from
>> stand/efi/libefi/efi_console.c is not call being the hook function for
>> the teken.fg_color variable. The efi_cons_update_mode() sets the
>> efi_set_colors() as the callback for teken.fg_color, but it's never
>> called. The only reason for that, according to code of the env_setenv()
>> in stand/libsa/environment.c, is that teken.fg_color was already created
>> (without the hook function, of course) when the efi_cons_update_mode()
>> tries to assign the efi_set_colors() hook. Or, the
>> efi_cons_update_mode() failed to allocate the buffer, and, therefore,
>> didn't set teken.fg_color at all. And later teken.fg_color is read from
>> /boot/loader.conf.
>>
>> One more evidence that efi_set_colors() is not called: setting
>> teken.fg_color from the loader
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
On Sat, Mar 14, 2020 at 06:36:03AM +, Toomas Soome wrote: > New Revision: 358989 > URL: https://svnweb.freebsd.org/changeset/base/358989 > > Log: > loader: add comconsole implementation on top of SIO protocol > > [...] > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/stand/efi/loader/efiserialio.c Sat Mar 14 06:36:03 2020 > (r358989) > @@ -0,0 +1,518 @@ > +/*- > + * Copyright (c) 1998 Michael Smith (msm...@freebsd.org) If this is the new code, then copyright date and maybe attribution seem wrong. If this is the old code, why wasn't it repocopied? ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
> On 28. Mar 2020, at 08:07, Alexey Dokuchaev wrote: > > On Sat, Mar 14, 2020 at 06:36:03AM +, Toomas Soome wrote: >> New Revision: 358989 >> URL: https://svnweb.freebsd.org/changeset/base/358989 >> >> Log: >> loader: add comconsole implementation on top of SIO protocol >> >> [...] >> --- /dev/null00:00:00 1970 (empty, because file is newly added) >> +++ head/stand/efi/loader/efiserialio.c Sat Mar 14 06:36:03 2020 >> (r358989) >> @@ -0,0 +1,518 @@ >> +/*- >> + * Copyright (c) 1998 Michael Smith (msm...@freebsd.org) > > If this is the new code, then copyright date and maybe attribution > seem wrong. If this is the old code, why wasn't it repocopied? > > ./danfe It is based on libi386 version. rgds, toomas ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
> On 27. Mar 2020, at 16:39, Ruslan Garipov wrote:
>
> On 3/14/2020 11:36 AM, Toomas Soome wrote:
>> Author: tsoome
>> Date: Sat Mar 14 06:36:03 2020
>> New Revision: 358989
>> URL: https://svnweb.freebsd.org/changeset/base/358989
>>
>> Log:
>> loader: add comconsole implementation on top of SIO protocol
>>
>> Provide comconsole on top of SIO for arm platforms (x86 does use bios
>> version).
>>
>> Added:
>> head/stand/efi/loader/efiserialio.c (contents, props changed)
>> Modified:
>> head/stand/efi/libefi/efi_console.c
>> head/stand/efi/loader/arch/arm/Makefile.inc
>> head/stand/efi/loader/arch/arm64/Makefile.inc
>> head/stand/efi/loader/conf.c
>> head/stand/efi/loader/main.c
>>
>> Modified: head/stand/efi/libefi/efi_console.c
>> ==
>> --- head/stand/efi/libefi/efi_console.c Sat Mar 14 05:57:22 2020
>> (r358988)
>> +++ head/stand/efi/libefi/efi_console.c Sat Mar 14 06:36:03 2020
>> (r358989)
>> @@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const void *buf __u
>> {
>> }
>>
>> +/*
>> + * Set up conin/conout/coninex to make sure we have input ready.
>> + */
>> static void
>> efi_cons_probe(struct console *cp)
>> {
>> +EFI_STATUS status;
>> +
>> +conout = ST->ConOut;
>> +conin = ST->ConIn;
>> +
>> +status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
>> +(void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>> +if (status != EFI_SUCCESS)
>> +coninex = NULL;
>> +
>> cp->c_flags |= C_PRESENTIN | C_PRESENTOUT;
>> }
>>
>> @@ -889,15 +902,7 @@ efi_cons_init(int arg)
>> if (conin != NULL)
>> return (0);
>>
>> -conout = ST->ConOut;
>> -conin = ST->ConIn;
>> -
>> conout->EnableCursor(conout, TRUE);
>> -status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
>> -(void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
>> -if (status != EFI_SUCCESS)
>> -coninex = NULL;
>> -
>> if (efi_cons_update_mode())
>> return (0);
> Hello, Toomas!
>
> I have to return to this revision once again.
>
> Speaking in advance, the problem I'll describe isn't a fatal one. I
> want to find a solution/root cause by myself... well, I had tried to do
> that but failed, therefore, I need some tips from you, if you have free
> time for that.
>
> The loader started to ignore teken.fg_color after r358989.
>
> I like to have green text on black console. Therefore, I have this:
>
> teken.fg_color="green"
Oh cool, at least it is useful for someone:)
I am sorry, yes this is my bug, I somehow missed the second probe and assumed
we do probe only once.. And yes, your analysis is correct, the environment with
callback should be treated carefully.
What probe must do is to set up conin/coninex so the efiserial can use
workaround for buggy SIO, the rest is not that important.
>
> in my /boot/loader.conf. Before r358989 everything worked just like I
> wanted: not only vt(4) had green text on black, but the loader menu
> also. After r358989 vt(4) still renders greeen text on black, but the
> loader doesn't. It use default white on black. The variable is
> assigned but doesn't affect the output:
>
> OK show teken.fg_color
> green
>
> That started to happen after the changes from above: when code from the
> efi_cons_init() was moved to the efi_cons_probe()
> (stand/efi/libefi/efi_console.c). Therefore, if I revert those only
> changes, the loader starts to draw green text on black.
>
> If I read the sources correctly, the cons_probe() function in
> stand/common/console.c calls both those functions. Moreover, the
> efi_cons_probe() is called twice: first time when the cons_probe()
> probes all available consoles, and then when it searches an "online"
> console. And then the cons_probe() calls the efi_cons_init(). I see
> nothing between those calls which may cause the loader to ignore
> teken.fg_color (or any other variable).
>
> I believe that the efi_set_colors() function from
> stand/efi/libefi/efi_console.c is not call being the hook function for
> the teken.fg_color variable. The efi_cons_update_mode() sets the
> efi_set_colors() as the callback for teken.fg_color, but it's never
> called. The only reason for that, according to code of the env_setenv()
> in stand/libsa/environment.c, is that teken.fg_color was already created
> (without the hook function, of course) when the efi_cons_update_mode()
> tries to assign the efi_set_colors() hook. Or, the
> efi_cons_update_mode() failed to allocate the buffer, and, therefore,
> didn't set teken.fg_color at all. And later teken.fg_color is read from
> /boot/loader.conf.
>
> One more evidence that efi_set_colors() is not called: setting
> teken.fg_color from the loader prompt to something incorrect:
>
> OK set teken.fg_color=foobar
>
> doesn't print error message "Allowed values are either ansi color name
> or
Re: svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
On 3/14/2020 11:36 AM, Toomas Soome wrote:
> Author: tsoome
> Date: Sat Mar 14 06:36:03 2020
> New Revision: 358989
> URL: https://svnweb.freebsd.org/changeset/base/358989
>
> Log:
> loader: add comconsole implementation on top of SIO protocol
>
> Provide comconsole on top of SIO for arm platforms (x86 does use bios
> version).
>
> Added:
> head/stand/efi/loader/efiserialio.c (contents, props changed)
> Modified:
> head/stand/efi/libefi/efi_console.c
> head/stand/efi/loader/arch/arm/Makefile.inc
> head/stand/efi/loader/arch/arm64/Makefile.inc
> head/stand/efi/loader/conf.c
> head/stand/efi/loader/main.c
>
> Modified: head/stand/efi/libefi/efi_console.c
> ==
> --- head/stand/efi/libefi/efi_console.c Sat Mar 14 05:57:22 2020
> (r358988)
> +++ head/stand/efi/libefi/efi_console.c Sat Mar 14 06:36:03 2020
> (r358989)
> @@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const void *buf __u
> {
> }
>
> +/*
> + * Set up conin/conout/coninex to make sure we have input ready.
> + */
> static void
> efi_cons_probe(struct console *cp)
> {
> + EFI_STATUS status;
> +
> + conout = ST->ConOut;
> + conin = ST->ConIn;
> +
> + status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
> + (void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> + if (status != EFI_SUCCESS)
> + coninex = NULL;
> +
> cp->c_flags |= C_PRESENTIN | C_PRESENTOUT;
> }
>
> @@ -889,15 +902,7 @@ efi_cons_init(int arg)
> if (conin != NULL)
> return (0);
>
> - conout = ST->ConOut;
> - conin = ST->ConIn;
> -
> conout->EnableCursor(conout, TRUE);
> - status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
> - (void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> - if (status != EFI_SUCCESS)
> - coninex = NULL;
> -
> if (efi_cons_update_mode())
> return (0);
Hello, Toomas!
I have to return to this revision once again.
Speaking in advance, the problem I'll describe isn't a fatal one. I
want to find a solution/root cause by myself... well, I had tried to do
that but failed, therefore, I need some tips from you, if you have free
time for that.
The loader started to ignore teken.fg_color after r358989.
I like to have green text on black console. Therefore, I have this:
teken.fg_color="green"
in my /boot/loader.conf. Before r358989 everything worked just like I
wanted: not only vt(4) had green text on black, but the loader menu
also. After r358989 vt(4) still renders greeen text on black, but the
loader doesn't. It use default white on black. The variable is
assigned but doesn't affect the output:
OK show teken.fg_color
green
That started to happen after the changes from above: when code from the
efi_cons_init() was moved to the efi_cons_probe()
(stand/efi/libefi/efi_console.c). Therefore, if I revert those only
changes, the loader starts to draw green text on black.
If I read the sources correctly, the cons_probe() function in
stand/common/console.c calls both those functions. Moreover, the
efi_cons_probe() is called twice: first time when the cons_probe()
probes all available consoles, and then when it searches an "online"
console. And then the cons_probe() calls the efi_cons_init(). I see
nothing between those calls which may cause the loader to ignore
teken.fg_color (or any other variable).
I believe that the efi_set_colors() function from
stand/efi/libefi/efi_console.c is not call being the hook function for
the teken.fg_color variable. The efi_cons_update_mode() sets the
efi_set_colors() as the callback for teken.fg_color, but it's never
called. The only reason for that, according to code of the env_setenv()
in stand/libsa/environment.c, is that teken.fg_color was already created
(without the hook function, of course) when the efi_cons_update_mode()
tries to assign the efi_set_colors() hook. Or, the
efi_cons_update_mode() failed to allocate the buffer, and, therefore,
didn't set teken.fg_color at all. And later teken.fg_color is read from
/boot/loader.conf.
One more evidence that efi_set_colors() is not called: setting
teken.fg_color from the loader prompt to something incorrect:
OK set teken.fg_color=foobar
doesn't print error message "Allowed values are either ansi color name
or number from range ..."
Thoomas, is ignoring of teken.fg_color by the loader caused by failing
to allocate the buffer within the efi_cons_update_mode()?
>
>
> Modified: head/stand/efi/loader/arch/arm/Makefile.inc
> ==
> --- head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 05:57:22
> 2020(r358988)
> +++ head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 06:36:03
> 2020(r358989)
> @@ -1,6 +1,7 @@
> # $FreeBSD$
>
> SRCS+= exec.c \
> +
svn commit: r358989 - in head/stand/efi: libefi loader loader/arch/arm loader/arch/arm64
Author: tsoome
Date: Sat Mar 14 06:36:03 2020
New Revision: 358989
URL: https://svnweb.freebsd.org/changeset/base/358989
Log:
loader: add comconsole implementation on top of SIO protocol
Provide comconsole on top of SIO for arm platforms (x86 does use bios
version).
Added:
head/stand/efi/loader/efiserialio.c (contents, props changed)
Modified:
head/stand/efi/libefi/efi_console.c
head/stand/efi/loader/arch/arm/Makefile.inc
head/stand/efi/loader/arch/arm64/Makefile.inc
head/stand/efi/loader/conf.c
head/stand/efi/loader/main.c
Modified: head/stand/efi/libefi/efi_console.c
==
--- head/stand/efi/libefi/efi_console.c Sat Mar 14 05:57:22 2020
(r358988)
+++ head/stand/efi/libefi/efi_console.c Sat Mar 14 06:36:03 2020
(r358989)
@@ -377,9 +377,22 @@ efi_cons_respond(void *s __unused, const void *buf __u
{
}
+/*
+ * Set up conin/conout/coninex to make sure we have input ready.
+ */
static void
efi_cons_probe(struct console *cp)
{
+ EFI_STATUS status;
+
+ conout = ST->ConOut;
+ conin = ST->ConIn;
+
+ status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
+ (void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+ if (status != EFI_SUCCESS)
+ coninex = NULL;
+
cp->c_flags |= C_PRESENTIN | C_PRESENTOUT;
}
@@ -889,15 +902,7 @@ efi_cons_init(int arg)
if (conin != NULL)
return (0);
- conout = ST->ConOut;
- conin = ST->ConIn;
-
conout->EnableCursor(conout, TRUE);
- status = BS->OpenProtocol(ST->ConsoleInHandle, _input_ex_guid,
- (void **), IH, NULL, EFI_OPEN_PROTOCOL_GET_PROTOCOL);
- if (status != EFI_SUCCESS)
- coninex = NULL;
-
if (efi_cons_update_mode())
return (0);
Modified: head/stand/efi/loader/arch/arm/Makefile.inc
==
--- head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 05:57:22 2020
(r358988)
+++ head/stand/efi/loader/arch/arm/Makefile.inc Sat Mar 14 06:36:03 2020
(r358989)
@@ -1,6 +1,7 @@
# $FreeBSD$
SRCS+= exec.c \
+ efiserialio.c \
start.S
HAVE_FDT=yes
Modified: head/stand/efi/loader/arch/arm64/Makefile.inc
==
--- head/stand/efi/loader/arch/arm64/Makefile.inc Sat Mar 14 05:57:22
2020(r358988)
+++ head/stand/efi/loader/arch/arm64/Makefile.inc Sat Mar 14 06:36:03
2020(r358989)
@@ -3,6 +3,7 @@
HAVE_FDT=yes
SRCS+= exec.c \
+ efiserialio.c \
start.S
.PATH: ${BOOTSRC}/arm64/libarm64
Modified: head/stand/efi/loader/conf.c
==
--- head/stand/efi/loader/conf.cSat Mar 14 05:57:22 2020
(r358988)
+++ head/stand/efi/loader/conf.cSat Mar 14 06:36:03 2020
(r358989)
@@ -73,16 +73,16 @@ struct netif_driver *netif_drivers[] = {
};
extern struct console efi_console;
-#if defined(__amd64__) || defined(__i386__)
extern struct console comconsole;
+#if defined(__amd64__) || defined(__i386__)
extern struct console nullconsole;
extern struct console spinconsole;
#endif
struct console *consoles[] = {
_console,
-#if defined(__amd64__) || defined(__i386__)
,
+#if defined(__amd64__) || defined(__i386__)
,
,
#endif
Added: head/stand/efi/loader/efiserialio.c
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/stand/efi/loader/efiserialio.c Sat Mar 14 06:36:03 2020
(r358989)
@@ -0,0 +1,518 @@
+/*-
+ * Copyright (c) 1998 Michael Smith (msm...@freebsd.org)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
