* [BUG] sandbox: './u-boot -l ' fails @ 2020-09-19 19:48 Heinrich Schuchardt 2020-09-28 4:24 ` Simon Glass 0 siblings, 1 reply; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-19 19:48 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-19 19:48 [BUG] sandbox: './u-boot -l ' fails Heinrich Schuchardt @ 2020-09-28 4:24 ` Simon Glass 2020-09-28 4:46 ` Heinrich Schuchardt 0 siblings, 1 reply; 14+ messages in thread From: Simon Glass @ 2020-09-28 4:24 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 4:24 ` Simon Glass @ 2020-09-28 4:46 ` Heinrich Schuchardt 2020-09-28 11:31 ` Heinrich Schuchardt 0 siblings, 1 reply; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-28 4:46 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 4:46 ` Heinrich Schuchardt @ 2020-09-28 11:31 ` Heinrich Schuchardt 2020-09-28 13:22 ` Simon Glass 0 siblings, 1 reply; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-28 11:31 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 11:31 ` Heinrich Schuchardt @ 2020-09-28 13:22 ` Simon Glass 2020-09-28 13:30 ` Heinrich Schuchardt 0 siblings, 1 reply; 14+ messages in thread From: Simon Glass @ 2020-09-28 13:22 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 13:22 ` Simon Glass @ 2020-09-28 13:30 ` Heinrich Schuchardt 2020-09-28 13:42 ` Simon Glass 2020-09-29 11:12 ` Wolfgang Denk 0 siblings, 2 replies; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-28 13:30 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 13:30 ` Heinrich Schuchardt @ 2020-09-28 13:42 ` Simon Glass 2020-09-28 21:23 ` Heinrich Schuchardt 2020-09-29 11:12 ` Wolfgang Denk 1 sibling, 1 reply; 14+ messages in thread From: Simon Glass @ 2020-09-28 13:42 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 13:42 ` Simon Glass @ 2020-09-28 21:23 ` Heinrich Schuchardt 2020-09-28 22:19 ` Simon Glass 0 siblings, 1 reply; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-28 21:23 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 21:23 ` Heinrich Schuchardt @ 2020-09-28 22:19 ` Simon Glass 2020-09-28 23:59 ` Heinrich Schuchardt 0 siblings, 1 reply; 14+ messages in thread From: Simon Glass @ 2020-09-28 22:19 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 22:19 ` Simon Glass @ 2020-09-28 23:59 ` Heinrich Schuchardt 2020-09-29 1:21 ` Heinrich Schuchardt 0 siblings, 1 reply; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-28 23:59 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 23:59 ` Heinrich Schuchardt @ 2020-09-29 1:21 ` Heinrich Schuchardt 0 siblings, 0 replies; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-29 1:21 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-28 13:30 ` Heinrich Schuchardt 2020-09-28 13:42 ` Simon Glass @ 2020-09-29 11:12 ` Wolfgang Denk 2020-09-29 11:47 ` Heinrich Schuchardt 1 sibling, 1 reply; 14+ messages in thread From: Wolfgang Denk @ 2020-09-29 11:12 UTC (permalink / raw) To: u-boot 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-29 11:12 ` Wolfgang Denk @ 2020-09-29 11:47 ` Heinrich Schuchardt 2020-09-29 13:05 ` Wolfgang Denk 0 siblings, 1 reply; 14+ messages in thread From: Heinrich Schuchardt @ 2020-09-29 11:47 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* [BUG] sandbox: './u-boot -l ' fails 2020-09-29 11:47 ` Heinrich Schuchardt @ 2020-09-29 13:05 ` Wolfgang Denk 0 siblings, 0 replies; 14+ messages in thread From: Wolfgang Denk @ 2020-09-29 13:05 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-09-29 13:05 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-19 19:48 [BUG] sandbox: './u-boot -l ' fails Heinrich Schuchardt 2020-09-28 4:24 ` Simon Glass 2020-09-28 4:46 ` Heinrich Schuchardt 2020-09-28 11:31 ` Heinrich Schuchardt 2020-09-28 13:22 ` Simon Glass 2020-09-28 13:30 ` Heinrich Schuchardt 2020-09-28 13:42 ` Simon Glass 2020-09-28 21:23 ` Heinrich Schuchardt 2020-09-28 22:19 ` Simon Glass 2020-09-28 23:59 ` Heinrich Schuchardt 2020-09-29 1:21 ` Heinrich Schuchardt 2020-09-29 11:12 ` Wolfgang Denk 2020-09-29 11:47 ` Heinrich Schuchardt 2020-09-29 13:05 ` Wolfgang Denk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.