On 9/29/20 12:19 AM, Simon Glass wrote: > Hi Heinrich, > > On Mon, 28 Sep 2020 at 15:23, Heinrich Schuchardt <[email protected]> wrote: >> >> On 9/28/20 3:42 PM, Simon Glass wrote: >>> Hi Heinrich, >>> >>> On Mon, 28 Sep 2020 at 07:30, Heinrich Schuchardt <[email protected]> >>> wrote: >>>> >>>> On 28.09.20 15:22, Simon Glass wrote: >>>>> Hi Heinrich, >>>>> >>>>> On Mon, 28 Sep 2020 at 05:31, Heinrich Schuchardt <[email protected]> >>>>> wrote: >>>>>> >>>>>> On 28.09.20 06:46, Heinrich Schuchardt wrote: >>>>>>> Am 28. September 2020 06:24:38 MESZ schrieb Simon Glass >>>>>>> <[email protected]>: >>>>>>>> Hi Heinrich, >>>>>>>> >>>>>>>> On Sat, 19 Sep 2020 at 13:48, Heinrich Schuchardt <[email protected]> >>>>>>>> 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
