[BUG] sandbox: './u-boot -l ' fails

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

Hello Simon,

when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run out
of the box?

$ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb

U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39 +0200)

Model: sandbox
DRAM:  128 MiB

Warning: host_lo MAC addresses don't match:
Address in ROM is               26:4b:ca:6c:98:f4
Address in environment is       00:00:11:22:33:44

Warning: host_virbr0 MAC addresses don't match:
Address in ROM is               ee:3e:c9:ce:1f:9c
Address in environment is       00:00:11:22:33:45

Warning: host_docker0 MAC addresses don't match:
Address in ROM is               c2:85:07:7b:9a:18
Address in environment is       00:00:11:22:33:46
WDT:   Not found!
MMC:

No output after this point.

The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.

CONFIG_SANDBOX_SDL=y

SDL_InitSubSystem() never returns. It is looping somewhere in U-Boot's
__serial_getc(). I wonder how it gets there without returning from the
function.

I compiled SDL2.cpp from
https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
with

g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test

and it runs fine showing an X11 windows with red background.

So there seems to be no general problem with the SDL2 library.

Best regards

Heinrich

[BUG] sandbox: './u-boot -l ' fails

[Simon Glass]

Hi Heinrich,

On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> Hello Simon,
>
> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run out
> of the box?
>
> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb

For the record you should be able to use -D to get the same effect as
your -d above.

>
> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39 +0200)
>
> Model: sandbox
> DRAM:  128 MiB
>
> Warning: host_lo MAC addresses don't match:
> Address in ROM is               26:4b:ca:6c:98:f4
> Address in environment is       00:00:11:22:33:44
>
> Warning: host_virbr0 MAC addresses don't match:
> Address in ROM is               ee:3e:c9:ce:1f:9c
> Address in environment is       00:00:11:22:33:45
>
> Warning: host_docker0 MAC addresses don't match:
> Address in ROM is               c2:85:07:7b:9a:18
> Address in environment is       00:00:11:22:33:46
> WDT:   Not found!
> MMC:
>
> No output after this point.
>
> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>
> CONFIG_SANDBOX_SDL=y
>
> SDL_InitSubSystem() never returns. It is looping somewhere in U-Boot's
> __serial_getc(). I wonder how it gets there without returning from the
> function.
>
> I compiled SDL2.cpp from
> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
> with
>
> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>
> and it runs fine showing an X11 windows with red background.
>
> So there seems to be no general problem with the SDL2 library.

I hit this myself on another computer and it turned out to be that SDL
defined getc(), as does U-Boot, and things get confused. At least I
think it is getc.

I hacked around with changing the name of getc (I think it was getc)
in U-Boot and the problem went away.

Regards,
Simon

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
>Hi Heinrich,
>
>On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
>wrote:
>>
>> Hello Simon,
>>
>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
>out
>> of the box?
>>
>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
>
>For the record you should be able to use -D to get the same effect as
>your -d above.
>
>>
>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
>+0200)
>>
>> Model: sandbox
>> DRAM:  128 MiB
>>
>> Warning: host_lo MAC addresses don't match:
>> Address in ROM is               26:4b:ca:6c:98:f4
>> Address in environment is       00:00:11:22:33:44
>>
>> Warning: host_virbr0 MAC addresses don't match:
>> Address in ROM is               ee:3e:c9:ce:1f:9c
>> Address in environment is       00:00:11:22:33:45
>>
>> Warning: host_docker0 MAC addresses don't match:
>> Address in ROM is               c2:85:07:7b:9a:18
>> Address in environment is       00:00:11:22:33:46
>> WDT:   Not found!
>> MMC:
>>
>> No output after this point.
>>
>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>>
>> CONFIG_SANDBOX_SDL=y
>>
>> SDL_InitSubSystem() never returns. It is looping somewhere in
>U-Boot's
>> __serial_getc(). I wonder how it gets there without returning from
>the
>> function.
>>
>> I compiled SDL2.cpp from
>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
>> with
>>
>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>>
>> and it runs fine showing an X11 windows with red background.
>>
>> So there seems to be no general problem with the SDL2 library.
>
>I hit this myself on another computer and it turned out to be that SDL
>defined getc(), as does U-Boot, and things get confused. At least I
>think it is getc.
>
>I hacked around with changing the name of getc (I think it was getc)
>in U-Boot and the problem went away.

Should we include a patched SDL2 with U-Boot for static linking?

>
>Regards,
>Simon

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

On 28.09.20 06:46, Heinrich Schuchardt wrote:
> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
>> Hi Heinrich,
>>
>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
>> wrote:
>>>
>>> Hello Simon,
>>>
>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
>> out
>>> of the box?
>>>
>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
>>
>> For the record you should be able to use -D to get the same effect as
>> your -d above.
>>
>>>
>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
>> +0200)
>>>
>>> Model: sandbox
>>> DRAM:  128 MiB
>>>
>>> Warning: host_lo MAC addresses don't match:
>>> Address in ROM is               26:4b:ca:6c:98:f4
>>> Address in environment is       00:00:11:22:33:44
>>>
>>> Warning: host_virbr0 MAC addresses don't match:
>>> Address in ROM is               ee:3e:c9:ce:1f:9c
>>> Address in environment is       00:00:11:22:33:45
>>>
>>> Warning: host_docker0 MAC addresses don't match:
>>> Address in ROM is               c2:85:07:7b:9a:18
>>> Address in environment is       00:00:11:22:33:46
>>> WDT:   Not found!
>>> MMC:
>>>
>>> No output after this point.
>>>
>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>>>
>>> CONFIG_SANDBOX_SDL=y
>>>
>>> SDL_InitSubSystem() never returns. It is looping somewhere in
>> U-Boot's
>>> __serial_getc(). I wonder how it gets there without returning from
>> the
>>> function.
>>>
>>> I compiled SDL2.cpp from
>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
>>> with
>>>
>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>>>
>>> and it runs fine showing an X11 windows with red background.
>>>
>>> So there seems to be no general problem with the SDL2 library.
>>
>> I hit this myself on another computer and it turned out to be that SDL
>> defined getc(), as does U-Boot, and things get confused. At least I
>> think it is getc.
>>
>> I hacked around with changing the name of getc (I think it was getc)
>> in U-Boot and the problem went away.
>
> Should we include a patched SDL2 with U-Boot for static linking?
>

I cannot find a symbol getc() nor a reference to it in the SDL
repository. getc() is defined in stdio.h.

Our getc() takes no argument, while the stdio one wants a FILE *.

But changing the U-Boot definition to "int getc(void *)" does not solve
the issue.

Best regards

Heinrich

[BUG] sandbox: './u-boot -l ' fails

[Simon Glass]

Hi Heinrich,

On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 28.09.20 06:46, Heinrich Schuchardt wrote:
> > Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >> Hi Heinrich,
> >>
> >> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
> >> wrote:
> >>>
> >>> Hello Simon,
> >>>
> >>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
> >> out
> >>> of the box?
> >>>
> >>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
> >>
> >> For the record you should be able to use -D to get the same effect as
> >> your -d above.
> >>
> >>>
> >>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
> >> +0200)
> >>>
> >>> Model: sandbox
> >>> DRAM:  128 MiB
> >>>
> >>> Warning: host_lo MAC addresses don't match:
> >>> Address in ROM is               26:4b:ca:6c:98:f4
> >>> Address in environment is       00:00:11:22:33:44
> >>>
> >>> Warning: host_virbr0 MAC addresses don't match:
> >>> Address in ROM is               ee:3e:c9:ce:1f:9c
> >>> Address in environment is       00:00:11:22:33:45
> >>>
> >>> Warning: host_docker0 MAC addresses don't match:
> >>> Address in ROM is               c2:85:07:7b:9a:18
> >>> Address in environment is       00:00:11:22:33:46
> >>> WDT:   Not found!
> >>> MMC:
> >>>
> >>> No output after this point.
> >>>
> >>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
> >>>
> >>> CONFIG_SANDBOX_SDL=y
> >>>
> >>> SDL_InitSubSystem() never returns. It is looping somewhere in
> >> U-Boot's
> >>> __serial_getc(). I wonder how it gets there without returning from
> >> the
> >>> function.
> >>>
> >>> I compiled SDL2.cpp from
> >>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
> >>> with
> >>>
> >>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
> >>>
> >>> and it runs fine showing an X11 windows with red background.
> >>>
> >>> So there seems to be no general problem with the SDL2 library.
> >>
> >> I hit this myself on another computer and it turned out to be that SDL
> >> defined getc(), as does U-Boot, and things get confused. At least I
> >> think it is getc.
> >>
> >> I hacked around with changing the name of getc (I think it was getc)
> >> in U-Boot and the problem went away.
> >
> > Should we include a patched SDL2 with U-Boot for static linking?
> >
>
> I cannot find a symbol getc() nor a reference to it in the SDL
> repository. getc() is defined in stdio.h.
>
> Our getc() takes no argument, while the stdio one wants a FILE *.
>
> But changing the U-Boot definition to "int getc(void *)" does not solve
> the issue.

I just tried it on the machine where it doesn't work:

$ gdb --args /tmp/b/sandbox/u-boot -l -D
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /tmp/b/sandbox/u-boot...
(gdb) br getc
Breakpoint 1 at 0x5b6d6: getc. (2 locations)
(gdb) r
Starting program: /tmp/b/sandbox/u-boot -l -D
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".


U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)

Model: sandbox
DRAM:  128 MiB

Warning: host_lo MAC addresses don't match:
Address in ROM is 1a:34:9b:48:aa:53
Address in environment is 00:00:11:22:33:44
WDT:   Not found!
MMC:

Breakpoint 1, getc () at
/home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
414 if (!gd->have_console)
(gdb) up
#1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb)


So it seems that it is libX11 causing the problem.

I don't think the best fix is to remove getc() from that library,
although I do wonder if it is a bug. Renaming the symbol in U-Boot
with #define (only on sandbox) might be one option.

Regards,
Simon

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

On 28.09.20 15:22, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 28.09.20 06:46, Heinrich Schuchardt wrote:
>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
>>>> Hi Heinrich,
>>>>
>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>> wrote:
>>>>>
>>>>> Hello Simon,
>>>>>
>>>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
>>>> out
>>>>> of the box?
>>>>>
>>>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
>>>>
>>>> For the record you should be able to use -D to get the same effect as
>>>> your -d above.
>>>>
>>>>>
>>>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
>>>> +0200)
>>>>>
>>>>> Model: sandbox
>>>>> DRAM:  128 MiB
>>>>>
>>>>> Warning: host_lo MAC addresses don't match:
>>>>> Address in ROM is               26:4b:ca:6c:98:f4
>>>>> Address in environment is       00:00:11:22:33:44
>>>>>
>>>>> Warning: host_virbr0 MAC addresses don't match:
>>>>> Address in ROM is               ee:3e:c9:ce:1f:9c
>>>>> Address in environment is       00:00:11:22:33:45
>>>>>
>>>>> Warning: host_docker0 MAC addresses don't match:
>>>>> Address in ROM is               c2:85:07:7b:9a:18
>>>>> Address in environment is       00:00:11:22:33:46
>>>>> WDT:   Not found!
>>>>> MMC:
>>>>>
>>>>> No output after this point.
>>>>>
>>>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>>>>>
>>>>> CONFIG_SANDBOX_SDL=y
>>>>>
>>>>> SDL_InitSubSystem() never returns. It is looping somewhere in
>>>> U-Boot's
>>>>> __serial_getc(). I wonder how it gets there without returning from
>>>> the
>>>>> function.
>>>>>
>>>>> I compiled SDL2.cpp from
>>>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
>>>>> with
>>>>>
>>>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>>>>>
>>>>> and it runs fine showing an X11 windows with red background.
>>>>>
>>>>> So there seems to be no general problem with the SDL2 library.
>>>>
>>>> I hit this myself on another computer and it turned out to be that SDL
>>>> defined getc(), as does U-Boot, and things get confused. At least I
>>>> think it is getc.
>>>>
>>>> I hacked around with changing the name of getc (I think it was getc)
>>>> in U-Boot and the problem went away.
>>>
>>> Should we include a patched SDL2 with U-Boot for static linking?
>>>
>>
>> I cannot find a symbol getc() nor a reference to it in the SDL
>> repository. getc() is defined in stdio.h.
>>
>> Our getc() takes no argument, while the stdio one wants a FILE *.
>>
>> But changing the U-Boot definition to "int getc(void *)" does not solve
>> the issue.
>
> I just tried it on the machine where it doesn't work:
>
> $ gdb --args /tmp/b/sandbox/u-boot -l -D
> GNU gdb (Debian 9.2-1) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /tmp/b/sandbox/u-boot...
> (gdb) br getc
> Breakpoint 1 at 0x5b6d6: getc. (2 locations)
> (gdb) r
> Starting program: /tmp/b/sandbox/u-boot -l -D
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>
>
> U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)
>
> Model: sandbox
> DRAM:  128 MiB
>
> Warning: host_lo MAC addresses don't match:
> Address in ROM is 1a:34:9b:48:aa:53
> Address in environment is 00:00:11:22:33:44
> WDT:   Not found!
> MMC:
>
> Breakpoint 1, getc () at
> /home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
> 414 if (!gd->have_console)
> (gdb) up
> #1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
> (gdb)
>
>
> So it seems that it is libX11 causing the problem.
>
> I don't think the best fix is to remove getc() from that library,
> although I do wonder if it is a bug. Renaming the symbol in U-Boot
> with #define (only on sandbox) might be one option.
>
> Regards,
> Simon
>

#define getc _uboot_getc

is what I tried but it runs you into the trouble that many other symbols
contain the getc substring.

As we always try to use the same definition in U-Boot as in glibc we
should really replace getc() by another symbol, e.g. chget() so that we
avoid confusion.

Best regards

Heinrich

[BUG] sandbox: './u-boot -l ' fails

[Simon Glass]

Hi Heinrich,

On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 28.09.20 15:22, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> On 28.09.20 06:46, Heinrich Schuchardt wrote:
> >>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >>>> Hi Heinrich,
> >>>>
> >>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>> wrote:
> >>>>>
> >>>>> Hello Simon,
> >>>>>
> >>>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
> >>>> out
> >>>>> of the box?
> >>>>>
> >>>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
> >>>>
> >>>> For the record you should be able to use -D to get the same effect as
> >>>> your -d above.
> >>>>
> >>>>>
> >>>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
> >>>> +0200)
> >>>>>
> >>>>> Model: sandbox
> >>>>> DRAM:  128 MiB
> >>>>>
> >>>>> Warning: host_lo MAC addresses don't match:
> >>>>> Address in ROM is               26:4b:ca:6c:98:f4
> >>>>> Address in environment is       00:00:11:22:33:44
> >>>>>
> >>>>> Warning: host_virbr0 MAC addresses don't match:
> >>>>> Address in ROM is               ee:3e:c9:ce:1f:9c
> >>>>> Address in environment is       00:00:11:22:33:45
> >>>>>
> >>>>> Warning: host_docker0 MAC addresses don't match:
> >>>>> Address in ROM is               c2:85:07:7b:9a:18
> >>>>> Address in environment is       00:00:11:22:33:46
> >>>>> WDT:   Not found!
> >>>>> MMC:
> >>>>>
> >>>>> No output after this point.
> >>>>>
> >>>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
> >>>>>
> >>>>> CONFIG_SANDBOX_SDL=y
> >>>>>
> >>>>> SDL_InitSubSystem() never returns. It is looping somewhere in
> >>>> U-Boot's
> >>>>> __serial_getc(). I wonder how it gets there without returning from
> >>>> the
> >>>>> function.
> >>>>>
> >>>>> I compiled SDL2.cpp from
> >>>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
> >>>>> with
> >>>>>
> >>>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
> >>>>>
> >>>>> and it runs fine showing an X11 windows with red background.
> >>>>>
> >>>>> So there seems to be no general problem with the SDL2 library.
> >>>>
> >>>> I hit this myself on another computer and it turned out to be that SDL
> >>>> defined getc(), as does U-Boot, and things get confused. At least I
> >>>> think it is getc.
> >>>>
> >>>> I hacked around with changing the name of getc (I think it was getc)
> >>>> in U-Boot and the problem went away.
> >>>
> >>> Should we include a patched SDL2 with U-Boot for static linking?
> >>>
> >>
> >> I cannot find a symbol getc() nor a reference to it in the SDL
> >> repository. getc() is defined in stdio.h.
> >>
> >> Our getc() takes no argument, while the stdio one wants a FILE *.
> >>
> >> But changing the U-Boot definition to "int getc(void *)" does not solve
> >> the issue.
> >
> > I just tried it on the machine where it doesn't work:
> >
> > $ gdb --args /tmp/b/sandbox/u-boot -l -D
> > GNU gdb (Debian 9.2-1) 9.2
> > Copyright (C) 2020 Free Software Foundation, Inc.
> > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> > This is free software: you are free to change and redistribute it.
> > There is NO WARRANTY, to the extent permitted by law.
> > Type "show copying" and "show warranty" for details.
> > This GDB was configured as "x86_64-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > <http://www.gnu.org/software/gdb/bugs/>.
> > Find the GDB manual and other documentation resources online at:
> >     <http://www.gnu.org/software/gdb/documentation/>.
> >
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from /tmp/b/sandbox/u-boot...
> > (gdb) br getc
> > Breakpoint 1 at 0x5b6d6: getc. (2 locations)
> > (gdb) r
> > Starting program: /tmp/b/sandbox/u-boot -l -D
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >
> >
> > U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)
> >
> > Model: sandbox
> > DRAM:  128 MiB
> >
> > Warning: host_lo MAC addresses don't match:
> > Address in ROM is 1a:34:9b:48:aa:53
> > Address in environment is 00:00:11:22:33:44
> > WDT:   Not found!
> > MMC:
> >
> > Breakpoint 1, getc () at
> > /home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
> > 414 if (!gd->have_console)
> > (gdb) up
> > #1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
> > (gdb)
> >
> >
> > So it seems that it is libX11 causing the problem.
> >
> > I don't think the best fix is to remove getc() from that library,
> > although I do wonder if it is a bug. Renaming the symbol in U-Boot
> > with #define (only on sandbox) might be one option.
> >
> > Regards,
> > Simon
> >
>
> #define getc _uboot_getc
>
> is what I tried but it runs you into the trouble that many other symbols
> contain the getc substring.
>
> As we always try to use the same definition in U-Boot as in glibc we
> should really replace getc() by another symbol, e.g. chget() so that we
> avoid confusion.

Well the first question is whether this is a bug with x11.

I'm not sure that renaming is a good idea. getc() is a pretty standard name.

Try

#define getc(x) _sandbox_get(x)

which might get you closer.

Regards,
Simon

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

On 9/28/20 3:42 PM, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 28.09.20 15:22, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>
>>>> On 28.09.20 06:46, Heinrich Schuchardt wrote:
>>>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
>>>>>> Hi Heinrich,
>>>>>>
>>>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hello Simon,
>>>>>>>
>>>>>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
>>>>>> out
>>>>>>> of the box?
>>>>>>>
>>>>>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
>>>>>>
>>>>>> For the record you should be able to use -D to get the same effect as
>>>>>> your -d above.
>>>>>>
>>>>>>>
>>>>>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
>>>>>> +0200)
>>>>>>>
>>>>>>> Model: sandbox
>>>>>>> DRAM:  128 MiB
>>>>>>>
>>>>>>> Warning: host_lo MAC addresses don't match:
>>>>>>> Address in ROM is               26:4b:ca:6c:98:f4
>>>>>>> Address in environment is       00:00:11:22:33:44
>>>>>>>
>>>>>>> Warning: host_virbr0 MAC addresses don't match:
>>>>>>> Address in ROM is               ee:3e:c9:ce:1f:9c
>>>>>>> Address in environment is       00:00:11:22:33:45
>>>>>>>
>>>>>>> Warning: host_docker0 MAC addresses don't match:
>>>>>>> Address in ROM is               c2:85:07:7b:9a:18
>>>>>>> Address in environment is       00:00:11:22:33:46
>>>>>>> WDT:   Not found!
>>>>>>> MMC:
>>>>>>>
>>>>>>> No output after this point.
>>>>>>>
>>>>>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>>>>>>>
>>>>>>> CONFIG_SANDBOX_SDL=y
>>>>>>>
>>>>>>> SDL_InitSubSystem() never returns. It is looping somewhere in
>>>>>> U-Boot's
>>>>>>> __serial_getc(). I wonder how it gets there without returning from
>>>>>> the
>>>>>>> function.
>>>>>>>
>>>>>>> I compiled SDL2.cpp from
>>>>>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
>>>>>>> with
>>>>>>>
>>>>>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>>>>>>>
>>>>>>> and it runs fine showing an X11 windows with red background.
>>>>>>>
>>>>>>> So there seems to be no general problem with the SDL2 library.
>>>>>>
>>>>>> I hit this myself on another computer and it turned out to be that SDL
>>>>>> defined getc(), as does U-Boot, and things get confused. At least I
>>>>>> think it is getc.
>>>>>>
>>>>>> I hacked around with changing the name of getc (I think it was getc)
>>>>>> in U-Boot and the problem went away.
>>>>>
>>>>> Should we include a patched SDL2 with U-Boot for static linking?
>>>>>
>>>>
>>>> I cannot find a symbol getc() nor a reference to it in the SDL
>>>> repository. getc() is defined in stdio.h.
>>>>
>>>> Our getc() takes no argument, while the stdio one wants a FILE *.
>>>>
>>>> But changing the U-Boot definition to "int getc(void *)" does not solve
>>>> the issue.
>>>
>>> I just tried it on the machine where it doesn't work:
>>>
>>> $ gdb --args /tmp/b/sandbox/u-boot -l -D
>>> GNU gdb (Debian 9.2-1) 9.2
>>> Copyright (C) 2020 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>>     <http://www.gnu.org/software/gdb/documentation/>.
>>>
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from /tmp/b/sandbox/u-boot...
>>> (gdb) br getc
>>> Breakpoint 1 at 0x5b6d6: getc. (2 locations)
>>> (gdb) r
>>> Starting program: /tmp/b/sandbox/u-boot -l -D
>>> [Thread debugging using libthread_db enabled]
>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>>
>>>
>>> U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)
>>>
>>> Model: sandbox
>>> DRAM:  128 MiB
>>>
>>> Warning: host_lo MAC addresses don't match:
>>> Address in ROM is 1a:34:9b:48:aa:53
>>> Address in environment is 00:00:11:22:33:44
>>> WDT:   Not found!
>>> MMC:
>>>
>>> Breakpoint 1, getc () at
>>> /home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
>>> 414 if (!gd->have_console)
>>> (gdb) up
>>> #1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
>>> (gdb)
>>>
>>>
>>> So it seems that it is libX11 causing the problem.
>>>
>>> I don't think the best fix is to remove getc() from that library,
>>> although I do wonder if it is a bug. Renaming the symbol in U-Boot
>>> with #define (only on sandbox) might be one option.
>>>
>>> Regards,
>>> Simon
>>>
>>
>> #define getc _uboot_getc
>>
>> is what I tried but it runs you into the trouble that many other symbols
>> contain the getc substring.
>>
>> As we always try to use the same definition in U-Boot as in glibc we
>> should really replace getc() by another symbol, e.g. chget() so that we
>> avoid confusion.
>
> Well the first question is whether this is a bug with x11.
>
> I'm not sure that renaming is a good idea. getc() is a pretty standard name.
>
> Try
>
> #define getc(x) _sandbox_get(x)
>
> which might get you closer.
>
> Regards,
> Simon
>
https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commit/7b302bedb21f94b9eb619cb38ef985f7bbb9be1f

seems to fix the crash. I get an output window.

But there are still problems:

* The shift key does not work on the keyboard.
* The output is black and white only.

What I would like to have is a 32bit color framebuffer on which I can
draw with the EFI graphical output protocol.

Best regards

Heinrich

[BUG] sandbox: './u-boot -l ' fails

[Simon Glass]

Hi Heinrich,

On Mon, 28 Sep 2020 at 15:23, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 9/28/20 3:42 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>
> >> On 28.09.20 15:22, Simon Glass wrote:
> >>> Hi Heinrich,
> >>>
> >>> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> >>>>
> >>>> On 28.09.20 06:46, Heinrich Schuchardt wrote:
> >>>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
> >>>>>> Hi Heinrich,
> >>>>>>
> >>>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hello Simon,
> >>>>>>>
> >>>>>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
> >>>>>> out
> >>>>>>> of the box?
> >>>>>>>
> >>>>>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
> >>>>>>
> >>>>>> For the record you should be able to use -D to get the same effect as
> >>>>>> your -d above.
> >>>>>>
> >>>>>>>
> >>>>>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
> >>>>>> +0200)
> >>>>>>>
> >>>>>>> Model: sandbox
> >>>>>>> DRAM:  128 MiB
> >>>>>>>
> >>>>>>> Warning: host_lo MAC addresses don't match:
> >>>>>>> Address in ROM is               26:4b:ca:6c:98:f4
> >>>>>>> Address in environment is       00:00:11:22:33:44
> >>>>>>>
> >>>>>>> Warning: host_virbr0 MAC addresses don't match:
> >>>>>>> Address in ROM is               ee:3e:c9:ce:1f:9c
> >>>>>>> Address in environment is       00:00:11:22:33:45
> >>>>>>>
> >>>>>>> Warning: host_docker0 MAC addresses don't match:
> >>>>>>> Address in ROM is               c2:85:07:7b:9a:18
> >>>>>>> Address in environment is       00:00:11:22:33:46
> >>>>>>> WDT:   Not found!
> >>>>>>> MMC:
> >>>>>>>
> >>>>>>> No output after this point.
> >>>>>>>
> >>>>>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
> >>>>>>>
> >>>>>>> CONFIG_SANDBOX_SDL=y
> >>>>>>>
> >>>>>>> SDL_InitSubSystem() never returns. It is looping somewhere in
> >>>>>> U-Boot's
> >>>>>>> __serial_getc(). I wonder how it gets there without returning from
> >>>>>> the
> >>>>>>> function.
> >>>>>>>
> >>>>>>> I compiled SDL2.cpp from
> >>>>>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
> >>>>>>> with
> >>>>>>>
> >>>>>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
> >>>>>>>
> >>>>>>> and it runs fine showing an X11 windows with red background.
> >>>>>>>
> >>>>>>> So there seems to be no general problem with the SDL2 library.
> >>>>>>
> >>>>>> I hit this myself on another computer and it turned out to be that SDL
> >>>>>> defined getc(), as does U-Boot, and things get confused. At least I
> >>>>>> think it is getc.
> >>>>>>
> >>>>>> I hacked around with changing the name of getc (I think it was getc)
> >>>>>> in U-Boot and the problem went away.
> >>>>>
> >>>>> Should we include a patched SDL2 with U-Boot for static linking?
> >>>>>
> >>>>
> >>>> I cannot find a symbol getc() nor a reference to it in the SDL
> >>>> repository. getc() is defined in stdio.h.
> >>>>
> >>>> Our getc() takes no argument, while the stdio one wants a FILE *.
> >>>>
> >>>> But changing the U-Boot definition to "int getc(void *)" does not solve
> >>>> the issue.
> >>>
> >>> I just tried it on the machine where it doesn't work:
> >>>
> >>> $ gdb --args /tmp/b/sandbox/u-boot -l -D
> >>> GNU gdb (Debian 9.2-1) 9.2
> >>> Copyright (C) 2020 Free Software Foundation, Inc.
> >>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> >>> This is free software: you are free to change and redistribute it.
> >>> There is NO WARRANTY, to the extent permitted by law.
> >>> Type "show copying" and "show warranty" for details.
> >>> This GDB was configured as "x86_64-linux-gnu".
> >>> Type "show configuration" for configuration details.
> >>> For bug reporting instructions, please see:
> >>> <http://www.gnu.org/software/gdb/bugs/>.
> >>> Find the GDB manual and other documentation resources online at:
> >>>     <http://www.gnu.org/software/gdb/documentation/>.
> >>>
> >>> For help, type "help".
> >>> Type "apropos word" to search for commands related to "word"...
> >>> Reading symbols from /tmp/b/sandbox/u-boot...
> >>> (gdb) br getc
> >>> Breakpoint 1 at 0x5b6d6: getc. (2 locations)
> >>> (gdb) r
> >>> Starting program: /tmp/b/sandbox/u-boot -l -D
> >>> [Thread debugging using libthread_db enabled]
> >>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >>>
> >>>
> >>> U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)
> >>>
> >>> Model: sandbox
> >>> DRAM:  128 MiB
> >>>
> >>> Warning: host_lo MAC addresses don't match:
> >>> Address in ROM is 1a:34:9b:48:aa:53
> >>> Address in environment is 00:00:11:22:33:44
> >>> WDT:   Not found!
> >>> MMC:
> >>>
> >>> Breakpoint 1, getc () at
> >>> /home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
> >>> 414 if (!gd->have_console)
> >>> (gdb) up
> >>> #1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
> >>> (gdb)
> >>>
> >>>
> >>> So it seems that it is libX11 causing the problem.
> >>>
> >>> I don't think the best fix is to remove getc() from that library,
> >>> although I do wonder if it is a bug. Renaming the symbol in U-Boot
> >>> with #define (only on sandbox) might be one option.
> >>>
> >>> Regards,
> >>> Simon
> >>>
> >>
> >> #define getc _uboot_getc
> >>
> >> is what I tried but it runs you into the trouble that many other symbols
> >> contain the getc substring.
> >>
> >> As we always try to use the same definition in U-Boot as in glibc we
> >> should really replace getc() by another symbol, e.g. chget() so that we
> >> avoid confusion.
> >
> > Well the first question is whether this is a bug with x11.
> >
> > I'm not sure that renaming is a good idea. getc() is a pretty standard name.
> >
> > Try
> >
> > #define getc(x) _sandbox_get(x)
> >
> > which might get you closer.
> >
> > Regards,
> > Simon
> >
> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commit/7b302bedb21f94b9eb619cb38ef985f7bbb9be1f
>
> seems to fix the crash. I get an output window.
>
> But there are still problems:
>
> * The shift key does not work on the keyboard.

What is shift supposed to do? Do you mean you cannot get capital
letters or symbols?

> * The output is black and white only.

That's odd. I haven't tried it recently but earlier in the year I was
able to write a colour BMP.

>
> What I would like to have is a 32bit color framebuffer on which I can
> draw with the EFI graphical output protocol.

Well that should work. I adds Nuklear support a while back and
everything seemed good. Perhaps there has been a regression? But there
is a test for colour bitmaps. Perhaps it is just the SDL display side
which is not working?

I just tried this and got a colour image:

=> host load hostfs - 0 tools/logos/denx.bmp
=> bmp display 0

Regards,
Simon

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

On 9/29/20 12:19 AM, Simon Glass wrote:
> Hi Heinrich,
>
> On Mon, 28 Sep 2020 at 15:23, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>
>> On 9/28/20 3:42 PM, Simon Glass wrote:
>>> Hi Heinrich,
>>>
>>> On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>
>>>> On 28.09.20 15:22, Simon Glass wrote:
>>>>> Hi Heinrich,
>>>>>
>>>>> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>>>
>>>>>> On 28.09.20 06:46, Heinrich Schuchardt wrote:
>>>>>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
>>>>>>>> Hi Heinrich,
>>>>>>>>
>>>>>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello Simon,
>>>>>>>>>
>>>>>>>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
>>>>>>>> out
>>>>>>>>> of the box?
>>>>>>>>>
>>>>>>>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
>>>>>>>>
>>>>>>>> For the record you should be able to use -D to get the same effect as
>>>>>>>> your -d above.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
>>>>>>>> +0200)
>>>>>>>>>
>>>>>>>>> Model: sandbox
>>>>>>>>> DRAM:  128 MiB
>>>>>>>>>
>>>>>>>>> Warning: host_lo MAC addresses don't match:
>>>>>>>>> Address in ROM is               26:4b:ca:6c:98:f4
>>>>>>>>> Address in environment is       00:00:11:22:33:44
>>>>>>>>>
>>>>>>>>> Warning: host_virbr0 MAC addresses don't match:
>>>>>>>>> Address in ROM is               ee:3e:c9:ce:1f:9c
>>>>>>>>> Address in environment is       00:00:11:22:33:45
>>>>>>>>>
>>>>>>>>> Warning: host_docker0 MAC addresses don't match:
>>>>>>>>> Address in ROM is               c2:85:07:7b:9a:18
>>>>>>>>> Address in environment is       00:00:11:22:33:46
>>>>>>>>> WDT:   Not found!
>>>>>>>>> MMC:
>>>>>>>>>
>>>>>>>>> No output after this point.
>>>>>>>>>
>>>>>>>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>>>>>>>>>
>>>>>>>>> CONFIG_SANDBOX_SDL=y
>>>>>>>>>
>>>>>>>>> SDL_InitSubSystem() never returns. It is looping somewhere in
>>>>>>>> U-Boot's
>>>>>>>>> __serial_getc(). I wonder how it gets there without returning from
>>>>>>>> the
>>>>>>>>> function.
>>>>>>>>>
>>>>>>>>> I compiled SDL2.cpp from
>>>>>>>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
>>>>>>>>> with
>>>>>>>>>
>>>>>>>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>>>>>>>>>
>>>>>>>>> and it runs fine showing an X11 windows with red background.
>>>>>>>>>
>>>>>>>>> So there seems to be no general problem with the SDL2 library.
>>>>>>>>
>>>>>>>> I hit this myself on another computer and it turned out to be that SDL
>>>>>>>> defined getc(), as does U-Boot, and things get confused. At least I
>>>>>>>> think it is getc.
>>>>>>>>
>>>>>>>> I hacked around with changing the name of getc (I think it was getc)
>>>>>>>> in U-Boot and the problem went away.
>>>>>>>
>>>>>>> Should we include a patched SDL2 with U-Boot for static linking?
>>>>>>>
>>>>>>
>>>>>> I cannot find a symbol getc() nor a reference to it in the SDL
>>>>>> repository. getc() is defined in stdio.h.
>>>>>>
>>>>>> Our getc() takes no argument, while the stdio one wants a FILE *.
>>>>>>
>>>>>> But changing the U-Boot definition to "int getc(void *)" does not solve
>>>>>> the issue.
>>>>>
>>>>> I just tried it on the machine where it doesn't work:
>>>>>
>>>>> $ gdb --args /tmp/b/sandbox/u-boot -l -D
>>>>> GNU gdb (Debian 9.2-1) 9.2
>>>>> Copyright (C) 2020 Free Software Foundation, Inc.
>>>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>>>> This is free software: you are free to change and redistribute it.
>>>>> There is NO WARRANTY, to the extent permitted by law.
>>>>> Type "show copying" and "show warranty" for details.
>>>>> This GDB was configured as "x86_64-linux-gnu".
>>>>> Type "show configuration" for configuration details.
>>>>> For bug reporting instructions, please see:
>>>>> <http://www.gnu.org/software/gdb/bugs/>.
>>>>> Find the GDB manual and other documentation resources online at:
>>>>>     <http://www.gnu.org/software/gdb/documentation/>.
>>>>>
>>>>> For help, type "help".
>>>>> Type "apropos word" to search for commands related to "word"...
>>>>> Reading symbols from /tmp/b/sandbox/u-boot...
>>>>> (gdb) br getc
>>>>> Breakpoint 1 at 0x5b6d6: getc. (2 locations)
>>>>> (gdb) r
>>>>> Starting program: /tmp/b/sandbox/u-boot -l -D
>>>>> [Thread debugging using libthread_db enabled]
>>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>>>>
>>>>>
>>>>> U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)
>>>>>
>>>>> Model: sandbox
>>>>> DRAM:  128 MiB
>>>>>
>>>>> Warning: host_lo MAC addresses don't match:
>>>>> Address in ROM is 1a:34:9b:48:aa:53
>>>>> Address in environment is 00:00:11:22:33:44
>>>>> WDT:   Not found!
>>>>> MMC:
>>>>>
>>>>> Breakpoint 1, getc () at
>>>>> /home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
>>>>> 414 if (!gd->have_console)
>>>>> (gdb) up
>>>>> #1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
>>>>> (gdb)
>>>>>
>>>>>
>>>>> So it seems that it is libX11 causing the problem.
>>>>>
>>>>> I don't think the best fix is to remove getc() from that library,
>>>>> although I do wonder if it is a bug. Renaming the symbol in U-Boot
>>>>> with #define (only on sandbox) might be one option.
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>
>>>> #define getc _uboot_getc
>>>>
>>>> is what I tried but it runs you into the trouble that many other symbols
>>>> contain the getc substring.
>>>>
>>>> As we always try to use the same definition in U-Boot as in glibc we
>>>> should really replace getc() by another symbol, e.g. chget() so that we
>>>> avoid confusion.
>>>
>>> Well the first question is whether this is a bug with x11.
>>>
>>> I'm not sure that renaming is a good idea. getc() is a pretty standard name.
>>>
>>> Try
>>>
>>> #define getc(x) _sandbox_get(x)
>>>
>>> which might get you closer.
>>>
>>> Regards,
>>> Simon
>>>
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commit/7b302bedb21f94b9eb619cb38ef985f7bbb9be1f
>>
>> seems to fix the crash. I get an output window.
>>
>> But there are still problems:
>>
>> * The shift key does not work on the keyboard.
>
> What is shift supposed to do? Do you mean you cannot get capital
> letters or symbols?
>
>> * The output is black and white only.
>
> That's odd. I haven't tried it recently but earlier in the year I was
> able to write a colour BMP.
>
>>
>> What I would like to have is a 32bit color framebuffer on which I can
>> draw with the EFI graphical output protocol.
>
> Well that should work. I adds Nuklear support a while back and
> everything seemed good. Perhaps there has been a regression? But there
> is a test for colour bitmaps. Perhaps it is just the SDL display side
> which is not working?
>
> I just tried this and got a colour image:
>
> => host load hostfs - 0 tools/logos/denx.bmp
> => bmp display 0
>
> Regards,
> Simon
>

Hello Simon,

the background of characters is not set correctly. I thought it was
black and white.

To see what I mean:

CONFIG_EFI_SELFTEST=y

./u-boot -D -l

=> setenv efi_selftest block image transfer
=> bootefi selftest

You will need my two patches.

Things that are still wrong:

* We start with black on white instead white on black.
* Background for characters.
* The font in not mono-spaced.
* When typing a backslash you get always two of them.

Best regards

Heinrich

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

On 9/29/20 1:59 AM, Heinrich Schuchardt wrote:
> On 9/29/20 12:19 AM, Simon Glass wrote:
>> Hi Heinrich,
>>
>> On Mon, 28 Sep 2020 at 15:23, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>
>>> On 9/28/20 3:42 PM, Simon Glass wrote:
>>>> Hi Heinrich,
>>>>
>>>> On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>>
>>>>> On 28.09.20 15:22, Simon Glass wrote:
>>>>>> Hi Heinrich,
>>>>>>
>>>>>> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>>>>>>>
>>>>>>> On 28.09.20 06:46, Heinrich Schuchardt wrote:
>>>>>>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass <sjg@chromium.org>:
>>>>>>>>> Hi Heinrich,
>>>>>>>>>
>>>>>>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <xypron.glpk@gmx.de>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Simon,
>>>>>>>>>>
>>>>>>>>>> when I try to run ./u-boot -l the sandbox stalls. Shouldn't it run
>>>>>>>>> out
>>>>>>>>>> of the box?
>>>>>>>>>>
>>>>>>>>>> $ ./u-boot -l -d arch/sandbox/dts/sandbox.dtb
>>>>>>>>>
>>>>>>>>> For the record you should be able to use -D to get the same effect as
>>>>>>>>> your -d above.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> U-Boot 2020.10-rc4-00018-g21a10244f9-dirty (Sep 19 2020 - 19:55:39
>>>>>>>>> +0200)
>>>>>>>>>>
>>>>>>>>>> Model: sandbox
>>>>>>>>>> DRAM:  128 MiB
>>>>>>>>>>
>>>>>>>>>> Warning: host_lo MAC addresses don't match:
>>>>>>>>>> Address in ROM is               26:4b:ca:6c:98:f4
>>>>>>>>>> Address in environment is       00:00:11:22:33:44
>>>>>>>>>>
>>>>>>>>>> Warning: host_virbr0 MAC addresses don't match:
>>>>>>>>>> Address in ROM is               ee:3e:c9:ce:1f:9c
>>>>>>>>>> Address in environment is       00:00:11:22:33:45
>>>>>>>>>>
>>>>>>>>>> Warning: host_docker0 MAC addresses don't match:
>>>>>>>>>> Address in ROM is               c2:85:07:7b:9a:18
>>>>>>>>>> Address in environment is       00:00:11:22:33:46
>>>>>>>>>> WDT:   Not found!
>>>>>>>>>> MMC:
>>>>>>>>>>
>>>>>>>>>> No output after this point.
>>>>>>>>>>
>>>>>>>>>> The problem also exists with U-Boot v2020.07, v2019.10, v2018.11.
>>>>>>>>>>
>>>>>>>>>> CONFIG_SANDBOX_SDL=y
>>>>>>>>>>
>>>>>>>>>> SDL_InitSubSystem() never returns. It is looping somewhere in
>>>>>>>>> U-Boot's
>>>>>>>>>> __serial_getc(). I wonder how it gets there without returning from
>>>>>>>>> the
>>>>>>>>>> function.
>>>>>>>>>>
>>>>>>>>>> I compiled SDL2.cpp from
>>>>>>>>>> https://gist.github.com/miguelmartin75/6946310#file-sdl2-cpp-L18
>>>>>>>>>> with
>>>>>>>>>>
>>>>>>>>>> g++ SDL2.cpp -D_REENTRANT -I/usr/include/SDL2 -lSDL2 -lGL -o test
>>>>>>>>>>
>>>>>>>>>> and it runs fine showing an X11 windows with red background.
>>>>>>>>>>
>>>>>>>>>> So there seems to be no general problem with the SDL2 library.
>>>>>>>>>
>>>>>>>>> I hit this myself on another computer and it turned out to be that SDL
>>>>>>>>> defined getc(), as does U-Boot, and things get confused. At least I
>>>>>>>>> think it is getc.
>>>>>>>>>
>>>>>>>>> I hacked around with changing the name of getc (I think it was getc)
>>>>>>>>> in U-Boot and the problem went away.
>>>>>>>>
>>>>>>>> Should we include a patched SDL2 with U-Boot for static linking?
>>>>>>>>
>>>>>>>
>>>>>>> I cannot find a symbol getc() nor a reference to it in the SDL
>>>>>>> repository. getc() is defined in stdio.h.
>>>>>>>
>>>>>>> Our getc() takes no argument, while the stdio one wants a FILE *.
>>>>>>>
>>>>>>> But changing the U-Boot definition to "int getc(void *)" does not solve
>>>>>>> the issue.
>>>>>>
>>>>>> I just tried it on the machine where it doesn't work:
>>>>>>
>>>>>> $ gdb --args /tmp/b/sandbox/u-boot -l -D
>>>>>> GNU gdb (Debian 9.2-1) 9.2
>>>>>> Copyright (C) 2020 Free Software Foundation, Inc.
>>>>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>>>>> This is free software: you are free to change and redistribute it.
>>>>>> There is NO WARRANTY, to the extent permitted by law.
>>>>>> Type "show copying" and "show warranty" for details.
>>>>>> This GDB was configured as "x86_64-linux-gnu".
>>>>>> Type "show configuration" for configuration details.
>>>>>> For bug reporting instructions, please see:
>>>>>> <http://www.gnu.org/software/gdb/bugs/>.
>>>>>> Find the GDB manual and other documentation resources online at:
>>>>>>     <http://www.gnu.org/software/gdb/documentation/>.
>>>>>>
>>>>>> For help, type "help".
>>>>>> Type "apropos word" to search for commands related to "word"...
>>>>>> Reading symbols from /tmp/b/sandbox/u-boot...
>>>>>> (gdb) br getc
>>>>>> Breakpoint 1 at 0x5b6d6: getc. (2 locations)
>>>>>> (gdb) r
>>>>>> Starting program: /tmp/b/sandbox/u-boot -l -D
>>>>>> [Thread debugging using libthread_db enabled]
>>>>>> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>>>>>>
>>>>>>
>>>>>> U-Boot 2020.10-rc5-00196-g0ac83d080a0 (Sep 28 2020 - 07:11:52 -0600)
>>>>>>
>>>>>> Model: sandbox
>>>>>> DRAM:  128 MiB
>>>>>>
>>>>>> Warning: host_lo MAC addresses don't match:
>>>>>> Address in ROM is 1a:34:9b:48:aa:53
>>>>>> Address in environment is 00:00:11:22:33:44
>>>>>> WDT:   Not found!
>>>>>> MMC:
>>>>>>
>>>>>> Breakpoint 1, getc () at
>>>>>> /home/sjg/cosarm/src/third_party/u-boot/files/common/console.c:414
>>>>>> 414 if (!gd->have_console)
>>>>>> (gdb) up
>>>>>> #1  0x00007ffff7914d48 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
>>>>>> (gdb)
>>>>>>
>>>>>>
>>>>>> So it seems that it is libX11 causing the problem.
>>>>>>
>>>>>> I don't think the best fix is to remove getc() from that library,
>>>>>> although I do wonder if it is a bug. Renaming the symbol in U-Boot
>>>>>> with #define (only on sandbox) might be one option.
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>>
>>>>> #define getc _uboot_getc
>>>>>
>>>>> is what I tried but it runs you into the trouble that many other symbols
>>>>> contain the getc substring.
>>>>>
>>>>> As we always try to use the same definition in U-Boot as in glibc we
>>>>> should really replace getc() by another symbol, e.g. chget() so that we
>>>>> avoid confusion.
>>>>
>>>> Well the first question is whether this is a bug with x11.
>>>>
>>>> I'm not sure that renaming is a good idea. getc() is a pretty standard name.
>>>>
>>>> Try
>>>>
>>>> #define getc(x) _sandbox_get(x)
>>>>
>>>> which might get you closer.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/commit/7b302bedb21f94b9eb619cb38ef985f7bbb9be1f
>>>
>>> seems to fix the crash. I get an output window.
>>>
>>> But there are still problems:
>>>
>>> * The shift key does not work on the keyboard.
>>
>> What is shift supposed to do? Do you mean you cannot get capital
>> letters or symbols?
>>
>>> * The output is black and white only.
>>
>> That's odd. I haven't tried it recently but earlier in the year I was
>> able to write a colour BMP.
>>
>>>
>>> What I would like to have is a 32bit color framebuffer on which I can
>>> draw with the EFI graphical output protocol.
>>
>> Well that should work. I adds Nuklear support a while back and
>> everything seemed good. Perhaps there has been a regression? But there
>> is a test for colour bitmaps. Perhaps it is just the SDL display side
>> which is not working?
>>
>> I just tried this and got a colour image:
>>
>> => host load hostfs - 0 tools/logos/denx.bmp
>> => bmp display 0
>>
>> Regards,
>> Simon
>>
>
> Hello Simon,
>
> the background of characters is not set correctly. I thought it was
> black and white.
>
> To see what I mean:
>
> CONFIG_EFI_SELFTEST=y
>
> ./u-boot -D -l
>
> => setenv efi_selftest block image transfer
> => bootefi selftest
>
> You will need my two patches.
>
> Things that are still wrong:
>
> * We start with black on white instead white on black.
> * Background for characters.
> * The font in not mono-spaced.
> * When typing a backslash you get always two of them.

* White on black is customizing.
Can we change that for the sandbox_defconfig to fit to Linux standards?

* The truetype console does not yet understand the escape sequences for
colors. The normal console does.

* The normal console has a mono-space font. We also have alternative
fonts for the truetype console.

* Both consoles fail on Unicode characters. But we probably do not want
larger font files.

So the only problem I do not understood yet is the duplicate backspace.

Best regards

Heinrich

[BUG] sandbox: './u-boot -l ' fails

[Wolfgang Denk]

Dear Heinrich,

In message <cab32aa2-0423-c966-47e1-a6f59411b0d1@gmx.de> you wrote:
>
> As we always try to use the same definition in U-Boot as in glibc we
> should really replace getc() by another symbol, e.g. chget() so that we
> avoid confusion.

We should not invent any new names when there are existing good
alterntives.

Why not use getchar()?

Quote fgetc(3) man page:

...
       int getchar(void);
...
       getchar() is equivalent to getc(stdin).
...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I saw Susie sitting in a shoe shine shop. Where she sits she shines,
and where she shines she sits.

[BUG] sandbox: './u-boot -l ' fails

[Heinrich Schuchardt]

Am 29. September 2020 13:12:25 MESZ schrieb Wolfgang Denk <wd@denx.de>:
>Dear Heinrich,
>
>In message <cab32aa2-0423-c966-47e1-a6f59411b0d1@gmx.de> you wrote:
>>
>> As we always try to use the same definition in U-Boot as in glibc we
>> should really replace getc() by another symbol, e.g. chget() so that
>we
>> avoid confusion.
>
>We should not invent any new names when there are existing good
>alterntives.
>
>Why not use getchar()?
>
>Quote fgetc(3) man page:
>
>...
>       int getchar(void);
>...
>       getchar() is equivalent to getc(stdin).
>...
>
>Best regards,
>
>Wolfgang Denk


Hello Wolfgang,

please, have a look at http://patchwork.ozlabs.org/project/uboot/patch/20200928234514.124945-1-xypron.glpk at gmx.de/

Is such a #define the way to go or should we globally rename getc?

Best regards

Heinrich

[BUG] sandbox: './u-boot -l ' fails

[Wolfgang Denk]

Dear Heinrich,

In message <0CBB3DF2-632B-4DAB-BD39-E2CE9F5AF513@gmx.de> you wrote:
>
> >We should not invent any new names when there are existing good
> >alterntives.
> >
> >Why not use getchar()?
...

> please, have a look at http://patchwork.ozlabs.org/project/uboot/patch> /20200928234514.124945-1-xypron.glpk at gmx.de/
>
> Is such a #define the way to go or should we globally rename getc?

I don't think this is a good idea; I would recommend to keep the
getc() as used so far in normal U-Boot, and only "translate" it into
getchar() for the sandbox environment.

Especially messing with  include/_exports.h  is critical, as this is
used for standalone applications, which are the only allowed
exception from GPL code, so we have to assume there is some amount
of binary-only code in the field, and we should be careful not to
break this without need.  Changes here may break compatibility.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Well I don't see why I have to make one man  miserable  when  I  can
make so many men happy."              - Ellyn Mustard, about marriage