Re: Raspberry Pi 3 booting from USB

[Jonathan Gray]

On Mon, Mar 06, 2017 at 07:46:30AM +0100, Otto Moerbeek wrote:
> On Sun, Mar 05, 2017 at 09:41:27AM -0500, Joe Gidi wrote:
> 
> > I was stuck at that point for a while. Make sure you have everything you 
> > need
> > to boot on the DOS partition of your USB drive; mine was missing u-boot.bin.
> > Are you using the bootcode.bin and start.elf files from Raspbian?
> 
> I'm using the files as installed by the installer. But indeed,
> u-boot.bin is missing on the i partition on the USB disk. Will add
> that (and find out why it isn't there) tonight.  In the meantime I'm
> doing a make build, which does not seem to be stable yet. I've seen
> segfaults now and then plus at least one malloc use-after-free error.
> 
>   -Otto
> 

Missing something like this, should already be present as
/usr/mdec/rpi/u-boot.bin on the ramdisk.

Index: install.md
===
RCS file: /cvs/src/distrib/arm64/ramdisk/install.md,v
retrieving revision 1.2
diff -u -p -r1.2 install.md
--- install.md  18 Feb 2017 02:01:53 -  1.2
+++ install.md  6 Mar 2017 06:55:24 -
@@ -56,6 +56,8 @@ md_installboot() {
device_tree_address=0x100
kernel=u-boot.bin
__EOT
+
+   cp $_mdec/u-boot.bin /mnt/mnt/
 }
 
 md_prep_fdisk() {

Re: Raspberry Pi 3 booting from USB

[Otto Moerbeek]

On Sun, Mar 05, 2017 at 09:41:27AM -0500, Joe Gidi wrote:

> I was stuck at that point for a while. Make sure you have everything you need
> to boot on the DOS partition of your USB drive; mine was missing u-boot.bin.
> Are you using the bootcode.bin and start.elf files from Raspbian?

I'm using the files as installed by the installer. But indeed,
u-boot.bin is missing on the i partition on the USB disk. Will add
that (and find out why it isn't there) tonight.  In the meantime I'm
doing a make build, which does not seem to be stable yet. I've seen
segfaults now and then plus at least one malloc use-after-free error.

-Otto

Re: Speed tests on 11n / 11g and on different channels with the latest 6.1 snapshot from yesterday. Patterns can be observed.

[techay]

In my post I stated what the ethernet speed was, using speedtest.net, these 
speeds are consistent with what I would expect from my line as I do regular 
speed tests. I know from possibly 300 speed tests in the past week alone what 
my averages are on both ethernet off the router I built with OpenBSD, the 
router I have with pfSesne and the router I have from my ISP. Iam extremely 
familiar with the speed I get. And not just from the ethernet, but from all the 
wireless devices on pfSense, OpenBSD and ISP router firewalls. So, please.. 
don't insult my intelligence by telling me I can't be sure of anything - that's 
why I do multiple testing from everything. But thanks for your input.






 Original Message 
Subject: Re: Speed tests on 11n / 11g and on different channels with the latest 
6.1 snapshot from yesterday. Patterns can be observed.
Local Time: 6 March 2017 3:49 AM
UTC Time: 6 March 2017 02:49
From: zel...@zeloff.org
To: tec...@protonmail.com
misc@openbsd.org

On Sun, Mar 05, 2017 at 04:04:00PM -0500, tec...@protonmail.com wrote:
> Why does it make no sense? It's a real world test on actual
> performance noticed by a client. It absolutely makes sense. Yes there
> are other tests which could be performed on top of that testing,
> obviously.

Because if you are comparing the results of different test runs you are
assuming that the bandwidth from your gateway to the speedtest.net
server is constant. And it might not be for a lot of reasons. Maybe it
is constant, and in that case all's good, but you can't be sure, can
you? So no, it doesn't make sense. If you want to test bandwidth from
machine A to machine B, you measure it from A to B not from A to Z and
assume B to Z is constant.


>  Original Message 
> Subject: Re: Speed tests on 11n / 11g and on different channels with the 
> latest 6.1 snapshot from yesterday. Patterns can be observed.
> Local Time: 5 March 2017 9:29 PM
> UTC Time: 5 March 2017 20:29
> From: paol...@gmail.com
> To: misc@openbsd.org
>
> In order to measure the performance of a wireless 802.11 connection,
> speedtest.net makes no sense.
>
> U'd better use iperf on your lan.
>
> Il 05/mar/2017 07:45 PM,  ha scritto:
>
> > Forgot to mention that the speed tests were performed using
> > https://speedtest.net from a mobile client connected to the AP.
> >
> > But yeah, the uploads can be pretty damn good on channels with less
> > interference.
> >
> > Thanks for letting me know about the key issue in my logs. Luckily, it was
> > just a temporary password/key for testing purposes.
> >
> > I will try the patch later and do a quick test and provide just the best
> > result!
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Mar 04, 2017 at 11:16:28PM -0500, tec...@protonmail.com wrote:
> > > Hi,
> > >
> > > I have performed some speed tests with my AP (AR9287) using both 11g and
> > 11n.
> > > I am on the latest 6.1 snapshot from yestrerday.
> >
> > Thanks for taking the time to test!
> >
> > > For comparison sake, I have included tests on different channels.
> >
> > Reporting just the best results is good enough for me.
> >
> > Channels are occupied differently everywhere and occupation patterns change
> > constantly. So this comparison is mostly useful for yourself, since it
> > tells
> > you which channel is working best at your location (until some AP in your
> > area decides that this channel is so good that it is going to use it, too).
> >
> > > I have approx 70mbps download speed on my ethernet connection, and an
> > upload of under 20mbps.
> > >
> > > A pattern can be observed in these results.
> > >
> > > Upload speed is way above the download speed, infact in many of the
> > > results the upload speed is hitting the same speeds as my ethernet
> > > connection.
> >
> > What is down, and what is up?
> > Is traffic going from the client to the AP what you call "upstream"?
> >
> > There is a known issue where an A won't transmit reliably at higher data
> > rates with our athn(4) driver. I have no idea yet what is causing this
> > problem.
> >
> > > Generally 11n upload speed is better, but on one of the channels - 5 -
> > > both down and upload were pretty dire. Not sure if it is interference,
> > > or wether the card is handling that particulary well.
> >
> > Most likely there is another busy network on channel 5.
> >
> > > Upper channels seem to provide the best performance.
> > >
> > > Hope these tests help in some way.
> >
> > Your numbers are in the ranges as the ones I get. This patch (not
> > committed yet, and not in snaps) might make things a bit faster:
> > https://marc.info/?l=openbsd-tech=148866151017854=raw
>

--

Re: Speed tests on 11n / 11g and on different channels with the latest 6.1 snapshot from yesterday. Patterns can be observed.

[Zé Loff]

On Sun, Mar 05, 2017 at 04:04:00PM -0500, tec...@protonmail.com wrote:
> Why does it make no sense? It's a real world test on actual
> performance noticed by a client. It absolutely makes sense. Yes there
> are other tests which could be performed on top of that testing,
> obviously.

Because if you are comparing the results of different test runs you are
assuming that the bandwidth from your gateway to the speedtest.net
server is constant.  And it might not be for a lot of reasons.  Maybe it
is constant, and in that case all's good, but you can't be sure, can
you?  So no, it doesn't make sense.  If you want to test bandwidth from
machine A to machine B, you measure it from A to B not from A to Z and
assume B to Z is constant.


>  Original Message 
> Subject: Re: Speed tests on 11n / 11g and on different channels with the 
> latest 6.1 snapshot from yesterday. Patterns can be observed.
> Local Time: 5 March 2017 9:29 PM
> UTC Time: 5 March 2017 20:29
> From: paol...@gmail.com
> To: misc@openbsd.org
> 
> In order to measure the performance of a wireless 802.11 connection,
> speedtest.net makes no sense.
> 
> U'd better use iperf on your lan.
> 
> Il 05/mar/2017 07:45 PM,  ha scritto:
> 
> > Forgot to mention that the speed tests were performed using
> > https://speedtest.net from a mobile client connected to the AP.
> >
> > But yeah, the uploads can be pretty damn good on channels with less
> > interference.
> >
> > Thanks for letting me know about the key issue in my logs. Luckily, it was
> > just a temporary password/key for testing purposes.
> >
> > I will try the patch later and do a quick test and provide just the best
> > result!
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Mar 04, 2017 at 11:16:28PM -0500, tec...@protonmail.com wrote:
> > > Hi,
> > >
> > > I have performed some speed tests with my AP (AR9287) using both 11g and
> > 11n.
> > > I am on the latest 6.1 snapshot from yestrerday.
> >
> > Thanks for taking the time to test!
> >
> > > For comparison sake, I have included tests on different channels.
> >
> > Reporting just the best results is good enough for me.
> >
> > Channels are occupied differently everywhere and occupation patterns change
> > constantly. So this comparison is mostly useful for yourself, since it
> > tells
> > you which channel is working best at your location (until some AP in your
> > area decides that this channel is so good that it is going to use it, too).
> >
> > > I have approx 70mbps download speed on my ethernet connection, and an
> > upload of under 20mbps.
> > >
> > > A pattern can be observed in these results.
> > >
> > > Upload speed is way above the download speed, infact in many of the
> > > results the upload speed is hitting the same speeds as my ethernet
> > > connection.
> >
> > What is down, and what is up?
> > Is traffic going from the client to the AP what you call "upstream"?
> >
> > There is a known issue where an A won't transmit reliably at higher data
> > rates with our athn(4) driver. I have no idea yet what is causing this
> > problem.
> >
> > > Generally 11n upload speed is better, but on one of the channels - 5 -
> > > both down and upload were pretty dire. Not sure if it is interference,
> > > or wether the card is handling that particulary well.
> >
> > Most likely there is another busy network on channel 5.
> >
> > > Upper channels seem to provide the best performance.
> > >
> > > Hope these tests help in some way.
> >
> > Your numbers are in the ranges as the ones I get. This patch (not
> > committed yet, and not in snaps) might make things a bit faster:
> > https://marc.info/?l=openbsd-tech=148866151017854=raw
> 

-- 

Re: reorder_libs() from /etc/rc when using NFS root FS

[magraith]

hi I'm a noob to openbsd but I've just installed the macppc version of
openbsd 6.0 and my boot frequently hangs on "reordering libraries" ...so I
found this thread. Just got it installed from the CD I burned, yesterday.
tyring to determine whether I fried my firmware  in all my messing around
trying to get the machine to boot from a couple different CDs, or it's  a
bad install, or my old Powermac G4 Sawtooth is flaky...

hope I haven't abused the point of this thread too much, or any protocols of
the forum. Getting tired of banging my head and flipping through Michael
Lucas's fascinating and mysterious openbsd book for possibilities... (I'm
not a sysadmin so some of it goes flying over my head at this point)

cheers
Ian



--
View this message in context: 
http://openbsd-archive.7691.n7.nabble.com/reorder-libs-from-etc-rc-when-using-NFS-root-FS-tp300116p314235.html
Sent from the openbsd user - misc mailing list archive at Nabble.com.

Re: Speed tests on 11n / 11g and on different channels with the latest 6.1 snapshot from yesterday.

[Mihai Popescu]

> Why does it make no sense? It's a real world test on actual performance 
> noticed by a > client. It absolutely makes sense. Yes there are other tests 
> which could be performed
> on top of that testing, obviously.

Just as an irony, last week I was so pissed of about wireless
performance between two points (OpenBSD not involved, LEDE and some
dedicated ZTE) so that I setup wireless channel to auto. After that my
download speed tripled.

Looking at techie articles, they tell you to fix the channel on 1, 5,
or 11. I was so intrigued over years about that, since the wireless
tech is a jumping channel communication. Well, what do I know, just
reading!

I suspect WiFi is like other "standards", I will not dive in details.
I admire Stefan for what he is doing for OpenBSD wireless. And the
others are great, too.

Re: Speed tests on 11n / 11g and on different channels with the latest 6.1 snapshot from yesterday. Patterns can be observed.

[techay]

Why does it make no sense? It's a real world test on actual performance noticed 
by a client. It absolutely makes sense. Yes there are other tests which could 
be performed on top of that testing, obviously.





 Original Message 
Subject: Re: Speed tests on 11n / 11g and on different channels with the latest 
6.1 snapshot from yesterday. Patterns can be observed.
Local Time: 5 March 2017 9:29 PM
UTC Time: 5 March 2017 20:29
From: paol...@gmail.com
To: misc@openbsd.org

In order to measure the performance of a wireless 802.11 connection,
speedtest.net makes no sense.

U'd better use iperf on your lan.

Il 05/mar/2017 07:45 PM,  ha scritto:

> Forgot to mention that the speed tests were performed using
> https://speedtest.net from a mobile client connected to the AP.
>
> But yeah, the uploads can be pretty damn good on channels with less
> interference.
>
> Thanks for letting me know about the key issue in my logs. Luckily, it was
> just a temporary password/key for testing purposes.
>
> I will try the patch later and do a quick test and provide just the best
> result!
>
>
>
>
>
>
>
> On Sat, Mar 04, 2017 at 11:16:28PM -0500, tec...@protonmail.com wrote:
> > Hi,
> >
> > I have performed some speed tests with my AP (AR9287) using both 11g and
> 11n.
> > I am on the latest 6.1 snapshot from yestrerday.
>
> Thanks for taking the time to test!
>
> > For comparison sake, I have included tests on different channels.
>
> Reporting just the best results is good enough for me.
>
> Channels are occupied differently everywhere and occupation patterns change
> constantly. So this comparison is mostly useful for yourself, since it
> tells
> you which channel is working best at your location (until some AP in your
> area decides that this channel is so good that it is going to use it, too).
>
> > I have approx 70mbps download speed on my ethernet connection, and an
> upload of under 20mbps.
> >
> > A pattern can be observed in these results.
> >
> > Upload speed is way above the download speed, infact in many of the
> > results the upload speed is hitting the same speeds as my ethernet
> > connection.
>
> What is down, and what is up?
> Is traffic going from the client to the AP what you call "upstream"?
>
> There is a known issue where an A won't transmit reliably at higher data
> rates with our athn(4) driver. I have no idea yet what is causing this
> problem.
>
> > Generally 11n upload speed is better, but on one of the channels - 5 -
> > both down and upload were pretty dire. Not sure if it is interference,
> > or wether the card is handling that particulary well.
>
> Most likely there is another busy network on channel 5.
>
> > Upper channels seem to provide the best performance.
> >
> > Hope these tests help in some way.
>
> Your numbers are in the ranges as the ones I get. This patch (not
> committed yet, and not in snaps) might make things a bit faster:
> https://marc.info/?l=openbsd-tech=148866151017854=raw

Re: Speed tests on 11n / 11g and on different channels with the latest 6.1 snapshot from yesterday. Patterns can be observed.

[Paolo Aglialoro]

In order to measure the performance of a wireless 802.11 connection,
speedtest.net makes no sense.

U'd better use iperf on your lan.

Il 05/mar/2017 07:45 PM,  ha scritto:

> Forgot to mention that the speed tests were performed using
> https://speedtest.net from a mobile client connected to the AP.
>
> But yeah, the uploads can be pretty damn good on channels with less
> interference.
>
> Thanks for letting me know about the key issue in my logs. Luckily, it was
> just a temporary password/key for testing purposes.
>
> I will try the patch later and do a quick test and provide just the best
> result!
>
>
>
>
>
>
>
> On Sat, Mar 04, 2017 at 11:16:28PM -0500, tec...@protonmail.com wrote:
> > Hi,
> >
> > I have performed some speed tests with my AP (AR9287) using both 11g and
> 11n.
> > I am on the latest 6.1 snapshot from yestrerday.
>
> Thanks for taking the time to test!
>
> > For comparison sake, I have included tests on different channels.
>
> Reporting just the best results is good enough for me.
>
> Channels are occupied differently everywhere and occupation patterns change
> constantly. So this comparison is mostly useful for yourself, since it
> tells
> you which channel is working best at your location (until some AP in your
> area decides that this channel is so good that it is going to use it, too).
>
> > I have approx 70mbps download speed on my ethernet connection, and an
> upload of under 20mbps.
> >
> > A pattern can be observed in these results.
> >
> > Upload speed is way above the download speed, infact in many of the
> > results the upload speed is hitting the same speeds as my ethernet
> > connection.
>
> What is down, and what is up?
> Is traffic going from the client to the AP what you call "upstream"?
>
> There is a known issue where an A won't transmit reliably at higher data
> rates with our athn(4) driver. I have no idea yet what is causing this
> problem.
>
> > Generally 11n upload speed is better, but on one of the channels - 5 -
> > both down and upload were pretty dire. Not sure if it is interference,
> > or wether the card is handling that particulary well.
>
> Most likely there is another busy network on channel 5.
>
> > Upper channels seem to provide the best performance.
> >
> > Hope these tests help in some way.
>
> Your numbers are in the ranges as the ones I get. This patch (not
> committed yet, and not in snaps) might make things a bit faster:
> https://marc.info/?l=openbsd-tech=148866151017854=raw

Re: Speed tests on 11n / 11g and on different channels with the latest 6.1 snapshot from yesterday. Patterns can be observed.

[techay]

Forgot to mention that the speed tests were performed using 
https://speedtest.net from a mobile client connected to the AP.

But yeah, the uploads can be pretty damn good on channels with less 
interference.

Thanks for letting me know about the key issue in my logs. Luckily, it was just 
a temporary password/key for testing purposes.

I will try the patch later and do a quick test and provide just the best result!







On Sat, Mar 04, 2017 at 11:16:28PM -0500, tec...@protonmail.com wrote:
> Hi,
>
> I have performed some speed tests with my AP (AR9287) using both 11g and 11n.
> I am on the latest 6.1 snapshot from yestrerday.

Thanks for taking the time to test!

> For comparison sake, I have included tests on different channels.

Reporting just the best results is good enough for me.

Channels are occupied differently everywhere and occupation patterns change
constantly. So this comparison is mostly useful for yourself, since it tells
you which channel is working best at your location (until some AP in your
area decides that this channel is so good that it is going to use it, too).

> I have approx 70mbps download speed on my ethernet connection, and an upload 
> of under 20mbps.
>
> A pattern can be observed in these results.
>
> Upload speed is way above the download speed, infact in many of the
> results the upload speed is hitting the same speeds as my ethernet
> connection.

What is down, and what is up?
Is traffic going from the client to the AP what you call "upstream"?

There is a known issue where an A won't transmit reliably at higher data
rates with our athn(4) driver. I have no idea yet what is causing this problem.

> Generally 11n upload speed is better, but on one of the channels - 5 -
> both down and upload were pretty dire. Not sure if it is interference,
> or wether the card is handling that particulary well.

Most likely there is another busy network on channel 5.

> Upper channels seem to provide the best performance.
>
> Hope these tests help in some way.

Your numbers are in the ranges as the ones I get. This patch (not
committed yet, and not in snaps) might make things a bit faster:
https://marc.info/?l=openbsd-tech=148866151017854=raw

Re: softraid & GPT configuration.

[Christian Weisgerber]

On 2017-03-03, Eric Huiban  wrote:

> bioctl needs a mandatory bootable partition to act correctly even on 
> disks not aimed to be bootable.

I find that very surprising.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: Raspberry Pi 3 booting from USB

[Joe Gidi]

I was stuck at that point for a while. Make sure you have everything you need
to boot on the DOS partition of your USB drive; mine was missing u-boot.bin.
Are you using the bootcode.bin and start.elf files from Raspbian?


On March 5, 2017 9:25:59 AM EST, Otto Moerbeek  wrote:
>On Mon, Mar 06, 2017 at 12:36:55AM +1100, Jonathan Gray wrote:
>
>> The arm64 miniroot and bsd.rd already include fixup.dat and dtbs
>> from https://github.com/raspberrypi/firmware/tree/master/boot
>>
>> There is no need to manually change them.
>
>I managed to get usb booting to work on a external powered device, bus
>powered so far is not working for me.
>
>Also, I need to keep the sd card in, I might have done something
>wrong with the setting of the vars. If I leave the sd card out nothing
>happens on power up.
>
>By telling u-boot to prefer usb0 over mmc0 I got usb booting to work:
>
>setenv boot_targets usb0 mmc0 pxe dhcp
>saveenv
>
>   -Otto

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Raspberry Pi 3 booting from USB

[Otto Moerbeek]

On Mon, Mar 06, 2017 at 12:36:55AM +1100, Jonathan Gray wrote:

> The arm64 miniroot and bsd.rd already include fixup.dat and dtbs
> from https://github.com/raspberrypi/firmware/tree/master/boot
> 
> There is no need to manually change them.

I managed to get usb booting to work on a external powered device, bus
powered so far is not working for me.

Also, I need to keep the sd card in, I might have done something
wrong with the setting of the vars. If I leave the sd card out nothing
happens on power up.

By telling u-boot to prefer usb0 over mmc0 I got usb booting to work:

setenv boot_targets usb0 mmc0 pxe dhcp
saveenv

-Otto

Re: Raspberry Pi 3 booting from USB

[Joe Gidi]

In the case of my admittedly Frankensteined system, it was needed. The files
from Raspbian were different. I will do a clean install when the next snap
comes out with the latest firmware, DTBs, etc.

Do you know why u-boot.bin didn't make it to my USB drive during installation
and had to be manually added?

Thanks,

On March 5, 2017 8:36:55 AM EST, Jonathan Gray  wrote:
>The arm64 miniroot and bsd.rd already include fixup.dat and dtbs
>from https://github.com/raspberrypi/firmware/tree/master/boot
>
>There is no need to manually change them.
>
>On Sun, Mar 05, 2017 at 08:21:56AM -0500, Joe Gidi wrote:
>> >From further tinkering, I discovered that my Pi was only recognizing
>128 MB of
>> RAM until I switched to using the DTB and fixup.dat files from
>Raspbian. Seems
>> that those /boot/ files should be kept in sync.
>>
>> Thanks for all your work on this new platform!
>>
>> On March 5, 2017 3:36:16 AM EST, Jonathan Gray  wrote:
>> >On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
>> >> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
>> >>
>> >> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
>> >> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
>> >> > >
>> >> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a
>USB
>> >device
>> >> > > > might be
>> >> > > > possible, I decided to find out how deep the rabbit hole is.
>> >> > > > As it turns out,
>> >> > > > it's currently a bit convoluted, but it can be made
>> >> > > > to work with OpenBSD.
>> >> > > > First off, USB boot support is just now getting fully ironed
>> >out.
>> >> > > > You'll need
>> >> > > > to update the firmware on your Pi to make it work. I
>> >> > > > installed the latest
>> >> > > > (2017-03-02) Raspbian image to an SD card and
>> >> > > > booted the Pi from that. While
>> >> > > > booted in Raspbian, update the
>> >> > > > firmware:
>> >> > > >
>> >> > > > sudo apt-get update
>> >> > > > sudo apt-get
>> >> > > > install rpi-update
>> >> > > > sudo rpi-update
>> >> > > >
>> >> > > > It's then necessary to actually enable USB
>> >> > > > boot support. Add the
>> >> > > > following 2 lines to /boot/config.txt to enable USB boot
>> >> > > > mode and set
>> >> > > > a 5-second timeout to allow time for USB device
>initialization:
>> >> > > > program_usb_boot_mode=1
>> >> > > > program_usb_boot_timeout=1
>> >> > > >
>> >> > > > NOTE: Apparently these
>> >> > > > variables are set in the Pi's OTP memory, which
>> >> > > > means once they're set, they
>> >> > > > can't ever be unset.
>> >> > > >
>> >> > > > Reboot for the changes to take effect. At this point the
>> >> > > > Pi should be
>> >> > > > ready to support USB booting.
>> >> > > >
>> >> > > > While you still have a working
>> >> > > > Raspbian install, grab a copy of the
>> >> > > > /boot/bootcode.bin and /boot/start.elf
>> >> > > > files for later use; apparently
>> >> > > > we need these special versions of those two
>> >> > > > files for USB boot
>> >> > > > support. At this point we're done with Raspbian and can
>> >> > > > shut it down
>> >> > > > to install OpenBSD.
>> >> > > >
>> >> > > > Next, write the OpenBSD miniroot60.fs to an
>> >> > > > SD card, plug in your USB
>> >> > > > drive, and boot the Pi. You should be greeted with
>> >> > > > the usual OpenBSD
>> >> > > > installer, and you should be able to install to your USB
>> >> > > > drive
>> >> > > > (probably sd0). Once the installer is done, run 'halt',
>unplug
>> >the Pi,
>> >> > > > and remove the SD card and USB drive.
>> >> > > >
>> >> > > > To make your USB drive bootable, you'll
>> >> > > > need to plug it into another
>> >> > > > system and mount its 'i' partition (the FAT32
>> >> > > > boot partition) to make
>> >> > > > a few changes. Replace the bootcode.bin and start.elf
>> >> > > > files with the
>> >> > > > ones from Raspbian, and add the u-boot.bin file from the 'i'
>> >> > > > partition
>> >> > > > of your miniroot60.fs SD card.
>> >> > > >
>> >> > > > With those changes made, your Pi
>> >> > > > should be able to boot OpenBSD
>> >> > > > directly from a USB drive with no SD card
>> >> > > > needed. Note that it seems
>> >> > > > to take around 10 seconds for the Pi to reach the
>> >> > > > OpenBSD bootloader
>> >> > > > and fire up the kernel.
>> >> > > >
>> >> > > > Hope this information is helpful
>> >> > > > to someone...
>> >> > > >
>> >> > > > --
>> >> > > >  Joe Gidi
>> >> > > >  j...@entropicblur.com
>> >> > > >
>> >> > > >  "You cannot buy skill."
>> >> > > > -- Ross Seyfried
>> >> > >
>> >> > > Thanks, I'll try this out soon,
>> >> > >
>> >> > > Some notes of things I saw when trying to boot from a sd-card
>> >using
>> >> > > various a USB devices to install to:
>> >> > >
>> >> > > Some USB devices do seem to hang the rpi3 sometimes while
>u-boot
>> >is
>> >> > > scanning the usb bus, in my case an old USB flash stick.
>> >> > >
>> >> > > With a disk enclosure (2.5" usb bus powered with 

Re: serial port expansion card

[Stuart Henderson]

On 2017/03/05 08:15, Tinker wrote:
> Hi Stuart,
> 
> On 2017-03-04 08:12, Stuart Henderson wrote:
> > On 2017/03/04 00:30, Tinker wrote:
> > > I'd like to know how the 15-25Mbps PCIe UART:s work, e.g.:
> > > 
> > > Exar XR17V354 (4x25mbps):
> ..
> > > Moschip MCS9904 (4x16mbps):
> ..
> > > OXPCIe954:
> ..
> > I don't know about the Exar/Moschip,
> 
> Got to test.
> 
> > the OXPCIe954 doesn't work on
> > OpenBSD, I had it part-working but never managed to get the baud rate
> > right, the clock runs at high speed so needs a larger divisor than other
> > puc(4)'s but things break somewhere.
> 
> Hm. About how badly did it break in your experience?

The UART wasn't running at the speed set (e.g. "cu -s 19200" ran at some
speed other than 19200 baud). It was consistent, i.e. a null-modem between
two ports on the card worked successfully, but couldn't be used to talk to
anything else. I wasn't feeling sufficiently motivated to borrow an
oscilloscope to figure out the actual speed ;)

> > Also you can't determine the number
> > of ports from the pci id, you are supposed to read from the chip to
> > figure it out, so it doesn't fit the usual pucdata.c framework.
> 
> So the kernel needs to have a per-PCI card or chip table of number of ports,
> aha.

Could be done, of course, it's just a bigger change than I wanted to do
without knowing if the speeds could be fixed.

> What about divisors and stuff for the 15-25Mbps modes, should that work out
> of the box =)

Baud rate is stored in ints everywhere so that would need changing for
that sort of speed for starters. Also not sure if we use the full fifos
on some chips, which would certainly be wanted for higher speeds.
Given the ubiquity of ethernet connections I think it would be rather
niche use though..

> Btw, PCI serial devices should be superior to USB cards, shouldn't they -
> USB v1 and v2 have extremely high latency, for instance. For a serial
> terminal it's OK but even for an Internet connection it must suck.

It doesn't seem too bad for USB UMTS adapters..

Re: Raspberry Pi 3 booting from USB

[Jonathan Gray]

The arm64 miniroot and bsd.rd already include fixup.dat and dtbs
from https://github.com/raspberrypi/firmware/tree/master/boot

There is no need to manually change them.

On Sun, Mar 05, 2017 at 08:21:56AM -0500, Joe Gidi wrote:
> >From further tinkering, I discovered that my Pi was only recognizing 128 MB 
> >of
> RAM until I switched to using the DTB and fixup.dat files from Raspbian. Seems
> that those /boot/ files should be kept in sync.
> 
> Thanks for all your work on this new platform!
> 
> On March 5, 2017 3:36:16 AM EST, Jonathan Gray  wrote:
> >On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
> >> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
> >>
> >> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
> >> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
> >> > >
> >> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB
> >device
> >> > > > might be
> >> > > > possible, I decided to find out how deep the rabbit hole is.
> >> > > > As it turns out,
> >> > > > it's currently a bit convoluted, but it can be made
> >> > > > to work with OpenBSD.
> >> > > > First off, USB boot support is just now getting fully ironed
> >out.
> >> > > > You'll need
> >> > > > to update the firmware on your Pi to make it work. I
> >> > > > installed the latest
> >> > > > (2017-03-02) Raspbian image to an SD card and
> >> > > > booted the Pi from that. While
> >> > > > booted in Raspbian, update the
> >> > > > firmware:
> >> > > >
> >> > > > sudo apt-get update
> >> > > > sudo apt-get
> >> > > > install rpi-update
> >> > > > sudo rpi-update
> >> > > >
> >> > > > It's then necessary to actually enable USB
> >> > > > boot support. Add the
> >> > > > following 2 lines to /boot/config.txt to enable USB boot
> >> > > > mode and set
> >> > > > a 5-second timeout to allow time for USB device initialization:
> >> > > > program_usb_boot_mode=1
> >> > > > program_usb_boot_timeout=1
> >> > > >
> >> > > > NOTE: Apparently these
> >> > > > variables are set in the Pi's OTP memory, which
> >> > > > means once they're set, they
> >> > > > can't ever be unset.
> >> > > >
> >> > > > Reboot for the changes to take effect. At this point the
> >> > > > Pi should be
> >> > > > ready to support USB booting.
> >> > > >
> >> > > > While you still have a working
> >> > > > Raspbian install, grab a copy of the
> >> > > > /boot/bootcode.bin and /boot/start.elf
> >> > > > files for later use; apparently
> >> > > > we need these special versions of those two
> >> > > > files for USB boot
> >> > > > support. At this point we're done with Raspbian and can
> >> > > > shut it down
> >> > > > to install OpenBSD.
> >> > > >
> >> > > > Next, write the OpenBSD miniroot60.fs to an
> >> > > > SD card, plug in your USB
> >> > > > drive, and boot the Pi. You should be greeted with
> >> > > > the usual OpenBSD
> >> > > > installer, and you should be able to install to your USB
> >> > > > drive
> >> > > > (probably sd0). Once the installer is done, run 'halt', unplug
> >the Pi,
> >> > > > and remove the SD card and USB drive.
> >> > > >
> >> > > > To make your USB drive bootable, you'll
> >> > > > need to plug it into another
> >> > > > system and mount its 'i' partition (the FAT32
> >> > > > boot partition) to make
> >> > > > a few changes. Replace the bootcode.bin and start.elf
> >> > > > files with the
> >> > > > ones from Raspbian, and add the u-boot.bin file from the 'i'
> >> > > > partition
> >> > > > of your miniroot60.fs SD card.
> >> > > >
> >> > > > With those changes made, your Pi
> >> > > > should be able to boot OpenBSD
> >> > > > directly from a USB drive with no SD card
> >> > > > needed. Note that it seems
> >> > > > to take around 10 seconds for the Pi to reach the
> >> > > > OpenBSD bootloader
> >> > > > and fire up the kernel.
> >> > > >
> >> > > > Hope this information is helpful
> >> > > > to someone...
> >> > > >
> >> > > > --
> >> > > >  Joe Gidi
> >> > > >  j...@entropicblur.com
> >> > > >
> >> > > >  "You cannot buy skill."
> >> > > > -- Ross Seyfried
> >> > >
> >> > > Thanks, I'll try this out soon,
> >> > >
> >> > > Some notes of things I saw when trying to boot from a sd-card
> >using
> >> > > various a USB devices to install to:
> >> > >
> >> > > Some USB devices do seem to hang the rpi3 sometimes while u-boot
> >is
> >> > > scanning the usb bus, in my case an old USB flash stick.
> >> > >
> >> > > With a disk enclosure (2.5" usb bus powered with spinning disk),
> >the
> >> > > hangs did not occur. But I saw another problem that looked to be
> >> > > caused by the reset of the usb bus while the kernel was booting
> >(from
> >> > > sd-card). The disk enclosure did not get recognized in time when
> >the
> >> > > kernel reached the ask root device questions, making it imposible
> >to
> >> > > select the usb drive as boot device.
> >> > >
> >> > > I manged to boot the machine using an externally powered
> >enclosure
> >> > > with a 3.5 disk. I'll be 

Re: Raspberry Pi 3 booting from USB

[Joe Gidi]

>From further tinkering, I discovered that my Pi was only recognizing 128 MB of
RAM until I switched to using the DTB and fixup.dat files from Raspbian. Seems
that those /boot/ files should be kept in sync.

Thanks for all your work on this new platform!

On March 5, 2017 3:36:16 AM EST, Jonathan Gray  wrote:
>On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
>> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
>>
>> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
>> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
>> > >
>> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB
>device
>> > > > might be
>> > > > possible, I decided to find out how deep the rabbit hole is.
>> > > > As it turns out,
>> > > > it's currently a bit convoluted, but it can be made
>> > > > to work with OpenBSD.
>> > > > First off, USB boot support is just now getting fully ironed
>out.
>> > > > You'll need
>> > > > to update the firmware on your Pi to make it work. I
>> > > > installed the latest
>> > > > (2017-03-02) Raspbian image to an SD card and
>> > > > booted the Pi from that. While
>> > > > booted in Raspbian, update the
>> > > > firmware:
>> > > >
>> > > > sudo apt-get update
>> > > > sudo apt-get
>> > > > install rpi-update
>> > > > sudo rpi-update
>> > > >
>> > > > It's then necessary to actually enable USB
>> > > > boot support. Add the
>> > > > following 2 lines to /boot/config.txt to enable USB boot
>> > > > mode and set
>> > > > a 5-second timeout to allow time for USB device initialization:
>> > > > program_usb_boot_mode=1
>> > > > program_usb_boot_timeout=1
>> > > >
>> > > > NOTE: Apparently these
>> > > > variables are set in the Pi's OTP memory, which
>> > > > means once they're set, they
>> > > > can't ever be unset.
>> > > >
>> > > > Reboot for the changes to take effect. At this point the
>> > > > Pi should be
>> > > > ready to support USB booting.
>> > > >
>> > > > While you still have a working
>> > > > Raspbian install, grab a copy of the
>> > > > /boot/bootcode.bin and /boot/start.elf
>> > > > files for later use; apparently
>> > > > we need these special versions of those two
>> > > > files for USB boot
>> > > > support. At this point we're done with Raspbian and can
>> > > > shut it down
>> > > > to install OpenBSD.
>> > > >
>> > > > Next, write the OpenBSD miniroot60.fs to an
>> > > > SD card, plug in your USB
>> > > > drive, and boot the Pi. You should be greeted with
>> > > > the usual OpenBSD
>> > > > installer, and you should be able to install to your USB
>> > > > drive
>> > > > (probably sd0). Once the installer is done, run 'halt', unplug
>the Pi,
>> > > > and remove the SD card and USB drive.
>> > > >
>> > > > To make your USB drive bootable, you'll
>> > > > need to plug it into another
>> > > > system and mount its 'i' partition (the FAT32
>> > > > boot partition) to make
>> > > > a few changes. Replace the bootcode.bin and start.elf
>> > > > files with the
>> > > > ones from Raspbian, and add the u-boot.bin file from the 'i'
>> > > > partition
>> > > > of your miniroot60.fs SD card.
>> > > >
>> > > > With those changes made, your Pi
>> > > > should be able to boot OpenBSD
>> > > > directly from a USB drive with no SD card
>> > > > needed. Note that it seems
>> > > > to take around 10 seconds for the Pi to reach the
>> > > > OpenBSD bootloader
>> > > > and fire up the kernel.
>> > > >
>> > > > Hope this information is helpful
>> > > > to someone...
>> > > >
>> > > > --
>> > > >  Joe Gidi
>> > > >  j...@entropicblur.com
>> > > >
>> > > >  "You cannot buy skill."
>> > > > -- Ross Seyfried
>> > >
>> > > Thanks, I'll try this out soon,
>> > >
>> > > Some notes of things I saw when trying to boot from a sd-card
>using
>> > > various a USB devices to install to:
>> > >
>> > > Some USB devices do seem to hang the rpi3 sometimes while u-boot
>is
>> > > scanning the usb bus, in my case an old USB flash stick.
>> > >
>> > > With a disk enclosure (2.5" usb bus powered with spinning disk),
>the
>> > > hangs did not occur. But I saw another problem that looked to be
>> > > caused by the reset of the usb bus while the kernel was booting
>(from
>> > > sd-card). The disk enclosure did not get recognized in time when
>the
>> > > kernel reached the ask root device questions, making it imposible
>to
>> > > select the usb drive as boot device.
>> > >
>> > > I manged to boot the machine using an externally powered
>enclosure
>> > > with a 3.5 disk. I'll be buying a SSD today to see how that goes.
>> > >
>> > >  -Otto
>> > >
>> >
>> > You don't need to bother with linux, the files are in the
>> > raspberrypi-firmware package with version 1.20170215.  And the next
>> > snapshot will include the newer firmware.
>> >
>> > Though that will take a few days, due to -current moving to 6.1 a
>> > xenocara build will have to be done as well and that tends to
>trigger
>> > problems with stuck and segfaulting processes.
>>
>> Will the 

Re: tlsv1 alert decrypt error

[Joel Sing]

On Thursday 02 March 2017 13:28:08 Kirill Miazine wrote:
> Recently I've noticed a number of error messages in my Exim mail log:
> 
> TLS error on connection from mx1.slc.paypal.com (mx0.slc.paypal.com)
> [173.0.84.226] \ (SSL_accept): error:1403741B:SSL
> routines:ACCEPT_SR_KEY_EXCH:tlsv1 alert decrypt error TLS client
> disconnected cleanly (rejected our certificate?)

This is most likely the same issue as that reported on the libressl@ mailing 
list a day or so ago - expect a fix to arrive shortly.

Re: Fw: Re: AP using AR9287 working yesterday, broken today.. How to diagnose? **THINK I FOUND A BUG**

[Stefan Sperling]

On Sat, Mar 04, 2017 at 08:22:55PM -0500, tec...@protonmail.com wrote:
> Ok, I solved the issue. It's a strange one. I noticed that the AP
> always uses channel 2, but when I set a channel explicitly within the
> hostname.athn0 config then everything would work. So I tried leaving
> the channel off, and again it wouldn't work - just immediate
> disconnect. So I thought, maybe some sort of interference on channel
> 2?.. Nope. I then set the channel to chan 2 and it worked.

Yep, this is a known issue which has been reported before.

I hope it will be fixed eventually but since setting a channel works around
the problem and the channel stays fixed anyway while the AP is running (i.e.
the AP won't switch to a different channel if the channel it picked becomes
worse) this is not a high priority issue.

For now, we just made sure that the FAQ contains recipies which work:
http://www.openbsd.org/faq/faq6.html#Wireless

Re: Speed tests on 11n / 11g and on different channels with the latest 6.1 snapshot from yesterday. Patterns can be observed.

[Stefan Sperling]

On Sat, Mar 04, 2017 at 11:16:28PM -0500, tec...@protonmail.com wrote:
> Hi,
> 
> I have performed some speed tests with my AP (AR9287) using both 11g and 11n.
> I am on the latest 6.1 snapshot from yestrerday.

Thanks for taking the time to test!

> For comparison sake, I have included tests on different channels.

Reporting just the best results is good enough for me.

Channels are occupied differently everywhere and occupation patterns change
constantly. So this comparison is mostly useful for yourself, since it tells
you which channel is working best at your location (until some AP in your
area decides that this channel is so good that it is going to use it, too).

> I have approx 70mbps download speed on my ethernet connection, and an upload 
> of under 20mbps.
> 
> A pattern can be observed in these results.
> 
> Upload speed is way above the download speed, infact in many of the
> results the upload speed is hitting the same speeds as my ethernet
> connection.

What is down, and what is up?
Is traffic going from the client to the AP what you call "upstream"?

There is a known issue where an A won't transmit reliably at higher data
rates with our athn(4) driver. I have no idea yet what is causing this problem.

> Generally 11n upload speed is better, but on one of the channels - 5 -
> both down and upload were pretty dire. Not sure if it is interference,
> or wether the card is handling that particulary well.

Most likely there is another busy network on channel 5.

> Upper channels seem to provide the best performance.
> 
> Hope these tests help in some way.

Your numbers are in the ranges as the ones I get. This patch (not
committed yet, and not in snaps) might make things a bit faster:
https://marc.info/?l=openbsd-tech=148866151017854=raw

Re: AP using AR9287 working yesterday, broken today.. How to diagnose?

[Stefan Sperling]

On Sat, Mar 04, 2017 at 07:18:18PM -0500, tec...@protonmail.com wrote:
> Hi,
> 
> Apologies - missed the important bits!
> 
> 
> 
> # ifconfig -a

It is unwise to run this command as root if you intend to paste its
output in a public forum. As root the output includes your network's
WPA key, which you should now change.

I am receiving multi-line pastes from you as a single line for some reason.
This makes your report hard to read.

> > $ cat /etc/pf.conf
> > int_if="{ vether0 em1 athn0 }" table  { 0.0.0.0/8 10.0.0.0/8 
> > 127.0.0.0/8 169.254.0.0/16 \ 172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 
> > 224.0.0.0/3 \ 192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \ 203.0.113.0/24 
> > } set block-policy drop set loginterface egress set skip on lo0 match in 
> > all scrub (no-df random-id max-mss 1440) match out on egress inet from 
> > !(egress:network) to any nat-to (egress:0) block in quick on egress from 
> >  to any block return out quick on egress from any to  
> > block all pass out quick inet pass in on $int_if inet pass in on egress 
> > inet proto tcp from any to (egress) port 22

After breaking this back up into multiple lines, it reads like this:

int_if="{ vether0 em1 athn0 }"
table  { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
192.168.0.0/16 198.18.0.0/15 198.51.100.0/24 \
203.0.113.0/24 }
set block-policy drop
set loginterface egress
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
match out on egress inet from !(egress:network) to any nat-to (egress:0)
block in quick on egress from  to any block
return out quick on egress from any to 
block all
pass out quick inet
pass in on $int_if inet pass in on egress inet proto tcp from any to (egress) 
port 22

Your problem looks like a misconfigured firewall to me.
Your ruleset is not defining any explicit rules for bridge0.
As far as I can see packets entering bridge0 will match the 'block all' rule.

Things might start working if you add a rule such as: set skip on bridge0
See the bridge(4) man page:

NOTES
 Bridged packets pass through pf(4) filters once as input on the receiving
 interface and once as output on all interfaces on which they are
 forwarded.  In order to pass through the bridge packets must pass any in
 rules on the input and any out rules on the output interface.  Packets
 may be blocked either entering or leaving the bridge.

I recommend you look into tools such as 'pfctl -sr -v' and tcpdump(8)
to learn how to debug your own firewall setup.

Re: Raspberry Pi 3 booting from USB

[Richard Toohey]

On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:


Hope this information is helpful
to someone...

--
  Joe Gidi
  j...@entropicblur.com

  "You cannot buy skill."
-- Ross Seyfried

Thanks for the info, and (a bit off-topic) great to see OpenBSD coming 
to the Pi.


So thanks to everyone making that happen, it is much appreciated.

Re: Raspberry Pi 3 booting from USB

[Jonathan Gray]

On Sun, Mar 05, 2017 at 09:23:13AM +0100, Otto Moerbeek wrote:
> On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:
> 
> > On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
> > > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
> > > 
> > > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB device
> > > > might be
> > > > possible, I decided to find out how deep the rabbit hole is.
> > > > As it turns out,
> > > > it's currently a bit convoluted, but it can be made
> > > > to work with OpenBSD.
> > > > First off, USB boot support is just now getting fully ironed out.
> > > > You'll need
> > > > to update the firmware on your Pi to make it work. I
> > > > installed the latest
> > > > (2017-03-02) Raspbian image to an SD card and
> > > > booted the Pi from that. While
> > > > booted in Raspbian, update the
> > > > firmware:
> > > > 
> > > > sudo apt-get update
> > > > sudo apt-get
> > > > install rpi-update
> > > > sudo rpi-update
> > > > 
> > > > It's then necessary to actually enable USB
> > > > boot support. Add the
> > > > following 2 lines to /boot/config.txt to enable USB boot
> > > > mode and set
> > > > a 5-second timeout to allow time for USB device initialization:
> > > > program_usb_boot_mode=1
> > > > program_usb_boot_timeout=1
> > > > 
> > > > NOTE: Apparently these
> > > > variables are set in the Pi's OTP memory, which
> > > > means once they're set, they
> > > > can't ever be unset.
> > > > 
> > > > Reboot for the changes to take effect. At this point the
> > > > Pi should be
> > > > ready to support USB booting.
> > > > 
> > > > While you still have a working
> > > > Raspbian install, grab a copy of the
> > > > /boot/bootcode.bin and /boot/start.elf
> > > > files for later use; apparently
> > > > we need these special versions of those two
> > > > files for USB boot
> > > > support. At this point we're done with Raspbian and can
> > > > shut it down
> > > > to install OpenBSD.
> > > > 
> > > > Next, write the OpenBSD miniroot60.fs to an
> > > > SD card, plug in your USB
> > > > drive, and boot the Pi. You should be greeted with
> > > > the usual OpenBSD
> > > > installer, and you should be able to install to your USB
> > > > drive
> > > > (probably sd0). Once the installer is done, run 'halt', unplug the Pi,
> > > > and remove the SD card and USB drive.
> > > > 
> > > > To make your USB drive bootable, you'll
> > > > need to plug it into another
> > > > system and mount its 'i' partition (the FAT32
> > > > boot partition) to make
> > > > a few changes. Replace the bootcode.bin and start.elf
> > > > files with the
> > > > ones from Raspbian, and add the u-boot.bin file from the 'i'
> > > > partition
> > > > of your miniroot60.fs SD card.
> > > > 
> > > > With those changes made, your Pi
> > > > should be able to boot OpenBSD
> > > > directly from a USB drive with no SD card
> > > > needed. Note that it seems
> > > > to take around 10 seconds for the Pi to reach the
> > > > OpenBSD bootloader
> > > > and fire up the kernel.
> > > > 
> > > > Hope this information is helpful
> > > > to someone...
> > > > 
> > > > -- 
> > > >  Joe Gidi
> > > >  j...@entropicblur.com
> > > > 
> > > >  "You cannot buy skill."
> > > > -- Ross Seyfried
> > > 
> > > Thanks, I'll try this out soon,
> > > 
> > > Some notes of things I saw when trying to boot from a sd-card using
> > > various a USB devices to install to:
> > > 
> > > Some USB devices do seem to hang the rpi3 sometimes while u-boot is
> > > scanning the usb bus, in my case an old USB flash stick.
> > > 
> > > With a disk enclosure (2.5" usb bus powered with spinning disk), the
> > > hangs did not occur. But I saw another problem that looked to be
> > > caused by the reset of the usb bus while the kernel was booting (from
> > > sd-card). The disk enclosure did not get recognized in time when the
> > > kernel reached the ask root device questions, making it imposible to
> > > select the usb drive as boot device.
> > > 
> > > I manged to boot the machine using an externally powered enclosure
> > > with a 3.5 disk. I'll be buying a SSD today to see how that goes.
> > > 
> > >   -Otto
> > > 
> > 
> > You don't need to bother with linux, the files are in the
> > raspberrypi-firmware package with version 1.20170215.  And the next
> > snapshot will include the newer firmware.
> > 
> > Though that will take a few days, due to -current moving to 6.1 a
> > xenocara build will have to be done as well and that tends to trigger
> > problems with stuck and segfaulting processes.
> 
> Will the fidding with
> 
> > > program_usb_boot_mode=1
> > > program_usb_boot_timeout=1
> 
> still be neccesary?
> 
>   -Otto
> 

Unless the parts of the miniroot/ramdisk which create config.txt are
changed to do so yes.

I'm not clear on the downsides of irreversibly setting these otp bits.
Not being able to use older firmware versions?

>From what I've read the boot rom will still try to load from the
sd slot first before trying to 

Re: Raspberry Pi 3 booting from USB

[Otto Moerbeek]

On Sun, Mar 05, 2017 at 07:00:46PM +1100, Jonathan Gray wrote:

> On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
> > On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
> > 
> > > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB device
> > > might be
> > > possible, I decided to find out how deep the rabbit hole is.
> > > As it turns out,
> > > it's currently a bit convoluted, but it can be made
> > > to work with OpenBSD.
> > > First off, USB boot support is just now getting fully ironed out.
> > > You'll need
> > > to update the firmware on your Pi to make it work. I
> > > installed the latest
> > > (2017-03-02) Raspbian image to an SD card and
> > > booted the Pi from that. While
> > > booted in Raspbian, update the
> > > firmware:
> > > 
> > > sudo apt-get update
> > > sudo apt-get
> > > install rpi-update
> > > sudo rpi-update
> > > 
> > > It's then necessary to actually enable USB
> > > boot support. Add the
> > > following 2 lines to /boot/config.txt to enable USB boot
> > > mode and set
> > > a 5-second timeout to allow time for USB device initialization:
> > > program_usb_boot_mode=1
> > > program_usb_boot_timeout=1
> > > 
> > > NOTE: Apparently these
> > > variables are set in the Pi's OTP memory, which
> > > means once they're set, they
> > > can't ever be unset.
> > > 
> > > Reboot for the changes to take effect. At this point the
> > > Pi should be
> > > ready to support USB booting.
> > > 
> > > While you still have a working
> > > Raspbian install, grab a copy of the
> > > /boot/bootcode.bin and /boot/start.elf
> > > files for later use; apparently
> > > we need these special versions of those two
> > > files for USB boot
> > > support. At this point we're done with Raspbian and can
> > > shut it down
> > > to install OpenBSD.
> > > 
> > > Next, write the OpenBSD miniroot60.fs to an
> > > SD card, plug in your USB
> > > drive, and boot the Pi. You should be greeted with
> > > the usual OpenBSD
> > > installer, and you should be able to install to your USB
> > > drive
> > > (probably sd0). Once the installer is done, run 'halt', unplug the Pi,
> > > and remove the SD card and USB drive.
> > > 
> > > To make your USB drive bootable, you'll
> > > need to plug it into another
> > > system and mount its 'i' partition (the FAT32
> > > boot partition) to make
> > > a few changes. Replace the bootcode.bin and start.elf
> > > files with the
> > > ones from Raspbian, and add the u-boot.bin file from the 'i'
> > > partition
> > > of your miniroot60.fs SD card.
> > > 
> > > With those changes made, your Pi
> > > should be able to boot OpenBSD
> > > directly from a USB drive with no SD card
> > > needed. Note that it seems
> > > to take around 10 seconds for the Pi to reach the
> > > OpenBSD bootloader
> > > and fire up the kernel.
> > > 
> > > Hope this information is helpful
> > > to someone...
> > > 
> > > -- 
> > >  Joe Gidi
> > >  j...@entropicblur.com
> > > 
> > >  "You cannot buy skill."
> > > -- Ross Seyfried
> > 
> > Thanks, I'll try this out soon,
> > 
> > Some notes of things I saw when trying to boot from a sd-card using
> > various a USB devices to install to:
> > 
> > Some USB devices do seem to hang the rpi3 sometimes while u-boot is
> > scanning the usb bus, in my case an old USB flash stick.
> > 
> > With a disk enclosure (2.5" usb bus powered with spinning disk), the
> > hangs did not occur. But I saw another problem that looked to be
> > caused by the reset of the usb bus while the kernel was booting (from
> > sd-card). The disk enclosure did not get recognized in time when the
> > kernel reached the ask root device questions, making it imposible to
> > select the usb drive as boot device.
> > 
> > I manged to boot the machine using an externally powered enclosure
> > with a 3.5 disk. I'll be buying a SSD today to see how that goes.
> > 
> > -Otto
> > 
> 
> You don't need to bother with linux, the files are in the
> raspberrypi-firmware package with version 1.20170215.  And the next
> snapshot will include the newer firmware.
> 
> Though that will take a few days, due to -current moving to 6.1 a
> xenocara build will have to be done as well and that tends to trigger
> problems with stuck and segfaulting processes.

Will the fidding with

> > program_usb_boot_mode=1
> > program_usb_boot_timeout=1

still be neccesary?

-Otto

Re: serial port expansion card

[Tinker]

Hi Stuart,

On 2017-03-04 08:12, Stuart Henderson wrote:

On 2017/03/04 00:30, Tinker wrote:

I'd like to know how the 15-25Mbps PCIe UART:s work, e.g.:

Exar XR17V354 (4x25mbps):

..

Moschip MCS9904 (4x16mbps):

..

OXPCIe954:

..

I don't know about the Exar/Moschip,


Got to test.


the OXPCIe954 doesn't work on
OpenBSD, I had it part-working but never managed to get the baud rate
right, the clock runs at high speed so needs a larger divisor than 
other

puc(4)'s but things break somewhere.


Hm. About how badly did it break in your experience?


Also you can't determine the number
of ports from the pci id, you are supposed to read from the chip to
figure it out, so it doesn't fit the usual pucdata.c framework.


So the kernel needs to have a per-PCI card or chip table of number of 
ports, aha.



What about divisors and stuff for the 15-25Mbps modes, should that work 
out of the box =)



Btw, PCI serial devices should be superior to USB cards, shouldn't they 
- USB v1 and v2 have extremely high latency, for instance. For a serial 
terminal it's OK but even for an Internet connection it must suck.

Re: Raspberry Pi 3 booting from USB

[Jonathan Gray]

On Sun, Mar 05, 2017 at 08:37:30AM +0100, Otto Moerbeek wrote:
> On Sat, Mar 04, 2017 at 06:40:57PM -0500, Joe Gidi wrote:
> 
> > After jsg@ mentioned that booting a Raspberry Pi 3 from a USB device
> > might be
> > possible, I decided to find out how deep the rabbit hole is.
> > As it turns out,
> > it's currently a bit convoluted, but it can be made
> > to work with OpenBSD.
> > First off, USB boot support is just now getting fully ironed out.
> > You'll need
> > to update the firmware on your Pi to make it work. I
> > installed the latest
> > (2017-03-02) Raspbian image to an SD card and
> > booted the Pi from that. While
> > booted in Raspbian, update the
> > firmware:
> > 
> > sudo apt-get update
> > sudo apt-get
> > install rpi-update
> > sudo rpi-update
> > 
> > It's then necessary to actually enable USB
> > boot support. Add the
> > following 2 lines to /boot/config.txt to enable USB boot
> > mode and set
> > a 5-second timeout to allow time for USB device initialization:
> > program_usb_boot_mode=1
> > program_usb_boot_timeout=1
> > 
> > NOTE: Apparently these
> > variables are set in the Pi's OTP memory, which
> > means once they're set, they
> > can't ever be unset.
> > 
> > Reboot for the changes to take effect. At this point the
> > Pi should be
> > ready to support USB booting.
> > 
> > While you still have a working
> > Raspbian install, grab a copy of the
> > /boot/bootcode.bin and /boot/start.elf
> > files for later use; apparently
> > we need these special versions of those two
> > files for USB boot
> > support. At this point we're done with Raspbian and can
> > shut it down
> > to install OpenBSD.
> > 
> > Next, write the OpenBSD miniroot60.fs to an
> > SD card, plug in your USB
> > drive, and boot the Pi. You should be greeted with
> > the usual OpenBSD
> > installer, and you should be able to install to your USB
> > drive
> > (probably sd0). Once the installer is done, run 'halt', unplug the Pi,
> > and remove the SD card and USB drive.
> > 
> > To make your USB drive bootable, you'll
> > need to plug it into another
> > system and mount its 'i' partition (the FAT32
> > boot partition) to make
> > a few changes. Replace the bootcode.bin and start.elf
> > files with the
> > ones from Raspbian, and add the u-boot.bin file from the 'i'
> > partition
> > of your miniroot60.fs SD card.
> > 
> > With those changes made, your Pi
> > should be able to boot OpenBSD
> > directly from a USB drive with no SD card
> > needed. Note that it seems
> > to take around 10 seconds for the Pi to reach the
> > OpenBSD bootloader
> > and fire up the kernel.
> > 
> > Hope this information is helpful
> > to someone...
> > 
> > -- 
> >  Joe Gidi
> >  j...@entropicblur.com
> > 
> >  "You cannot buy skill."
> > -- Ross Seyfried
> 
> Thanks, I'll try this out soon,
> 
> Some notes of things I saw when trying to boot from a sd-card using
> various a USB devices to install to:
> 
> Some USB devices do seem to hang the rpi3 sometimes while u-boot is
> scanning the usb bus, in my case an old USB flash stick.
> 
> With a disk enclosure (2.5" usb bus powered with spinning disk), the
> hangs did not occur. But I saw another problem that looked to be
> caused by the reset of the usb bus while the kernel was booting (from
> sd-card). The disk enclosure did not get recognized in time when the
> kernel reached the ask root device questions, making it imposible to
> select the usb drive as boot device.
> 
> I manged to boot the machine using an externally powered enclosure
> with a 3.5 disk. I'll be buying a SSD today to see how that goes.
> 
>   -Otto
> 

You don't need to bother with linux, the files are in the
raspberrypi-firmware package with version 1.20170215.  And the next
snapshot will include the newer firmware.

Though that will take a few days, due to -current moving to 6.1 a
xenocara build will have to be done as well and that tends to trigger
problems with stuck and segfaulting processes.