Re: Status of RPi 3 (b) ?
Swift Griggs writes: > On Thu, 5 Jan 2017, Brad Spencer wrote: [snip] >> I have 3 RPI3b v1.2 boards. Two of them will not boot NetBSD 9 out of >> 10 times. They will hang between these two lines: > > That sounds like a bummer. I'll watch for the same issue. Ya, annoying ... >> Raspbian works fine on those boards [at least it does on one of them, I >> don't remember if I tried both] and 1 time in 10 NetBSD will get past >> that point and run fine. The third RPI3 board appears to boot NetBSD >> just fine, as does my RPI2. I hope you have one that works out for you. > > Weird. I wonder if it's firmware related... There are some warnings about > upgrading firmware on the RPi Wiki page. > >> The two RPI3s that hang were purchased at different times from different >> places, but as far as I can tell are all the same board. > > Yeah, that definitely seems like it'd be firmware related. It's the same > SoC and other bits. I tried replacing the linux kernel on a Raspbian image with the NetBSD kernel and adjusting the config lines in cmdline.txt and config.txt to boot NetBSD and it still hung in the same place. One would expect the Raspbian image to use the latest firmware, but perhaps not... >> Right now the RPI3 runs like a RPI2, more or less, in terms of devices. > > I've got an RPi v2 on the way, also. If I have to fight the v3 too much > I'll just downgrade. The downside is the RPi is supposed to be about 2x > the speed of the RPi2. Of course, I'm not building a compute cluster with > them in any case (yet! hehe). As was mentioned you will get a 32 bit system, and I am not sure that the CPUs are running at their highest clock: cpu0 at mainbus0 core 0: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) ^^^ .. but sysctl says: machdep.cpu.frequency.current = 1200 > -Swift -- Brad Spencer - b...@anduin.eldar.org - KC8VKS http://anduin.eldar.org - & - http://anduin.ipv6.eldar.org [IPv6 only]
Re: Status of RPi 3 (b) ?
On Thu, 5 Jan 2017, Brad Spencer wrote: You will need to use something -currentish. I mostly run a 7.99.42 kernel with some local mods. Thanks for the tip. I have 3 RPI3b v1.2 boards. Two of them will not boot NetBSD 9 out of 10 times. They will hang between these two lines: That sounds like a bummer. I'll watch for the same issue. Raspbian works fine on those boards [at least it does on one of them, I don't remember if I tried both] and 1 time in 10 NetBSD will get past that point and run fine. The third RPI3 board appears to boot NetBSD just fine, as does my RPI2. I hope you have one that works out for you. Weird. I wonder if it's firmware related... There are some warnings about upgrading firmware on the RPi Wiki page. The two RPI3s that hang were purchased at different times from different places, but as far as I can tell are all the same board. Yeah, that definitely seems like it'd be firmware related. It's the same SoC and other bits. Right now the RPI3 runs like a RPI2, more or less, in terms of devices. I've got an RPi v2 on the way, also. If I have to fight the v3 too much I'll just downgrade. The downside is the RPi is supposed to be about 2x the speed of the RPi2. Of course, I'm not building a compute cluster with them in any case (yet! hehe). -Swift
Re: Status of RPi 3 (b) ?
Swift Griggs writes: > On Thu, 5 Jan 2017, Brian Buhrow wrote: >> I'm using NetBSD-current on an RPI3, using the RPI2 images. Everything >> seems to work except for the wireless and bluetooth modules. > > Right on. I was trying a 7.x release, I think. I can't remember. Anyhow, > I'll just use a -current image and try again. At least now I know it's > worth trying, so thanks for that. > >> The dmesg for this is below. Note that this is -current from the end of >> November 2016. -Brian > > Hmm, well, unless something has been broken between now and then, that > should be okay. As far as wireless & BT, they are "nice to have". Since > the RPi3 has 4 USB ports, I can just use one of those if I need Bluetooth > or Wifi to hork up my privacy. :-) > > -Swift You will need to use something -currentish. I mostly run a 7.99.42 kernel with some local mods. I have 3 RPI3b v1.2 boards. Two of them will not boot NetBSD 9 out of 10 times. They will hang between these two lines: usb0 at dwctwo0: USB revision 2.0 ---hangs here--- timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 Raspbian works fine on those boards [at least it does on one of them, I don't remember if I tried both] and 1 time in 10 NetBSD will get past that point and run fine. The third RPI3 board appears to boot NetBSD just fine, as does my RPI2. I hope you have one that works out for you. The two RPI3s that hang were purchased at different times from different places, but as far as I can tell are all the same board. Right now the RPI3 runs like a RPI2, more or less, in terms of devices. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS http://anduin.eldar.org - & - http://anduin.ipv6.eldar.org [IPv6 only]
Re: Status of RPi 3 (b) ?
I'm sitting here complaining to the Lives group about the unsharp mask plugin, trying to sharpen a video, on my 3B under Raspbian. Haven't tried NetBSD on it in a couple months. I thought the WiFi worked with plugin USB WiFi dongles though. At $5 or less they're an option. -- Credit is the root of all evil. - AB1JX
Re: Status of RPi 3 (b) ?
On Thu, 5 Jan 2017, Brian Buhrow wrote: I'm using NetBSD-current on an RPI3, using the RPI2 images. Everything seems to work except for the wireless and bluetooth modules. Right on. I was trying a 7.x release, I think. I can't remember. Anyhow, I'll just use a -current image and try again. At least now I know it's worth trying, so thanks for that. The dmesg for this is below. Note that this is -current from the end of November 2016. -Brian Hmm, well, unless something has been broken between now and then, that should be okay. As far as wireless & BT, they are "nice to have". Since the RPi3 has 4 USB ports, I can just use one of those if I need Bluetooth or Wifi to hork up my privacy. :-) -Swift
Re: Status of RPi 3 (b) ?
hello. I'm using NetBSD-current on an RPI3, using the RPI2 images. Everything seems to work except for the wireless and bluetooth modules. The dmesg for this is below. Note that this is -current from the end of November 2016. -Brian Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 7.99.43 (RPI2.201611300120Z) total memory = 944 MB avail memory = 925 MB sysctl_createv: sysctl_create(machine_arch) returned 17 timecounter: Timecounters tick every 10.000 msec mainbus0 (root) cpu0 at mainbus0 core 0: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB/64B 2-way L1 VIPT Instruction cache cpu0: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache cpu0: 512KB/64B 16-way write-through L2 PIPT Unified cache vfp0 at cpu0: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals cpu1 at mainbus0 core 1 cpu2 at mainbus0 core 2 cpu3 at mainbus0 core 3 obio0 at mainbus0 bcmicu0 at obio0: Multiprocessor armgtmr0 at obio0: ARMv7 Generic 64-bit Timer (19200 kHz) armgtmr0: interrupting on irq 3 timecounter: Timecounter "armgtmr0" frequency 1920 Hz quality 500 bcmmbox0 at obio0 intr 193: VC mailbox vcmbox0 at bcmmbox0 vchiq0 at obio0 intr 194: BCM2835 VCHIQ bcmpm0 at obio0: Power management, Reset and Watchdog controller bcmdmac0 at obio0: DMA0 DMA2 DMA4 DMA5 DMA8 DMA9 DMA10 bcmrng0 at obio0: RNG plcom0 at obio0 intr 185 plcom0: txfifo disabled plcom0: console genfb0 at obio0: switching to framebuffer console genfb0: framebuffer at 0xfd876000, size 1280x720, depth 32, stride 5120 wsdisplay0 at genfb0 kbdmux 1: console (default, vt100 emulation) wsmux1: connecting to wsdisplay0 wsdisplay0: screen 1-3 added (default, vt100 emulation) sdhc0 at obio0 intr 190: SDHC controller sdhc0: interrupting on intr 190 dwctwo0 at obio0 intr 137: USB controller bcmspi0 at obio0 intr 182: SPI spi0 at bcmspi0: SPI bus bsciic0 at obio0 intr 181: BSC0 iic0 at bsciic0: I2C bus bsciic1 at obio0 intr 181: BSC1 iic1 at bsciic1: I2C bus bcmgpio0 at obio0: GPIO [0...31] gpio0 at bcmgpio0: 32 pins bcmgpio1 at obio0: GPIO [32...53] gpio1 at bcmgpio1: 22 pins bcmcm at obio0 not configured bcmpwm at obio0 not configured usb0 at dwctwo0: USB revision 2.0 timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 cpu1: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) cpu1: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu1: 32KB/64B 2-way L1 VIPT Instruction cache cpu1: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache cpu1: 512KB/64B 16-way write-through L2 PIPT Unified cache vfp1 at cpu1: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals cpu3: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) cpu3: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu3: 32KB/64B 2-way L1 VIPT Instruction cache cpu3: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache cpu3: 512KB/64B 16-way write-through L2 PIPT Unified cache vfp3 at cpu3: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals cpu2: 600 MHz Cortex-A53 r0p4 (Cortex V8A core) cpu2: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu2: 32KB/64B 2-way L1 VIPT Instruction cache cpu2: 32KB/64B 4-way write-back-locking-C L1 PIPT Data cache cpu2: 512KB/64B 16-way write-through L2 PIPT Unified cache vfp2 at cpu2: NEON MPE (VFP 3.0+), rounding, NaN propagation, denormals sdhc0: SDHC 3.0, rev 153, platform DMA, 25 kHz, HS SDR50 3.3V, re-tuning mode 1, 1024 byte blocks sdmmc0 at sdhc0 slot 0 uhub0 at usb0: vendor DWC2 root hub, class 9/0, rev 2.00/1.00, addr 1 uhub0: 1 port with 1 removable, self powered IPsec: Initialized Security Association Processing. ld0 at sdmmc0: <0x1b:0x534d:0:0x10:0x09f15f20:0x106> ld0: 30543 MB, 7756 cyl, 128 head, 63 sec, 512 bytes/sect x 62552064 sectors ld0: 4-bit width, SDR50, 100.000 MHz uhub1 at uhub0 port 1: vendor 0424 product 9514, class 9/0, rev 2.00/2.00, addr 2 uhub1: multiple transaction translators uhub1: 5 ports with 4 removable, self powered usmsc0 at uhub1 port 1 usmsc0: vendor 0424 product ec00, rev 2.00/2.00, addr 3 usmsc0: Ethernet address b8:27:eb:XX:XX:XX ukphy0 at usmsc0 phy 1: OUI 0x00800f, model 0x000c, rev. 3 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto uhub0: illegal enable change, port 1 WARNING: 1 error while detecting hardware; check system log. boot device: ld0 root on ld0a dumps on ld0b root file system type: ffs kern.module.path=/stand/evbarm/7.99.43/modules vchiq: local ver 6 (min 3), remote ver 6. vcaudio0 at vchiq0: auds vchiq_get_state: g_state.remote->initialised != 1 (0) vchiq: vchiq_initialise: videocore initialized after 1 retries WARNING: no TOD clock present WARNING: using filesystem time WARNING: CHEC
Status of RPi 3 (b) ?
I just picked up an RPI3. I guess I should have waited. A few congenitally systemd-infected distros work on it, but not much else. FreeBSD was a notable exception. It seems to work, but I managed to hork up the SD card jacking around with ZFS before I could test X11 and other stuff. No big deal. However, before I start over, how about NetBSD? When I tried to boot the gzimg on the SD card it just came up with what looked like a multicolor test pattern, but no boot etc... That was just a quick and dirty test. I could have been doing any number of things wrong. For one, I wasn't using -current. My real question is: Does NetBSD work well enough on the RPi3 to make it worth trying ? Also, could one of the anointed ones update the RPI wiki for the RPi3 ? There is only a brief mention of the RPi3 in the firmware section (nothing that helpful) and another user in the comment section is seeing the exact same thing as me. -Swift
Re: Why is a wedge on RAID 10x slower?
On Thu, 5 Jan 2017, Patrick Welche wrote: On Wed, Nov 30, 2016 at 11:30:51AM +, Stephen Borrill wrote: mlelstv pointed out that because of the 64 sectPerSU RAIDframe setting (i.e. 128 sectors of data with 3 components, or 64k), the stripe unit is 32k, but the whole stripe is 64k. By starting the wedge at 64 sectors, this is 32k, but I'm attempting to do 64k I/O. Therefore the wedge should start at 128, not 64 # dkctl raid0 addwedge bigdata 128 15628073823 ffs dk3 created successfully. To check: this means the bigdata wedge on raid0 has to be correctly aligned, but the raid0 wedge on wd0 doesn't need to be? It would still need to be correctly aligned for the underlying sector size of the drive to avoid problems at the lowest level. -- Stephen
Re: Why is a wedge on RAID 10x slower?
On Wed, Nov 30, 2016 at 11:30:51AM +, Stephen Borrill wrote: > mlelstv pointed out that because of the 64 sectPerSU RAIDframe setting (i.e. > 128 sectors of data with 3 components, or 64k), the stripe unit is 32k, but > the whole stripe is 64k. By starting the wedge at 64 sectors, > this is 32k, but I'm attempting to do 64k I/O. Therefore the wedge should > start at 128, not 64 > > # dkctl raid0 addwedge bigdata 128 15628073823 ffs > dk3 created successfully. To check: this means the bigdata wedge on raid0 has to be correctly aligned, but the raid0 wedge on wd0 doesn't need to be? Cheers, Patrick