| Message ID | 20230424230836.630907-1-sjg@chromium.org |
|---|---|
| Headers | show |
| Series | Allow building sandbox with MSYS2 | expand |
Am 25. April 2023 01:08:05 MESZ schrieb Simon Glass <sjg@chromium.org>: >This expands the existing work to allow sandbox to build and run on >Windows using MSYS2. Why do we need this? Wouldn't a developer on Windows be much better served using WSL (https://learn.microsoft.com/en-us/windows/wsl/install)? Best regards Heinrich > >It also fixes a few issues so that binman can be used. > >There are various limitations and some features do not work fully yet. In >particular, weak functions are not well supported on Windows so these are >disabled. Various minor compiler-flag and filename adjustments are also >needed. > >This does not support SDL, so U-Boot has no display. This is potentially >possible, but requires using minggw instead of the base toolchain [1] so >needs to be dealt with separately. > >[1] https://gist.github.com/thales17/fb2e4cff60890a51d9dddd4c6e832ad2 > > >Simon Glass (31): > patman: Declare the future Series memory > u_boot_pylib: Correct name of readme > u_boot_pylib: Make pty optional > binman: Avoid using a symlink > binman: Don't require a HOME directory > pylibfdt: Allow building on Windows > Fix Makefile warning about parallel targets > mkimage: Correct checking of configuration node > Kbuild: Detect including an MSYS2 path > sandbox: Provide a linker script for MSYS2 > sandbox: Provide an EFI link script for PE > sandbox: Drop dead code from Makefile > sandbox: Disable raw Ethernet on MSYS2 > sandbox: Drop signal handling for MSYS2 > sandbox: Correct SDL.h header inclusion > sandbox: Include errno.h in the test header > sandbox: Allow weak symbols to be dropped > sections: Drop use of linux/types.h > sandbox: Drop incorrect inclusion of linux/types.h > sandbox: Drop inclusion of os.h in sscanf.c > test: Avoid strange symbols in the assembler file > sandbox: Fix up setting of monitor_len on MSYS2 > ctype: Avoid using a symlink > build: Disable weak symbols for MSYS2 > Makefile: Disable unsupported compiler options with PE > Makefile: Correct the ans1_compiler rule for MSYS2 > Makefile: Disable LTO when building with MSYS2 > doc: Update the MSYS2 packages and versions > doc: Show how to build sandbox for MSYS2 > Makefile: Drop unwind tables > CI: Enable sandbox build for Windows > > .azure-pipelines.yml | 27 ++ > Kconfig | 15 + > Makefile | 27 +- > arch/sandbox/Makefile | 7 - > arch/sandbox/config.mk | 8 +- > arch/sandbox/cpu/Makefile | 2 + > arch/sandbox/cpu/os.c | 3 +- > arch/sandbox/cpu/sdl.c | 2 +- > arch/sandbox/cpu/u-boot-pe.lds | 447 ++++++++++++++++++++++++++ > arch/sandbox/include/asm/test.h | 1 + > arch/x86/lib/crt0_x86_64_efi.S | 2 + > arch/x86/lib/pe_x86_64_efi.lds | 83 +++++ > cmd/bootefi.c | 3 +- > cmd/bootz.c | 3 + > common/board_f.c | 2 +- > common/usb.c | 3 + > doc/build/gcc.rst | 35 ++ > doc/build/tools.rst | 20 +- > drivers/core/root.c | 3 + > drivers/net/Makefile | 2 + > drivers/spi/sandbox_spi.c | 3 + > env/env.c | 6 + > include/asm-generic/sections.h | 16 +- > include/ctype.h | 7 +- > include/linux/compiler_attributes.h | 4 + > include/os.h | 2 - > include/test/test.h | 4 +- > lib/efi_loader/Makefile | 8 + > lib/efi_loader/efi_image_loader.c | 3 + > lib/efi_loader/efi_runtime.c | 4 + > lib/lmb.c | 4 +- > lib/sscanf.c | 1 - > lib/time.c | 3 + > scripts/Kbuild.include | 3 +- > scripts/Makefile.build | 2 +- > scripts/Makefile.lib | 9 +- > scripts/dtc/pylibfdt/Makefile | 16 +- > scripts/make_pip.sh | 9 +- > tools/Makefile | 14 +- > tools/binman/binman | 11 +- > tools/binman/cmdline.py | 2 +- > tools/image-host.c | 4 +- > tools/patman/commit.py | 3 + > tools/u_boot_pylib/README.rst | 2 +- > tools/u_boot_pylib/cros_subprocess.py | 28 +- > tools/u_boot_pylib/pyproject.toml | 2 +- > 46 files changed, 803 insertions(+), 62 deletions(-) > create mode 100644 arch/sandbox/cpu/u-boot-pe.lds > create mode 100644 arch/x86/lib/pe_x86_64_efi.lds > mode change 120000 => 100644 include/ctype.h > mode change 120000 => 100755 tools/binman/binman >
On Tue, Apr 25, 2023 at 04:59:53AM +0200, Heinrich Schuchardt wrote: > > > Am 25. April 2023 01:08:05 MESZ schrieb Simon Glass <sjg@chromium.org>: > >This expands the existing work to allow sandbox to build and run on > >Windows using MSYS2. > > Why do we need this? > Wouldn't a developer on Windows be much better served using WSL (https://learn.microsoft.com/en-us/windows/wsl/install)? Depending on corporate rules that may or may not be allowed. But I too am interested in the use case driving these changes. Sandbox is essentially a test platform. We test that we can do host tools on Windows via MSYS2 for semi-reasonable reasons, since those tools can be used in a number of places. We do the same on macOS in Azure as a check on building regular targets there too (which should work and I believe people do, both from macOS and from *BSD which this is a stand-in for, as we can't get free VMs for them today). What's the end goal of this series?
Hi Tom, On Tue, 25 Apr 2023 at 10:04, Tom Rini <trini@konsulko.com> wrote: > > On Tue, Apr 25, 2023 at 04:59:53AM +0200, Heinrich Schuchardt wrote: > > > > > > Am 25. April 2023 01:08:05 MESZ schrieb Simon Glass <sjg@chromium.org>: > > >This expands the existing work to allow sandbox to build and run on > > >Windows using MSYS2. > > > > Why do we need this? > > Wouldn't a developer on Windows be much better served using WSL (https://learn.microsoft.com/en-us/windows/wsl/install)? > > Depending on corporate rules that may or may not be allowed. But I too > am interested in the use case driving these changes. Sandbox is > essentially a test platform. We test that we can do host tools on > Windows via MSYS2 for semi-reasonable reasons, since those tools can be > used in a number of places. We do the same on macOS in Azure as a check > on building regular targets there too (which should work and I believe > people do, both from macOS and from *BSD which this is a stand-in for, > as we can't get free VMs for them today). What's the end goal of this > series? It is really just an extension of the existing tools-only build. I am not sure it is strongly motivated, but the end goal is to be able to do small features / development on U-Boot on Windows, since some users seem to only use a 'pure' Windows environment and don't use WSL, which after all is for cross-compiling. For example, it is possible to build a FIT and check it using the tools, but it is not possible (without this series) to see whether U-Boot will load it and behave correctly. The binman changes are to make that work on Windows (pip install binary-manager) which is important for that tool. The 'weak' issue is something that I am hoping can be resolved (in fact Bin made a promising comment on that patch). This has all come up as we try to establish a standard 'payload' format which can be used across the industry. For better or worse, some people do use Windows for development. Regards, Simon