Re: build.sh distribution failure for evbarm
On 11/03/18 04:50, m...@netbsd.org wrote: On Sat, Nov 03, 2018 at 04:44:18AM +, m...@netbsd.org wrote: Changing the actual triplets is probably a bad idea because the decisions are embedded in a lot of configure scripts in random third party code. But perhaps we need to rename things so no users end up using it by accident. And that's what nick was suggesting with the alias (I wasn't paying enough attention at first). Nick's suggestion was spot-on for me, the only kernels built were RPI, RPI2 and TISDP2420 (whatever that is), so I am good. The old RPI-Zero is already busy building packages...
Re: build.sh distribution failure for evbarm
On Sat, Nov 03, 2018 at 04:44:18AM +, m...@netbsd.org wrote: > Changing the actual triplets is probably a bad idea because the > decisions are embedded in a lot of configure scripts in random third > party code. > But perhaps we need to rename things so no users end up using it by > accident. And that's what nick was suggesting with the alias (I wasn't paying enough attention at first).
Re: build.sh distribution failure for evbarm
"compiled for earmv7hf" is just some text that NetBSD adds in to binaries it builds, it doesn't need to be meaningful. the "EABI5" part must be correct, but file doesn't try to distinguish more than "ARMv1" and "EABI5" (it doesn't make sense to try harder, you can write code to do v7 and v5 in the same binary). If you use gcc -S it can tell you more about the type of code it generated, e.g. for evbarm: ~/arm/tooldir.NetBSD-8.99.21-amd64/bin/arm--netbsdelf-eabi-gcc -S test.c cat test.s .. .cpu arm926ej-s .fpu softvfp Changing the actual triplets is probably a bad idea because the decisions are embedded in a lot of configure scripts in random third party code. But perhaps we need to rename things so no users end up using it by accident. the biggest issue with using evbarm is that it's soft float and you have an FPU you can take advantage of. You can adjust the list of kernels built in src/etc/etc.evbarm.
Re: build.sh distribution failure for evbarm
Chavdar Ivanov writes: > It would benefit from some clarification regarding the ARM ecosystem > indeed. So far I've always used ' evbarm' for my RPI builds and > wondered if I can skip the building of the rest. I think there are two separate issues behind your comment. First is the type of build, which involves a MACHINE, one of the NetBSD port types, corresponding to "uname -m", and then MACHINE_ARCH, which is a CPU type, corresponding to "uname -p". evbarm is a MACHINE that supports a number of hardware platforms and can be built with a number oF MACHINE_ARCH values. See src/build.sh, and search for evbarm. If you build with "-a evbearmv6hf-el", that will use MACHINE=evbarm and MACHINE_ARCH=earmv6hf (implicitly el). That's the right CPU definition for RPI1, and the same userland code will also run on RPI2/3. If you build with evbearmv7hf-el, then the userland code will run on RPI2/3 but not RPI1. "file" on the userland code says EABI5, compiled for earmv7hf. The RPI kernel (for 1) is not built; I am guessing that is because it needs earmv6hf and there's some logic to omit it. These articles are helpful to sort through the confusing naming. In particular note that armvN and armN have different meanings - there are familes, architectures and cores, all almost the same names, but really in different namespaces! https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures https://en.wikipedia.org/wiki/ARM_architecture The second issue is that you might wish to omit building a kernel for a board type you don't have, even if it uses the same CPU and same userland code. This is more or less the same thing as skipping building an alternative i386 kernel. I am unaware of support for that. But, my impression is that there has been significant progress in having more and more boards run GENERIC via FDT. But there do seem to be 37 in current when using evbearmv7hf-el.I find it easier to just run builds in the background than to adjust them. > Anyway, with 'evbearmv6hf-el' the build completed successfully. > > On Fri, 2 Nov 2018 at 19:42, Greg Troxel wrote: >> >> >> Nick Hudson writes: >> >> > RPI should use evbearmv6hf-el >> > RPI2 should use evbearmv7hf-el >> > >> > I'm thinking evbarm should alias to evbearmv7hf-el these days >> >> Maybe, but another theory is that we should have a bunch of aliases and >> that -a evbarm should just error out, because whoever invoked it that >> way doesn't have a clear view of what they want. And we should enable >> RELEASEMACHINEDIR being equal to the alias by default, so that multiple >> builds don't collide so much. >>
Re: build.sh distribution failure for evbarm
It would benefit from some clarification regarding the ARM ecosystem indeed. So far I've always used ' evbarm' for my RPI builds and wondered if I can skip the building of the rest. Anyway, with 'evbearmv6hf-el' the build completed successfully. On Fri, 2 Nov 2018 at 19:42, Greg Troxel wrote: > > > Nick Hudson writes: > > > RPI should use evbearmv6hf-el > > RPI2 should use evbearmv7hf-el > > > > I'm thinking evbarm should alias to evbearmv7hf-el these days > > Maybe, but another theory is that we should have a bunch of aliases and > that -a evbarm should just error out, because whoever invoked it that > way doesn't have a clear view of what they want. And we should enable > RELEASEMACHINEDIR being equal to the alias by default, so that multiple > builds don't collide so much. > --
Re: build.sh distribution failure for evbarm
Nick Hudson writes: > RPI should use evbearmv6hf-el > RPI2 should use evbearmv7hf-el > > I'm thinking evbarm should alias to evbearmv7hf-el these days Maybe, but another theory is that we should have a bunch of aliases and that -a evbarm should just error out, because whoever invoked it that way doesn't have a clear view of what they want. And we should enable RELEASEMACHINEDIR being equal to the alias by default, so that multiple builds don't collide so much.
Re: build.sh distribution failure for evbarm
On 02/11/2018 14:33, Chavdar Ivanov wrote: This is the command line: ./build.sh -D/home/sysbuild/evbarm/destdir -M/home/sysbuild/evbarm/obj -N2 -R/home/sysbuild/release -T/home/sysbuild/evbarm/tools -U -X/home/sysbuild/xsrc -j8 -mevbarm -u -x release live-image It is actually done by sysutils/sysbuild (obviously); I need only the RPI kernel for the two boards I have; never went down to figure out how to restrict it building all the other evbarm kernels and images, but thought that anyway it is useful to know if they build. RPI should use evbearmv6hf-el RPI2 should use evbearmv7hf-el I'm thinking evbarm should alias to evbearmv7hf-el these days Nick
Re: build.sh distribution failure for evbarm
This is the command line: ./build.sh -D/home/sysbuild/evbarm/destdir -M/home/sysbuild/evbarm/obj -N2 -R/home/sysbuild/release -T/home/sysbuild/evbarm/tools -U -X/home/sysbuild/xsrc -j8 -mevbarm -u -x release live-image It is actually done by sysutils/sysbuild (obviously); I need only the RPI kernel for the two boards I have; never went down to figure out how to restrict it building all the other evbarm kernels and images, but thought that anyway it is useful to know if they build. On Fri, 2 Nov 2018 at 13:36, Robert Swindells wrote: > > > Chavdar Ivanov wrote: > >With sources from about an hour ago I cannot complete distribution > >build for evbarm: > >--- > >ymir% pwd > >/home/sysbuild/evbarm/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC > >ymir% CC=/home/sysbuild/evbarm/tools/bin/arm--netbsdelf-eabi-gcc >^ > > What did you provide for the 'mach' parameter to build.sh ? > > If you are building it to run on your Zynq system then you should set it > to evbearmv7hf-el. --
Re: build.sh distribution failure for evbarm
Chavdar Ivanov wrote: >With sources from about an hour ago I cannot complete distribution >build for evbarm: >--- >ymir% pwd >/home/sysbuild/evbarm/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC >ymir% CC=/home/sysbuild/evbarm/tools/bin/arm--netbsdelf-eabi-gcc ^ What did you provide for the 'mach' parameter to build.sh ? If you are building it to run on your Zynq system then you should set it to evbearmv7hf-el.
Re: build.sh distribution failure for evbarm
On Fri, Nov 02, 2018 at 01:04:33PM +, Chavdar Ivanov wrote: > The last (third) attempt was with fresh obj directory; I also did > 'make cleandir' in the src directory just in case (in the past this > has helped). It is best to check the autobuild results in such cases, they fail the same (and they always do a clean build). http://releng.netbsd.org/cgi-bin/builds.cgi Martin
build.sh distribution failure for evbarm
Hi, With sources from about an hour ago I cannot complete distribution build for evbarm: --- ymir% pwd /home/sysbuild/evbarm/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC ymir% CC=/home/sysbuild/evbarm/tools/bin/arm--netbsdelf-eabi-gcc /home/sysbuild/evbarm/tools/bin/nbmkdep -f armv6_start.d.tmp -- -x assembler-with-cpp -D_LOCORE -Wa,--fatal-warnings --sysroot=/home/sysbuild/evbarm/destdir -DKERNEL_BASE_VOFFSET=\"\(0x8040-0x0040\)\" -I. -I/home/sysbuild/src/sys/external/bsd/libnv/dist -I/home/sysbuild/src/sys/../common/lib/libx86emu -I/home/sysbuild/src/sys/../common/lib/libc/misc -I/home/sysbuild/src/sys/../common/include -I/home/sysbuild/src/sys/arch -I/home/sysbuild/src/sys -nostdinc -DARM_GENERIC_TODR -D__HAVE_CPU_COUNTER -D__HAVE_CPU_UAREA_ALLOC_IDLELWP -D__HAVE_FAST_SOFTINTS -D__HAVE_PCI_CONF_HOOK -DCOMPAT_44 -DDIAGNOSTIC -D_KERNEL -D_KERNEL_OPT -std=gnu99 -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/quad -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/string -I/home/sysbuild/src/sys/lib/libkern/../../../common/lib/libc/arch/arm/string -I/home/sysbuild/src/sys/external/bsd/common/include -I/home/sysbuild/src/sys/external/bsd -I/home/sysbuild/src/sys/external/bsd/dwc2/dist -I/home/sysbuild/src/sys/external/bsd/libfdt/dist -I/home/sysbuild/src/sys/external/bsd/libnv/dist -I/home/sysbuild/src/sys/external/bsd/vchiq/dist -I/home/sysbuild/src/sys/external/bsd/common/include -DVCOS_VERIFY_BKPTS=1 -DUSE_VCHIQ_ARM -D__VCCOREVER__=0x0400 -DVCHIQ_ENABLE_DEBUG=1 -DVCHIQ_LOG_DEFAULT=5 /home/sysbuild/src/sys/arch/arm/arm/armv6_start.S /home/sysbuild/src/sys/arch/arm/arm/armv6_start.S:180:2: error: #error Unsupported CPU #error Unsupported CPU ^ nbmkdep: compile failed. --- The last (third) attempt was with fresh obj directory; I also did 'make cleandir' in the src directory just in case (in the past this has helped). Chavdar Ivanov --
