Re: cannot run rock64
> Date: Fri, 4 May 2018 13:27:13 -0700 (MST) > From: arun > > Does anyone have link to where I can get OpenBSD 6.3 miniroot.fs for pine64 > Rock64? Is there a complete step by step instructions on how to put one > together? Thanks. If you have U-Boot in SPI flash, you can use the standard miniroot.fs. The easiest way to do that is to use the images built by "ayufan": https://github.com/ayufan-rock64/linux-build/releases/download/0.6.34/u-boot-flash-spi-rock64.img.xz Simply write that to an uSD card and boot the machine with the uSD card inserted and follow the instructions. After you've sucessfully flashed the firmware you can simply write minitoor63.fs to the uSD card and boot. Note that the firmware runs the serial console at an unusual speed of 150 bps. Not all USB-to-serial converters support that speed. Also note that after the kernel boots it will switch the console to 115200 bps. So you'll have to reconnect at that speed to be able to install. I'm working on getting that fixed. The Gigabit Ethernet interface doesn't work yet. And I'm not sure the USB ports work with the device tree that's included with the firmware. They don't work with the current mainline Linux device tree.
USB support on pine64 boards and nanopi
Hi All, I have one of each of these devices: pine64 pine64-lts nanopi They're all running openbsd snapshots from today, with very minimal package installations. When inserting a usb drive into the boards, I don't see anything appear in the dmesg for each board. I see just the hub when running usbdevs. $ usbdevs addr 1: EHCI root hub, Generic That shows supported on this page: https://www.openbsd.org/arm64.html https://man.openbsd.org/arm64/ehci.4 Does anyone have usb working on any of these devices? If so, did it take special configuration to get it work? Thanks!
Re: USB support on pine64 boards and nanopi
On Sat, May 05, 2018 at 11:45:39AM -0700, jungle boogie wrote: > Hi All, > > I have one of each of these devices: > pine64 > pine64-lts > nanopi > > They're all running openbsd snapshots from today, with very minimal package > installations. When inserting a usb drive into the boards, I don't see > anything appear in the dmesg for each board. > > I see just the hub when running usbdevs. > $ usbdevs > addr 1: EHCI root hub, Generic > > That shows supported on this page: > https://www.openbsd.org/arm64.html > https://man.openbsd.org/arm64/ehci.4 > > Does anyone have usb working on any of these devices? If so, did it take > special configuration to get it work? > > Thanks! > Hi, did you try both ports on pine64? mainbus0 at root: Pine64+ ... umass0 at uhub1 port 1 configuration 1 interface 0 "Kingston DataTraveler 2.0" rev 2.00/1.00 addr 2 umass0: using SCSI over Bulk-Only scsibus1 at umass0: 2 targets, initiator 0 sd1 at scsibus1 targ 1 lun 0: SCSI2 0/direct removable serial.09306545EF90EA262D48 sd1: 14891MB, 512 bytes/sector, 30497664 sectors ... boot device: sd0 root on sd1a (7280d48fc18aa92a.a) swap on sd1b dump on sd1b ... working fine here on pine64plus, iirc. the upper port is connected to "usb otg"-controller, which doesn't have driver in the tree. -Artturi
Re: USB support on pine64 boards and nanopi
Thus said Artturi Alm on Sun, 6 May 2018 01:36:13 +0300 On Sat, May 05, 2018 at 11:45:39AM -0700, jungle boogie wrote: Hi All, I have one of each of these devices: pine64 pine64-lts nanopi They're all running openbsd snapshots from today, with very minimal package installations. When inserting a usb drive into the boards, I don't see anything appear in the dmesg for each board. I see just the hub when running usbdevs. $ usbdevs addr 1: EHCI root hub, Generic That shows supported on this page: https://www.openbsd.org/arm64.html https://man.openbsd.org/arm64/ehci.4 Does anyone have usb working on any of these devices? If so, did it take special configuration to get it work? Thanks! Hi, did you try both ports on pine64? On the pine64-lts, it seems most reliable. The bottom port produces similar output to yours: umass0 at uhub1 port 1 configuration 1 interface 0 "Generic Mass Storage" rev 2.00/1.05 addr 2 umass0: using SCSI over Bulk-Only scsibus3 at umass0: 2 targets, initiator 0 sd1 at scsibus3 targ 1 lun 0: SCSI2 0/direct removable sd1: 3840MB, 512 bytes/sector, 7864320 sectors sd1 detached On the other two devices, the red right briefly lights but then never comes back on. dmesg/usbdevs doesn't show anything. working fine here on pine64plus, iirc. the upper port is connected to "usb otg"-controller, which doesn't have driver in the tree. When I plug-in the same usb drive to all three top USB ports, the LED light on my usb drive stays lit, so I think you're right - it has some other purpose.
Re: USB support on pine64 boards and nanopi
Thus said Artturi Alm on Sun, 6 May 2018 01:36:13 +0300 On Sat, May 05, 2018 at 11:45:39AM -0700, jungle boogie wrote: Hi All, I have one of each of these devices: pine64 pine64-lts nanopi They're all running openbsd snapshots from today, with very minimal package installations. When inserting a usb drive into the boards, I don't see anything appear in the dmesg for each board. I see just the hub when running usbdevs. $ usbdevs addr 1: EHCI root hub, Generic That shows supported on this page: https://www.openbsd.org/arm64.html https://man.openbsd.org/arm64/ehci.4 Does anyone have usb working on any of these devices? If so, did it take special configuration to get it work? Thanks! Hi, did you try both ports on pine64? Okay, good news. It seems after a reboot or two of the nanopi, the usb device is recognized. Disconnecting/reconnecting the device repeatedly had no ill effect.
Re: USB support on pine64 boards and nanopi - solved
Thus said Jungle Boogie on Sat, 5 May 2018 11:45:39 -0700 Hi All, Does anyone have usb working on any of these devices? If so, did it take special configuration to get it work? Thanks! Okay, I think I've figured out the problem. Prior to using a usb drive, I was using a usb-to-serial converter cable, with chipset pl2303 to test the usb port. With this cable, nothing appears in the dmesg/usbdevs. I then attempted to connect a usb thumb drive to the devices and quickly saw the red light come on/go off. After a reboot, and before connecting the usb-to-serial cable, the usb drive works fine. If I connect the serial cable then the usb drive, the usb drive won't work. I don't think the cable is at fault, it works with an openBSD laptop fine. So knowing this, does anyone have a usb-to-serial cable they can try with their devices?
Re: gtk libool slow on arm
I have tested the diff (below) to the com driver on my orangepi. It works.
Can this patch be committed?
>From dmesg:
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
-Original Message-
From: owner-...@openbsd.org On Behalf Of Artturi Alm
Sent: May 2, 2018 2:26 PM
To: s_g...@telus.net
Cc: arm@openbsd.org
Subject: Re: gtk libool slow on arm
On Wed, May 02, 2018 at 10:35:27AM -0700, s_g...@telus.net wrote:
> I realize the orangepi is not the swiftest of machines, but the ld
> issue is more than just SOC performance. The ld process should finish
> within a few seconds to a minute. It is taking 20 minutes.
>
> I am trying to build php as the current bulk build failed on so many
> packages. I think it is the first bulk build since clang. The other
> compiles and processes execute in reasonable time, but when it comes
> to ld something happens.
>
> As I was looking around trying to find what some clues I ran man from
> the serial console and it hung. Man runs fine from an ssh connection
> over the lan. Man on the console was hung in bqwait. What is that?
>
> PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
> 87860 root 630 45M 45M run -18:26 64.60% ld
> 30014 sysadmin -60 832K 1556K sleep bqwait0:10 15.23% man
>
> Later when I suspect ld finished more started to run and got stuck
> also, probably when ld started up again.
>
> PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
> 18030 root 590 46M 47M run -23:02 54.54% ld
> 68435 sysadmin 580 257M 182M run - 0:57 42.72% more
> 30014 sysadmin 100 832K0K idle wait 4:14 0.00% man
>
> Both man and more seem to be using cpu cycles even though they are stuck.
> Could ld be trying to do something with the console?
>
Hi,
You could also add "stty status ^T" into ~/.profile, to see what's going on
when you press it.
tbh., i've never compiled anything gtk on armv7, so i think it's something i
can't help you with.
for less pressure on 'tty level', you could take advantage of the fifo your hw
has, with the diff below. you can see the effect with systat(1) in the
Interrupts column for com0.
-Artturi
diff --git sys/arch/armv7/dev/com_fdt.c sys/arch/armv7/dev/com_fdt.c index
053064e77c1..8f0f159413f 100644
--- sys/arch/armv7/dev/com_fdt.c
+++ sys/arch/armv7/dev/com_fdt.c
@@ -130,8 +130,11 @@ com_fdt_attach(struct device *parent, struct device *self,
void *aux)
sc->sc_reg_width = OF_getpropint(faa->fa_node, "reg-io-width", 4);
sc->sc_reg_shift = OF_getpropint(faa->fa_node, "reg-shift", 2);
- if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart"))
+ if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart")) {
+ sc->sc.sc_uarttype = COM_UART_16550A;
+ sc->sc.sc_fifolen = 64;
intr = com_fdt_intr_designware;
+ }
if (OF_is_compatible(faa->fa_node, "ti,omap3-uart") ||
OF_is_compatible(faa->fa_node, "ti,omap4-uart"))
>
> -Original Message-
> From: owner-po...@openbsd.org On Behalf Of
> Mark Kettenis
> Sent: May 2, 2018 3:10 AM
> To: s_g...@telus.net
> Cc: po...@openbsd.org; arm@openbsd.org
> Subject: Re: gtk libool slow on arm
>
> > From:
> > Date: Tue, 1 May 2018 16:30:28 -0700
> >
> > Why is the gtk libtool so slow on arm? A typical command such as:
>
> It's not libtool, but ld, the link editor that is taking its time.
>
> > libtool: link: cc -o .libs/testentrycompletion -pthread -O2 -pipe -g
> > -Wall -Wl,-rpath-link -Wl,/usr/X11R6/lib -Wl,-rpath-link
> > -Wl,/usr/X11R6/lib testentrycompletion.o -L.libs -lgtk-3 -lgdk-3
> > -lpangocairo-1.0 -lpango-1.0
> > -lgobject-2.0 -lglib-2.0 -liconv -lpcre -lintl -lffi -lc++abi
> > -lgthread-2.0 -lfribidi -lm -lcairo -lpthread -lpixman-1
> > -lfontconfig -lfreetype -lz -lexpat -lpng -lxcb-shm -lxcb
> > -lxcb-render -lXrender
> > -lX11 -lXext
> > -lpangoft2-1.0 -lharfbuzz -lgraphite2 -lgdk_pixbuf-2.0 -lgmodule-2.0
> > -lgio-2.0 -lcairo-gobject -lXinerama -lXi -lXrandr -lXcursor
> > -lXfixes -lXcomposite -lXdamage -lepoxy -latk-1.0 -latk-bridge-2.0
> > -ldbus-1 -latspi
> > -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib
>
> That is linking in quite a number of libraries, some of which are
> fairly sizeable.
>
> > takes from 15 to 20 minutes on arm. It is all cpu time, not i/o:
>
> The binutils linker is quite crappy. The LLVM linker is better.
>
> > load averages: 2.03, 2.02, 2.00 op1bsdsnap.graf.lan
> > 16:26:21
> >
> > 78 processes: 1 running, 76 idle, 1 on processor up 4 days,
> > 7:42
> >
> > CPU states: 99.6% user, 0.0% nice, 0.4% system, 0.0% interrupt,
> > 0.0% idle
> >
> > Memory: Real: 59M/234M act/tot Free: 259M Cache: 98M Swap: 11M/516M
> >
> >
> >
> > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU
> COMMAND
> >
> >
Re: gtk libool slow on arm
On Sat, May 05, 2018 at 08:18:01PM -0700, s_g...@telus.net wrote:
> I have tested the diff (below) to the com driver on my orangepi. It works.
> Can this patch be committed?
>
Atleast in _theory_, there could be "snps,dw-apb-uart" without fifo,
and the diff doesn't properly detect such. So the answer was/is no.
I don't remember the specifics, and I'm not sure if i ever sent out
the diff doing it properly, but linux has safe(?) procedure for
detecting these fifos.
-Artturi
> From dmesg:
>
> com0 at simplebus0: ns16550a, 64 byte fifo
> com0: console
>
>
> -Original Message-
> From: owner-...@openbsd.org On Behalf Of Artturi Alm
> Sent: May 2, 2018 2:26 PM
> To: s_g...@telus.net
> Cc: arm@openbsd.org
> Subject: Re: gtk libool slow on arm
>
> On Wed, May 02, 2018 at 10:35:27AM -0700, s_g...@telus.net wrote:
> > I realize the orangepi is not the swiftest of machines, but the ld
> > issue is more than just SOC performance. The ld process should finish
> > within a few seconds to a minute. It is taking 20 minutes.
> >
> > I am trying to build php as the current bulk build failed on so many
> > packages. I think it is the first bulk build since clang. The other
> > compiles and processes execute in reasonable time, but when it comes
> > to ld something happens.
> >
> > As I was looking around trying to find what some clues I ran man from
> > the serial console and it hung. Man runs fine from an ssh connection
> > over the lan. Man on the console was hung in bqwait. What is that?
> >
> > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
> > 87860 root 630 45M 45M run -18:26 64.60% ld
> > 30014 sysadmin -60 832K 1556K sleep bqwait0:10 15.23% man
> >
> > Later when I suspect ld finished more started to run and got stuck
> > also, probably when ld started up again.
> >
> > PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
> > 18030 root 590 46M 47M run -23:02 54.54% ld
> > 68435 sysadmin 580 257M 182M run - 0:57 42.72% more
> > 30014 sysadmin 100 832K0K idle wait 4:14 0.00% man
> >
> > Both man and more seem to be using cpu cycles even though they are stuck.
> > Could ld be trying to do something with the console?
> >
>
> Hi,
>
>
> You could also add "stty status ^T" into ~/.profile, to see what's going on
> when you press it.
> tbh., i've never compiled anything gtk on armv7, so i think it's something i
> can't help you with.
>
> for less pressure on 'tty level', you could take advantage of the fifo your
> hw has, with the diff below. you can see the effect with systat(1) in the
> Interrupts column for com0.
>
> -Artturi
>
>
> diff --git sys/arch/armv7/dev/com_fdt.c sys/arch/armv7/dev/com_fdt.c index
> 053064e77c1..8f0f159413f 100644
> --- sys/arch/armv7/dev/com_fdt.c
> +++ sys/arch/armv7/dev/com_fdt.c
> @@ -130,8 +130,11 @@ com_fdt_attach(struct device *parent, struct device
> *self, void *aux)
> sc->sc_reg_width = OF_getpropint(faa->fa_node, "reg-io-width", 4);
> sc->sc_reg_shift = OF_getpropint(faa->fa_node, "reg-shift", 2);
>
> - if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart"))
> + if (OF_is_compatible(faa->fa_node, "snps,dw-apb-uart")) {
> + sc->sc.sc_uarttype = COM_UART_16550A;
> + sc->sc.sc_fifolen = 64;
> intr = com_fdt_intr_designware;
> + }
>
> if (OF_is_compatible(faa->fa_node, "ti,omap3-uart") ||
> OF_is_compatible(faa->fa_node, "ti,omap4-uart"))
>
>
> >
> > -Original Message-
> > From: owner-po...@openbsd.org On Behalf Of
> > Mark Kettenis
> > Sent: May 2, 2018 3:10 AM
> > To: s_g...@telus.net
> > Cc: po...@openbsd.org; arm@openbsd.org
> > Subject: Re: gtk libool slow on arm
> >
> > > From:
> > > Date: Tue, 1 May 2018 16:30:28 -0700
> > >
> > > Why is the gtk libtool so slow on arm? A typical command such as:
> >
> > It's not libtool, but ld, the link editor that is taking its time.
> >
> > > libtool: link: cc -o .libs/testentrycompletion -pthread -O2 -pipe -g
> > > -Wall -Wl,-rpath-link -Wl,/usr/X11R6/lib -Wl,-rpath-link
> > > -Wl,/usr/X11R6/lib testentrycompletion.o -L.libs -lgtk-3 -lgdk-3
> > > -lpangocairo-1.0 -lpango-1.0
> > > -lgobject-2.0 -lglib-2.0 -liconv -lpcre -lintl -lffi -lc++abi
> > > -lgthread-2.0 -lfribidi -lm -lcairo -lpthread -lpixman-1
> > > -lfontconfig -lfreetype -lz -lexpat -lpng -lxcb-shm -lxcb
> > > -lxcb-render -lXrender
> > > -lX11 -lXext
> > > -lpangoft2-1.0 -lharfbuzz -lgraphite2 -lgdk_pixbuf-2.0 -lgmodule-2.0
> > > -lgio-2.0 -lcairo-gobject -lXinerama -lXi -lXrandr -lXcursor
> > > -lXfixes -lXcomposite -lXdamage -lepoxy -latk-1.0 -latk-bridge-2.0
> > > -ldbus-1 -latspi
> > > -Wl,-rpath-link,/usr/local/lib,-rpath-link,/usr/X11R6/lib
> >
> > That is linking in quite a number of libraries, some of which are
> > fairly sizeable.
> >
> > > takes from 1
