FYI -- this has already been fixed.
> On May 7, 2019, at 10:06 PM, NetBSD Test Fixture wrote:
>
> This is an automatically generated notice of a NetBSD-current/i386
> build failure.
>
> The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
> using sources from CVS date 2019.05.08.03
This is an automatically generated notice of a NetBSD-current/i386
build failure.
The failure occurred on babylon5.netbsd.org, a NetBSD/amd64 host,
using sources from CVS date 2019.05.08.03.29.59.
An extract from the build.sh output follows:
/tmp/bracket/build/2019.05.08.03.29.59-i386/src/t
Updating src tree:
P src/common/lib/libprop/prop_bool.c
P src/common/lib/libprop/prop_data.c
P src/common/lib/libprop/prop_number.c
P src/common/lib/libprop/prop_object_impl.h
P src/common/lib/libprop/prop_stack.c
P src/common/lib/libprop/prop_string.c
P src/distrib/sets/lists/base/mi
P src/doc/C
> On May 7, 2019, at 4:54 PM, Andrew Luke Nesbit
> wrote:
> This is a really great thread, which I am enjoying very much.
>
> I don't use any BPi because I am a user of Orange Pi (especially the
> OPi+2E).
>
> But considering they are very close in architecture and use
> (essentially) the s
On 07/05/2019 22:37, Jared McNeill wrote:
> On Tue, 7 May 2019, Markus Kilbinger wrote:
[...]
This is a really great thread, which I am enjoying very much.
I don't use any BPi because I am a user of Orange Pi (especially the
OPi+2E).
But considering they are very close in architecture and use
> On May 7, 2019, at 2:37 PM, Jared McNeill wrote:
>
> On Tue, 7 May 2019, Markus Kilbinger wrote:
>
>> - I was not able to bootarm.efi this kernel from its local ffs2 (!)
>> netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?
>
> It uses ffs support from libsa, so I would expect
On Tue, 7 May 2019, Markus Kilbinger wrote:
- I was not able to bootarm.efi this kernel from its local ffs2 (!)
netbsd partition on the sdcrad. Is bootarm.efi limited to ffs1?
It uses ffs support from libsa, so I would expect it to work (but can't
say that I have tried it on armv7).
- In c
Am Di., 7. Mai 2019 um 12:17 Uhr schrieb Jared McNeill :
> [...]
> Now on to the modern boot method..
>
> Using U-Boot 2018.11 or later, setup a FAT partition with the following files
> on it:
>
> EFI/BOOT/bootarm.efi
> your-fdt-file.dtb
>
> U-Boot will automatically launch the UEFI bootloader
The NetBSD-current/i386 build is working again.
The following commits were made between the last failed build and the
successful build:
2019.05.07.10.22.54 hannken src/tools/Makefile,v 1.203
Log files can be found at:
http://releng.NetBSD.org/b5reports/i386/commits-2019.05.html#2019.05
That looks much cleaner will try that.
Frank
On 05/01/19 22:58, Jared McNeill wrote:
So there is a better way to boot modern NetBSD/arm (using UEFI and
bootarm.efi). If you want to boot the old way, it goes something like
this:
setenv bootargs root=ld0a console=fb
fatload mmc 0 $kernel_
So there is a better way to boot modern NetBSD/arm (using UEFI and
bootarm.efi). If you want to boot the old way, it goes something like this:
setenv bootargs root=ld0a console=fb
fatload mmc 0 $kernel_addr_r netbsd-GENERIC.ub
fatload mmc 0 $fdt_addr_r $fdtfile
fdt addr $fdt_addr_r
boot
Yesterday I updated my machine (on i386 port, code base probably few days
behind from latest) and I had few observations:
1) upgrade using build.sh didn't build/install kernel modules it seems
(using distribution goal). I needed to build them separately and use
installmodules. Is it intended chang
I think Christos has kindly fixed this for me.Roy
13 matches
Mail list logo
