PATCH: Octeon RNG support
Hey tech@
Here's a patch that adds octeon's onboard rng chip as a source of
entropy. Currently I fire this off every second, which neither seemed to
increase the load on my ERL or produce duplicate outputs.
This patch also maps out the rnm register which controls the status of
the rng and entropy.
Ok?
Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/octeon/conf/GENERIC,v
retrieving revision 1.10
diff -u -b -w -p -r1.10 GENERIC
--- conf/GENERIC19 Sep 2013 00:15:59 - 1.10
+++ conf/GENERIC22 Oct 2013 02:55:23 -
@@ -51,3 +51,6 @@ pciide* at pci? flags 0x
# IDE hard drives
wd*at pciide? flags 0x
+
+# RNG
+octrng0at iobus0
Index: conf/files.octeon
===
RCS file: /cvs/src/sys/arch/octeon/conf/files.octeon,v
retrieving revision 1.14
diff -u -b -w -p -r1.14 files.octeon
--- conf/files.octeon 15 Aug 2013 06:54:35 - 1.14
+++ conf/files.octeon 22 Oct 2013 02:55:23 -
@@ -90,3 +90,8 @@ file arch/octeon/dev/octeon_pcibus.c p
file arch/octeon/dev/octeon_bus_space.c
file arch/octeon/octeon/pciide_machdep.c pciide
+
+# Onboard rng
+device octrng
+attach octrng at iobus
+file arch/octeon/dev/octrng.coctrng
Index: dev/cn30xxrnmreg.h
===
RCS file: dev/cn30xxrnmreg.h
diff -N dev/cn30xxrnmreg.h
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/cn30xxrnmreg.h 22 Oct 2013 02:55:23 -
@@ -0,0 +1,50 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2013 William Orr
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef _CN30XXPKOREG_H_
+#define _CN30XXPKOREG_H_
+
+#define RNM_REG_BASE 0x000118004000ULL
+#define RNM_REG_SIZE 0xFULL
+
+#define RNM_REG_CTL0x000118004000ULL
+#define RNM_REG_BIST 0x000118004008ULL
+
+#define RNM_CTL_ENT_EN 0x0001ULL
+#define RNM_CTL_RNG_EN 0x0002ULL
+#define RNM_CTL_RNM_RST0x0004ULL
+#define RNM_CTL_RNG_RST0x0008ULL
+#define RNM_CTL_ENT_SEL0x00F0ULL
+#define RNM_CTL_EER_VAL0x0100ULL
+#define RNM_CTL_EER_LCK0x0200ULL
+#define RNM_CTL_DIS_MAK0x0400ULL
+
+#define RNM_BIST_MEM 0x0001ULL
+#define RNM_BIST_RRC 0x0002ULL
+
+#endif
+
Index: dev/octeon_iobus.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/octeon_iobus.c,v
retrieving revision 1.4
diff -u -b -w -p -r1.4 octeon_iobus.c
--- dev/octeon_iobus.c 2 Jun 2013 20:29:36 - 1.4
+++ dev/octeon_iobus.c 22 Oct 2013 02:55:23 -
@@ -154,12 +154,14 @@ struct machine_bus_dma_tag iobus_bus_dma
const struct iobus_unit iobus_units[] = {
{ OCTEON_CF_BASE, 0 }, /* octcf */
{ 0, 0 }, /* pcibus */
- { GMX0_BASE_PORT0, CIU_INT_GMX_DRP0 } /* cn30xxgmx */
+ { GMX0_BASE_PORT0, CIU_INT_GMX_DRP0 }, /* cn30xxgmx */
+ { OCTEON_RNG_BASE, 0 } /* octrng */
};
struct iobus_attach_args iobus_children[] = {
IOBUSDEV("octcf", 0, &iobus_units[0]),
IOBUSDEV("pcibus", 0, &iobus_units[1]),
- IOBUSDEV("cn30xxgmx", 0, &iobus_units[2])
+ IOBUSDEV("cn30xxgmx", 0, &iobus_units[2]),
+ IOBUSDEV("octrng", 0, &iobus_units[3])
};
#undef IOBUSDEV
Index: dev/octrng.c
===
RCS file: dev/octrn
Re: pkill -l
On Tue, Oct 22, 2013 at 02:34, Alexander Hall wrote: > On 10/22/13 02:09, Ted Unangst wrote: >> I don't think the -l flag to pkill is useful. It's behavior is oddly >> different from pgrep -l (and more different with pgrep/pkill -f). Or >> rather, it's not just long output, but also turns on verbose mode when >> otherwise nothing would be printed. The only use case I can think of >> is "did I kill the right process?" which is literally the kind of shoot >> first, ask questions later behavior we should maybe not encourage. > > I tend to pgrep -fl for a process to kill, and then I always have to > think about which switch to remove. Being as tightly coupled as they > are, I think allowing -l for both is helpful. > > I agree the output is inconstistant, but I'd rather have that fixed (if > possible) than it being removed. > > > $ sleep 50 & > [1] 2673 > $ pgrep -fl sleep > 25664 sleep 5 > 2673 sleep 50 > $ pgrep -fl 'sleep 50' > 2673 sleep 50 > $ pkill -l 'sleep 50' > $ pgrep -fl 'sleep 50' > 2673 sleep 50 > $ #fuck > $ pkill -f 'sleep 50' > [1] + Terminated sleep 50 This is exactly the problem I experience. I didn't want to rely solely on "I can't remember which flag to use", but yes, that is the root of the problem. Removing support for -l causes it to be a hard error, that one will notice, as opposed to a silent failure.
Re: pkill -l
On 10/22/13 02:09, Ted Unangst wrote:
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use case I can think of
is "did I kill the right process?" which is literally the kind of shoot
first, ask questions later behavior we should maybe not encourage.
I tend to pgrep -fl for a process to kill, and then I always have to
think about which switch to remove. Being as tightly coupled as they
are, I think allowing -l for both is helpful.
I agree the output is inconstistant, but I'd rather have that fixed (if
possible) than it being removed.
$ sleep 50 &
[1] 2673
$ pgrep -fl sleep
25664 sleep 5
2673 sleep 50
$ pgrep -fl 'sleep 50'
2673 sleep 50
$ pkill -l 'sleep 50'
$ pgrep -fl 'sleep 50'
2673 sleep 50
$ #fuck
$ pkill -f 'sleep 50'
[1] + Terminated sleep 50
Related: linux pkill doesn't support -l either.
Indeed, which annoys me almost every day at work. ;-)
/Alexander
Index: pkill.1
===
RCS file: /cvs/src/usr.bin/pkill/pkill.1,v
retrieving revision 1.20
diff -u -p -r1.20 pkill.1
--- pkill.1 21 Aug 2012 09:45:50 - 1.20
+++ pkill.1 24 Sep 2013 02:17:59 -
@@ -49,7 +49,7 @@
.Op Ar pattern ...
.Nm pkill
.Op Fl Ar signal
-.Op Fl flnoqvx
+.Op Fl fnoqvx
.Op Fl G Ar gid
.Op Fl g Ar pgrp
.Op Fl P Ar ppid
@@ -101,9 +101,10 @@ Print the process name in addition to th
process.
If used in conjunction with
.Fl f ,
-print the process ID and the full argument list for each matching process
-.Pf ( Nm pgrep
-only).
+print the process ID and the full argument list for each matching process.
+This option can only be used with the
+.Nm pgrep
+command.
.It Fl n
Match only the most recently created (newest) process, if any.
Cannot be used in conjunction with
Index: pkill.c
===
RCS file: /cvs/src/usr.bin/pkill/pkill.c,v
retrieving revision 1.31
diff -u -p -r1.31 pkill.c
--- pkill.c 12 Dec 2012 22:25:21 - 1.31
+++ pkill.c 24 Sep 2013 02:16:37 -
@@ -184,6 +184,8 @@ main(int argc, char **argv)
criteria = 1;
break;
case 'l':
+ if (!pgrep)
+ usage();
longfmt = 1;
break;
case 'n':
@@ -446,7 +448,7 @@ usage(void)
if (pgrep)
ustr = "[-flnoqvx] [-d delim]";
else
- ustr = "[-signal] [-flnoqvx]";
+ ustr = "[-signal] [-fnoqvx]";
fprintf(stderr, "usage: %s %s [-G gid] [-g pgrp] [-P ppid] [-s sid]"
"\n\t[-T rtable] [-t tty] [-U uid] [-u euid] [pattern ...]\n",
@@ -458,9 +460,6 @@ usage(void)
int
killact(struct kinfo_proc *kp, int dummy)
{
- if (longfmt && !quiet)
- printf("%d %s\n", (int)kp->p_pid, kp->p_comm);
-
if (kill(kp->p_pid, signum) == -1) {
if (errno == ESRCH)
return (STATUS_NOMATCH);
pkill -l
I don't think the -l flag to pkill is useful. It's behavior is oddly
different from pgrep -l (and more different with pgrep/pkill -f). Or
rather, it's not just long output, but also turns on verbose mode when
otherwise nothing would be printed. The only use case I can think of
is "did I kill the right process?" which is literally the kind of shoot
first, ask questions later behavior we should maybe not encourage.
Related: linux pkill doesn't support -l either.
Index: pkill.1
===
RCS file: /cvs/src/usr.bin/pkill/pkill.1,v
retrieving revision 1.20
diff -u -p -r1.20 pkill.1
--- pkill.1 21 Aug 2012 09:45:50 - 1.20
+++ pkill.1 24 Sep 2013 02:17:59 -
@@ -49,7 +49,7 @@
.Op Ar pattern ...
.Nm pkill
.Op Fl Ar signal
-.Op Fl flnoqvx
+.Op Fl fnoqvx
.Op Fl G Ar gid
.Op Fl g Ar pgrp
.Op Fl P Ar ppid
@@ -101,9 +101,10 @@ Print the process name in addition to th
process.
If used in conjunction with
.Fl f ,
-print the process ID and the full argument list for each matching process
-.Pf ( Nm pgrep
-only).
+print the process ID and the full argument list for each matching process.
+This option can only be used with the
+.Nm pgrep
+command.
.It Fl n
Match only the most recently created (newest) process, if any.
Cannot be used in conjunction with
Index: pkill.c
===
RCS file: /cvs/src/usr.bin/pkill/pkill.c,v
retrieving revision 1.31
diff -u -p -r1.31 pkill.c
--- pkill.c 12 Dec 2012 22:25:21 - 1.31
+++ pkill.c 24 Sep 2013 02:16:37 -
@@ -184,6 +184,8 @@ main(int argc, char **argv)
criteria = 1;
break;
case 'l':
+ if (!pgrep)
+ usage();
longfmt = 1;
break;
case 'n':
@@ -446,7 +448,7 @@ usage(void)
if (pgrep)
ustr = "[-flnoqvx] [-d delim]";
else
- ustr = "[-signal] [-flnoqvx]";
+ ustr = "[-signal] [-fnoqvx]";
fprintf(stderr, "usage: %s %s [-G gid] [-g pgrp] [-P ppid] [-s sid]"
"\n\t[-T rtable] [-t tty] [-U uid] [-u euid] [pattern ...]\n",
@@ -458,9 +460,6 @@ usage(void)
int
killact(struct kinfo_proc *kp, int dummy)
{
- if (longfmt && !quiet)
- printf("%d %s\n", (int)kp->p_pid, kp->p_comm);
-
if (kill(kp->p_pid, signum) == -1) {
if (errno == ESRCH)
return (STATUS_NOMATCH);
Re: Wrong rights for ELF interpreters
Le 21/10/2013 09:38, Theo de Raadt a écrit : I don't get what's wrong with running execve on it. In all cases, someone can load it through another executable. Using ld.so does not imply "execve'ing it". If I have an interpreter that I chmod as exec-only, I want this interpreter to be world-loadable without thereby letting other users copy it. The same for a library. It is loadable. Because it is readable. I said "exec-only", so no it is not readable and not loadable. My point was that, actually, it should be loadable. But after sleeping a bit, I figured out that there may indeed be some issues with some libraries. To me it looks weird. I'm gonna investigate a bit, and if I have an objection I'll send it here. Until then, sorry for the noise.
Re: Allwinner
On 10/21/13 18:04, Jasper Lievisse Adriaanse wrote: On Fri, Oct 11, 2013 at 11:46:39PM +0300, Artturi Alm wrote: On 10/11/13 20:39, Markus Hennecke wrote: On Sat, 5 Oct 2013, Artturi Alm wrote: Current version attached, extract to /sys/arch/armv7 and read the short notes file, no more out of allwinner/ patches needed thanks to armv7. A20 support still needs a workaround under /sys/arch/arm/cortex/ which i didn't include as i think support is still 'subtly' broken anyway.. And ahci is still not working for me, but there's a couple of new drivers included. Ethernet driver survived make build of userland with /usr/src mounted via nfs, fwiw. Now this is totally usable for me as-is already, so any feedback is welcome, be it finding out possible bugs and/or confirming it's working. Great work! I made a few changes to fix the timer code for the A20 CPU, the diff to your code is attached. With this I am almost booting the kernel on a cubieboard 2: Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.4-current (GENERIC-ALLWINNER) #22: Fri Oct 11 19:17:11 CEST 2013 mar...@antigone.markus-hennecke.de:/usr/src/sys/arch/armv7/compile/GENERIC-ALLWINNER real mem = 1073741824 (1024MB) avail mem = 1040007168 (991MB) mainbus0 at root cortex0 at mainbus0 ampintc0 at cortex0 nirq 160 cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core) cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache allwinner0 at mainbus0: A20 awpio0 at allwinner0 awccmu0 at allwinner0 awtimer0 at allwinner0: tick rate 32KHz hz 100 stat rate 32KHz stathz 128 counter 24000 KHz awdog0 at allwinner0 awrtc0 at allwinner0 awuart0 at allwinner0: console awe0 at allwinner0 awe0: address 00:00:00:00:00:00 rlphy0 at awe0 phy 1: RTL8201L 10/100 PHY, rev. 1 ahci0 at allwinner0 GHC 0x8000 AHCI 1.1 ahci0: capabilities 0x6726ff80, 1 ports, 32 cmds, gen 1 (1.5Gbps) and 2 (3Gbps) ahci0: ports implemented: 0x0001 ahci0.0: port reset ahci0: no device detected on port 0 scsibus0 at ahci0: 32 targets ehci0 at allwinner0 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 ehci1 at allwinner0 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 gpio0 at awpio0: 18 pins gpio1 at awpio0: 24 pins gpio2 at awpio0: 25 pins gpio3 at awpio0: 28 pins gpio4 at awpio0: 12 pins gpio5 at awpio0: 6 pins gpio6 at awpio0: 12 pins gpio7 at awpio0: 28 pins gpio8 at awpio0: 22 pins /dev/ksyms: Symbol table not valid. Here the output stops, I will look into that later. At this point I am unable to figure out how to set the ethaddr in the u-boot version I am using. setenv ethaddr xx:xx:xx:xx:xx:xx doesn't seem to have any effect. Kind regards Markus Hi, Thanks for the patch, it looks correct when compared to the user manual and shows how ugly sources may get when not paid enough attention, will fix the whitespaces there also. Note that Cortex-A7 should support agtimer found in arch/arm/cortex, which would allow cleaning up awtimer.c from the 'added on'-kind of hacks to support A20, priorities have kept me from trying that one out so far. To allow it to boot further you would have to change ICP_ADDR and ICD_ADDR in ampintc, iirc. possibly 0x1000 and 0x2000 respectively, which is not the fix that would ever get commited even if allwinner would be on cvs, as it'll break Cortex-A9, and unfortunately, masking by cpu is not working option either, there is example of where it would fail already (exynos). FDT is the only clean solution i can think of, when there is priority on keeping arch/arm/cortex free of SoC-dependent code. About ethaddr, have you tried pinging another host from u-boot? Does your u-boot support emac? the one i initially downloaded for cubieboard2 did not iirc., if you can boot the bsd.umg over network, and still get 00:00:00:00:00:00, i will power up my cb2 to fix awe, as it's so far untested on A20 afaik. -Artturi I'm going to commit the initial allwinner diff along with Martin's diff tomorrow unless strong objection is raised. This needs to be worked on intree instead of letting it rot on the mailinglist. I got around 2,5k line diff to previous allwinner.tar.gz already. It has the diff by Markus to fix timer on A20, besides major cleanup on awtimer(mainly in _attach()) that definately should go in. It has also ugly hacks to support ethernet&usb on Hackberry, possibly doable in not so ugly way before FDT with boardids. And dma controller usable as is likely to just ethernet driver, which still has align issues with it so it's disabled there, and fixed the ethernet to use second fifo on tx. possibly i forgot something. I'll run a round of tests on what i have now once i've upgraded to -current and mail it if i find no regr
Remove octeon backwards compat calls
Hi tech --
Here's a diff to replace some backwards compat calls with their
new calls. The rest were long replaced; I'm assuming these went
unnoticed because they're both under an
#ifdef OCTEON_ETH_DEBUG
This was pointed out by William Orr in a
private email.
OK?
~Brian
Index: cn30xxgmx.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/cn30xxgmx.c,v
retrieving revision 1.7
diff -u -p -u -p -r1.7 cn30xxgmx.c
--- cn30xxgmx.c 19 Sep 2013 00:15:59 - 1.7
+++ cn30xxgmx.c 21 Oct 2013 16:32:04 -
@@ -1431,7 +1431,7 @@ cn30xxgmx_intr_rml_gmx1(void)
int
cn30xxgmx_intr_drop(void *arg)
{
- octeon_write_csr(CIU_INT0_SUM0, CIU_INTX_SUM0_GMX_DRP);
+ octeon_xkphys_write_8(CIU_INT0_SUM0, CIU_INTX_SUM0_GMX_DRP);
cn30xxgmx_intr_drop_evcnt.ev_count++;
return (1);
}
Index: cn30xxipd.c
===
RCS file: /cvs/src/sys/arch/octeon/dev/cn30xxipd.c,v
retrieving revision 1.2
diff -u -p -u -p -r1.2 cn30xxipd.c
--- cn30xxipd.c 5 Dec 2012 23:20:14 - 1.2
+++ cn30xxipd.c 21 Oct 2013 16:32:04 -
@@ -312,7 +312,7 @@ cn30xxipd_int_summary(struct cn30xxipd_s
int
cn30xxipd_intr_drop(void *arg)
{
- octeon_write_csr(CIU_INT0_SUM0, CIU_INTX_SUM0_IPD_DRP);
+ octeon_xkphys_write_8(CIU_INT0_SUM0, CIU_INTX_SUM0_IPD_DRP);
cn30xxipd_intr_drop_evcnt.ev_count++;
return (1);
}
Re: Allwinner
On Fri, Oct 11, 2013 at 11:46:39PM +0300, Artturi Alm wrote: > On 10/11/13 20:39, Markus Hennecke wrote: > >On Sat, 5 Oct 2013, Artturi Alm wrote: > > > >>Current version attached, extract to /sys/arch/armv7 and read the short > >>notes file, no more out of allwinner/ patches needed thanks to armv7. > >> > >>A20 support still needs a workaround under /sys/arch/arm/cortex/ which > >>i didn't include as i think support is still 'subtly' broken anyway.. > >>And ahci is still not working for me, but there's a couple of > >>new drivers included. > >>Ethernet driver survived make build of userland with /usr/src mounted > >>via nfs, fwiw. > >> > >>Now this is totally usable for me as-is already, so any feedback is > >>welcome, be it finding out possible bugs and/or confirming it's working. > > > >Great work! I made a few changes to fix the timer code for the A20 CPU, > >the diff to your code is attached. With this I am almost booting the > >kernel on a cubieboard 2: > > > >Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights reserved. > >Copyright (c) 1995-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org > > > >OpenBSD 5.4-current (GENERIC-ALLWINNER) #22: Fri Oct 11 19:17:11 CEST 2013 > > > > mar...@antigone.markus-hennecke.de:/usr/src/sys/arch/armv7/compile/GENERIC-ALLWINNER > >real mem = 1073741824 (1024MB) > >avail mem = 1040007168 (991MB) > >mainbus0 at root > >cortex0 at mainbus0 > >ampintc0 at cortex0 nirq 160 > >cpu0 at mainbus0: ARM Cortex A7 rev 4 (ARMv7 core) > >cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled > >cpu0: 32KB(32b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache > >allwinner0 at mainbus0: A20 > >awpio0 at allwinner0 > >awccmu0 at allwinner0 > >awtimer0 at allwinner0: tick rate 32KHz hz 100 stat rate 32KHz stathz 128 > > counter 24000 KHz > >awdog0 at allwinner0 > >awrtc0 at allwinner0 > >awuart0 at allwinner0: console > >awe0 at allwinner0 > >awe0: address 00:00:00:00:00:00 > >rlphy0 at awe0 phy 1: RTL8201L 10/100 PHY, rev. 1 > >ahci0 at allwinner0 GHC 0x8000 AHCI 1.1 > >ahci0: capabilities > >0x6726ff80, 1 ports, 32 > >cmds, gen 1 (1.5Gbps) and 2 (3Gbps) > >ahci0: ports implemented: 0x0001 > >ahci0.0: port reset > >ahci0: no device detected on port 0 > >scsibus0 at ahci0: 32 targets > >ehci0 at allwinner0 > >usb0 at ehci0: USB revision 2.0 > >uhub0 at usb0 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 > >ehci1 at allwinner0 > >usb1 at ehci1: USB revision 2.0 > >uhub1 at usb1 "Allwinner EHCI root hub" rev 2.00/1.00 addr 1 > >gpio0 at awpio0: 18 pins > >gpio1 at awpio0: 24 pins > >gpio2 at awpio0: 25 pins > >gpio3 at awpio0: 28 pins > >gpio4 at awpio0: 12 pins > >gpio5 at awpio0: 6 pins > >gpio6 at awpio0: 12 pins > >gpio7 at awpio0: 28 pins > >gpio8 at awpio0: 22 pins > >/dev/ksyms: Symbol table not valid. > > > >Here the output stops, I will look into that later. At this point I am > >unable to figure out how to set the ethaddr in the u-boot version I am > >using. setenv ethaddr xx:xx:xx:xx:xx:xx doesn't seem to have any effect. > > > >Kind regards > >Markus > > > > Hi, > > Thanks for the patch, it looks correct when compared to the user manual > and shows how ugly sources may get when not paid enough attention, > will fix the whitespaces there also. Note that Cortex-A7 should > support agtimer found in arch/arm/cortex, which would allow cleaning > up awtimer.c from the 'added on'-kind of hacks to support A20, > priorities have kept me from trying that one out so far. > > To allow it to boot further you would have to change ICP_ADDR and > ICD_ADDR in ampintc, iirc. possibly 0x1000 and 0x2000 respectively, > which is not the fix that would ever get commited even if allwinner > would be on cvs, as it'll break Cortex-A9, and unfortunately, masking > by cpu is not working option either, there is example of where it would > fail already (exynos). > FDT is the only clean solution i can think of, when there is priority on > keeping arch/arm/cortex free of SoC-dependent code. > > About ethaddr, have you tried pinging another host from u-boot? > Does your u-boot support emac? the one i initially downloaded for > cubieboard2 did not iirc., if you can boot the bsd.umg over network, > and still get 00:00:00:00:00:00, i will power up my cb2 to fix awe, > as it's so far untested on A20 afaik. > > > -Artturi I'm going to commit the initial allwinner diff along with Martin's diff tomorrow unless strong objection is raised. This needs to be worked on intree instead of letting it rot on the mailinglist. -- Cheers, Jasper "Stay Hungry. Stay Foolish"
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 09:05:04AM -0500, Vladimir Támara Patiño wrote: > I agree full Unicode support is desirable, but IMHO having 8 bits > collation is better than nothing (for example withouth it spanish > speakers have to > see ñ, á and other special symbols at the end of sorted results in > programs that support collations like PostgreSQL). So we add 8 bit support, and then what? Whoever would want to do it properly would have to throw the 8 bit stuff out and start all over again.
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote: > Indeed, doing collation properly (i.e. with Unicode, not just 8 bit > characters like FreeBSD does) really is a non-trivial effort. > > It requires some expertise in linguistics and a solid understanding > of the unicode standard. You'd need to make use of something like ICU > (icu-project.org) to keep your sanity, or implement a whole lot of > that code base yourself... Unfortunately, that requires support in the 3rd party software itself. Anyway, I updated to current the 8 bit collation support from FreeBSD I had sent in in March and that was reviewed by Stephan in the previous Hackathon: https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/03-cotejacion.patch Also updated the xlocale patch, also based in FreeBSD that I sent in February: https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/04-xlocale-wchar.patch https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/05-xlocale-ctype.patch https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/06-xlocale-str.patch And also updated patch for regress/lib/libc/locale/check_isw sent in March: https://github.com/pasosdeJesus/adJ/blob/OBSD_CURRENT/arboldes/usr/src/01-check_isw.patch I want to compare in detail with the implementation that Martin sent, few differences I see: * I changed the sources in order to avoid runetype.h in /usr/include * Martin implemented some pieces that I have not (e.g strtorx_l), I want to merge in what I have > If we bother with collation I think we should try to do better. I agree full Unicode support is desirable, but IMHO having 8 bits collation is better than nothing (for example withouth it spanish speakers have to see ñ, á and other special symbols at the end of sorted results in programs that support collations like PostgreSQL). > The shim is going to be a lot less work, and doesn't preclude an > implentation inside libc at a later stage. Thanks for showing the right direction. I'll look into it as soon as I have more time; at least I know what is needed and how big is it. Since xlocale is part of POSIX shouldn't we try to include that faster in libc? I think xlocale additions to POSIX were included in the Open Group Technical Standard, 2006, Extended API Set Part 4. That is what I understand of the documentation of xlocale functions like strcoll_l, see bottom of: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strcoll.html However if Martin prefers to make a new library for this, hope the patches I sent can be useful. -- Dios, gracias por tu amor infinito. -- Vladimir Támara Patiño. http://vtamara.pasosdeJesus.org/ http://www.pasosdejesus.org/dominio_publico_colombia.html
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 02:14:32PM +0200, Martin Pelikan wrote: > > Applications don't care where a symbol comes from. > > Build scripts and Makefiles might expect them to be in libc and > > would need to link an additional library, but that's trivial to do. > > For all such ports? Ok then :-) How many ports do you expect will require xlocale? > > I would suggest to implement a small and non-OS-specific stub for > > libcxx that they can use on any OS lacking xlocale support. > > Replace/enhance the existing shim for Solaris as part of this effort. > > Work with the libcxx team to integrate your changes there. > > > > If they tell you that they won't run on a non-xlocale OS that isn't > > Solaris, implement the shim anyway and add it to our ports tree. > > > > The shim is going to be a lot less work, and doesn't preclude an > > implentation inside libc at a later stage. > > Thanks for showing the right direction. I'll look into it as soon as > I have more time; at least I know what is needed and how big is it. If xlocale is needed beyond libcxx, take a look at the misc/libutf8 port in the CVS Attic. Perhaps a port like that could serve as an API shim for xlocale until libc support for xlocale arrives. If you'd still rather do this in libc itself, e.g. because a simple shim won't provide enough functionality to make libcxx work, or because you really need it coupled up with libc locale internals, don't just copy files over from FreeBSD and make us review it all. Figure out what the steps are to get us from here to there and let us review each step. I think starting with just the locale_t data type and related functions (duplocale() etc.) on this page would be a good first step: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/locale.h.html This interface extension is small enough to be added in one diff, I think. I don't care if you base the implementation on FreeBSD or write your own, as long as the diff is concise and adds nicely on top what we've already got. All the clutter from new *_l() convenience functions can come later. This page provides a high-level overview of xlocale interfaces, BTW: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/xlocale.3.html That's quite a lot. I wouldn't want to add all that in one chunk.
Re: partial xlocale(3) port from FreeBSD
> Indeed, doing collation properly (i.e. with Unicode, not just 8 bit > characters like FreeBSD does) really is a non-trivial effort. > > It requires some expertise in linguistics and a solid understanding > of the unicode standard. You'd need to make use of something like ICU > (icu-project.org) to keep your sanity, or implement a whole lot of > that code base yourself... Unfortunately, that requires support in the 3rd party software itself. > Applications don't care where a symbol comes from. > Build scripts and Makefiles might expect them to be in libc and > would need to link an additional library, but that's trivial to do. For all such ports? Ok then :-) > I think you should tackle your goals (C++11, collation) in isolation. > They aren't coupled, really. Yes, but xlocale seemed like a thing they have in common. > If we bother with collation I think we should try to do better. Yes, but that I think is only applying a correct library. As you've said earlier, getting this right is really hard. > I would suggest to implement a small and non-OS-specific stub for > libcxx that they can use on any OS lacking xlocale support. > Replace/enhance the existing shim for Solaris as part of this effort. > Work with the libcxx team to integrate your changes there. > > If they tell you that they won't run on a non-xlocale OS that isn't > Solaris, implement the shim anyway and add it to our ports tree. > > The shim is going to be a lot less work, and doesn't preclude an > implentation inside libc at a later stage. Thanks for showing the right direction. I'll look into it as soon as I have more time; at least I know what is needed and how big is it. -- Martin Pelikan
Re: partial xlocale(3) port from FreeBSD
On Mon, Oct 21, 2013 at 12:45:58AM +0200, Martin Pelikan wrote: > > > > Obviously, our locale support still sucks, this patch is mostly > > > > providing the API for filling the blanks later. > > > > Which blanks exactly? Locale features we don't have, such as collation? > > Yes. The features why for example PostgreSQL won't sort tables > correctly, which if you live in a country with weird characters in their > language is... quite unfortunate. > > I was planning on bringing specifically LC_COLLATE support for a long > time, but it's quite a lot of work. (and testing, and bugfixing with > languages I don't even know existed) Indeed, doing collation properly (i.e. with Unicode, not just 8 bit characters like FreeBSD does) really is a non-trivial effort. It requires some expertise in linguistics and a solid understanding of the unicode standard. You'd need to make use of something like ICU (icu-project.org) to keep your sanity, or implement a whole lot of that code base yourself... > > > How much did the ramdisks grow by when you built release with this? > > > Having just freed up a bunch of space on the ramdisks, I'll be pissed if > > > we squander it all immediately. > > No objections against #ifndef SMALL_KERNEL-ing the big bits. This is about userland parts of the ramdisk. Locales don't affect the kernel. Bloat in ramdisk libc is avoided by compiling API stubs instead of the usual source files. Or some special-case #ifdef other than SMALL_KERNEL. > > I'm not very excited about xlocale. If the only goal here is an API > > shim to compile a C++ library, can't we put the shim somewhere else > > than libc? Like the misc/libutf8 port we used to have? > > Thought about it too, but since apps expect to find this stuff in libc, Applications don't care where a symbol comes from. Build scripts and Makefiles might expect them to be in libc and would need to link an additional library, but that's trivial to do. > I went for a libc diff hoping that porters will have their lives easier. > The functions I ported were the ones ld-2.17 complained about. I have > no idea whether that port is complete and I don't claim the diff to be > ready. It gets the job done at the cost of being huge and probably > wrong in places, and is open for discussion. In my opinion, if you're putting something into libc it should be a correct and functional implementation, not an API stub that doesn't really provide the advertised functionality. Libc is not a stash for missing symbols that exist on other operating systems. > I don't care about xlocale either. What'd I like is to have C++11 > working out of the box for the next release (Is that real?) and > hopefully collation support some time in the future. I think you should tackle your goals (C++11, collation) in isolation. They aren't coupled, really. > Later in the > process I noticed there is an even smaller shim intended for Solaris as > a part of libcxx, Ah. So perhaps the right approach for now is to use reuse that shim? > but my thoughts were: > - Locale has always been a pain in the ass, but something users demand. >(or is it just me with postgresql?) You'll have to be a bit more specific about what's wrong with the current locale implementation and what user demands we don't serve. Otherwise it's hard to have a productive discussion. > - Sharing this stuff with FreeBSD will make our lives easier should >anything go wrong with it. Less work for us + satisfied customers. The FreeBSD collation implementation only works for characters from Latin1. It is based on code from 1995: http://svnweb.freebsd.org/base?view=revision&revision=6485 There haven't been any functional enhancements since. If we bother with collation I think we should try to do better. > - We don't have to be complete, or even advertise it very much. But >stuff that is increasingly popular (like C++11) will work out of the >box. The ability to use modern toolchains for ports should make the >latency-savvy desktop users happier. Then again we must resist adding stubs to our base libraries to make 3rd party stuff happy. Otherwise the quality of base will suffer in the long term. > - Since a lot of operating systems have now adopted solutions (being it >xlocale or others), I suspect libcxx maintainers won't be very happy >about #ifdef __OpenBSD__ So they're happy about their Solaris shim, but won't take an OpenBSD one? > Please correct me if the philosophy is wrong. Or better, suggest other > ways forward :-) Since your priorities clearly lie with C++11 and not locale support in our libc, I think you should try to make libcxx more portable. Going the other way of adding a proper xlocale implementation to libc is going to be frustrating for you if it is not a goal in itself. I would suggest to implement a small and non-OS-specific stub for libcxx that they can use on any OS lacking xlocale support. Replace/enhance the existing shim for Solaris as par
Re: unlimited HFSC v3: more readable, less hacks
* Claudio Jeker [2013-10-21 11:20]: > Can't we not just nuke altq? It is going to die anyway so why try to keep > it alive? no, sorry. as much as keeping it was a mistake (wearing my programmer hat), the painful work has been done already, and the feedback i got on it is clear. besides, newqueue isn't a 100% replacement yet. last not least RED (or sth similiar) is missing. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: unlimited HFSC v3: more readable, less hacks
On Mon, Oct 21, 2013 at 12:04:14AM +0200, Martin Pelikan wrote:
> Hopefully the third time does the charm.
>
> The previous union approach to altq/newq bits was wrong, because
> switching back and forth was racy. This new diff then concatenates
> these structures like [ifqueue, hfsc_if, altq-bits], has some better
> names, doesn't need renaming stuff in the old code (it can remain 2
> years old), removes the now useless ifq_hfsc pointer.
Can't we not just nuke altq? It is going to die anyway so why try to keep
it alive?
> As always, it's being heavily tested.
> --
> Martin Pelikan
>
>
> ? net/hfsc.c.instrumented
> Index: altq/if_altq.h
> ===
> RCS file: /cvs/src/sys/altq/if_altq.h,v
> retrieving revision 1.16
> diff -u -p -r1.16 if_altq.h
> --- altq/if_altq.h12 Oct 2013 12:13:10 - 1.16
> +++ altq/if_altq.h20 Oct 2013 21:25:41 -
> @@ -36,6 +36,13 @@ struct altq_pktattr; struct oldtb_regula
> /*
> * Structure defining a queue for a network interface.
> */
> +
> +/* XXX hack, because we need the structure definition */
> +#define ALTQ_IS_ENABLED 1
> +#include
> +#undef ALTQ_IS_ENABLED
> +/* XXX hack */
> +
> struct ifaltq {
> /* fields compatible with struct ifqueue */
> struct {
> @@ -45,8 +52,8 @@ struct ifaltq {
> int ifq_len;
> int ifq_maxlen;
> int ifq_drops;
> - struct hfsc_if *ifq_hfsc;
> struct timeout *ifq_congestion;
> + struct hfsc_if ifq_hfsc;
>
> /* alternate queueing related fields */
> int altq_type; /* discipline type */
> Index: net/hfsc.c
> ===
> RCS file: /cvs/src/sys/net/hfsc.c,v
> retrieving revision 1.1
> diff -u -p -r1.1 hfsc.c
> --- net/hfsc.c12 Oct 2013 11:39:17 - 1.1
> +++ net/hfsc.c20 Oct 2013 21:25:42 -
> @@ -63,7 +63,7 @@
> /*
> * function prototypes
> */
> -struct hfsc_class*hfsc_class_create(struct hfsc_if *,
> +struct hfsc_class*hfsc_class_create(struct ifqueue *,
> struct hfsc_sc *, struct hfsc_sc *,
> struct hfsc_sc *, struct hfsc_class *, int,
> int, int);
> @@ -128,18 +128,49 @@ hfsc_microuptime(void)
> HFSC_CLK_SHIFT);
> }
>
> +/*
> + * The new table will be exactly one page larger, so in the most
> + * common case of 8B pointers and 4KB pages it's 512 more classes.
> + * Returns the amount of classes, so all new pages are 100% utilized.
> + */
> +static inline u_int
> +hfsc_more_slots(u_int current)
> +{
> + u_int was_pages = current * sizeof(void *) / PAGE_SIZE;
> + u_int n = ((was_pages + 1) * PAGE_SIZE) / sizeof(void *);
> +
> + return (n);
> +}
> +
> +static void
> +hfsc_grow_class_tbl(struct hfsc_if *hif)
> +{
> + struct hfsc_class **newtbl, **old = hif->hif_class_tbl;
> + const u_int slots = hfsc_more_slots(hif->hif_allocated);
> +
> + newtbl = malloc(slots * sizeof(void *), M_DEVBUF, M_WAITOK | M_ZERO);
> + memcpy(newtbl, old, hif->hif_allocated * sizeof(void *));
> +
> + hif->hif_allocated = slots;
> + hif->hif_class_tbl = newtbl;
> +
> + free(old, M_DEVBUF);
> +}
> +
> int
> hfsc_attach(struct ifnet *ifp)
> {
> - struct hfsc_if *hif;
> + const u_int slots = hfsc_more_slots(0);
> + const size_t sz = slots * sizeof(void *);
> + struct hfsc_if *hif = &ifp->if_snd.ifq_hfsc;
>
> - if (ifp->if_snd.ifq_hfsc != NULL)
> + if (hif->hif_class_tbl != NULL)
> return (0);
>
> - hif = malloc(sizeof(struct hfsc_if), M_DEVBUF, M_WAITOK|M_ZERO);
> + hif->hif_class_tbl = malloc(sz, M_DEVBUF, M_WAITOK | M_ZERO);
> + hif->hif_allocated = slots;
> + hif->hif_classes = 0;
> hif->hif_eligible = hfsc_ellist_alloc();
> - hif->hif_ifq = (struct ifqueue *)&ifp->if_snd; /* XXX cast temp */
> - ifp->if_snd.ifq_hfsc = hif;
>
> return (0);
> }
> @@ -147,8 +178,11 @@ hfsc_attach(struct ifnet *ifp)
> int
> hfsc_detach(struct ifnet *ifp)
> {
> - free(ifp->if_snd.ifq_hfsc, M_DEVBUF);
> - ifp->if_snd.ifq_hfsc = NULL;
> + struct hfsc_if *hif = &ifp->if_snd.ifq_hfsc;
> +
> + hif->hif_allocated = hif->hif_classes = 0;
> + free(hif->hif_class_tbl, M_DEVBUF);
> + hif->hif_class_tbl = NULL;
>
> return (0);
> }
> @@ -156,11 +190,13 @@ hfsc_detach(struct ifnet *ifp)
> int
> hfsc_addqueue(struct pf_queuespec *q)
> {
> - struct hfsc_if *hif;
> + /* XXX remove the cast when ifaltq is gone. */
> + struct ifqueue *ifq = (struct ifqueue *)&q->kif->pfik_ifp->if_snd;
> + struct hfsc_if *hif = &ifq->ifq_hfsc;
> struct hfsc_class *cl, *parent;
> struct hfsc_sc rtsc, lssc, ulsc;
>
> - if ((hif = q->kif->pfik_ifp->if_snd.ifq_hfsc) == NULL)
> + if (hif->hif_allocated == 0)
> return (EINVAL);
>
> if (q->par
Re: Add Xbox 360 Controller USB support
On 20/10/13(Sun) 12:09, Jeremy Evans wrote: > On 10/20 03:52, Martin Pieuchot wrote: > > [...] > > Thanks for responding. Here's a new diff that incorporates most of your > suggestions. Unfortunately, using the existing quirks infrastructure > doesn't work correctly, because the quirks API is based on device > manufacturer and vendor, and matching on that instead of interface > subclass and protocol appears to not work correctly. When you plug in > the controller with my original diff and the first diff below, you get: > > uhidev0 at uhub3 port 3 configuration 1 interface 0 "\M-)Microsoft > Corporation Controller" rev 2.00/1.10 addr 2 > uhidev0: iclass 255/93 > uhid0 at uhidev0: input=20, output=0, feature=0 > ugen0 at uhub3 port 3 configuration 1 "\M-)Microsoft Corporation Controller" > rev 2.00/1.10 addr 2 > > As you can see, the controller shows up as both a uhid and a ugen. > > With the second diff below, when you plugin the controller, it > attaches as follows: > > uhidev0 at uhub3 port 3 configuration 1 interface 0 "\M-)Microsoft > Corporation Controller" rev 2.00/1.10 addr 2 > uhidev0: iclass 255/93 > uhid0 at uhidev0: input=20, output=0, feature=0 > uhidev1 at uhub3 port 3 configuration 1 interface 1 "\M-)Microsoft > Corporation Controller" rev 2.00/1.10 addr 2 > uhidev1: iclass 255/93 > uhid1 at uhidev1: input=20, output=0, feature=0 > uhidev2 at uhub3 port 3 configuration 1 interface 2 "\M-)Microsoft > Corporation Controller" rev 2.00/1.10 addr 2 > uhidev2: iclass 255/93 > uhid2 at uhidev2: input=20, output=0, feature=0 > uhidev3 at uhub3 port 3 configuration 1 interface 3 "\M-)Microsoft > Corporation Controller" rev 2.00/1.10 addr 2 > uhidev3: no input interrupt endpoint > > In this case uhid0 appears to work, but uhid1 and uhid2 do not: > > $ usbhidctl -f 1 -a > usbhidctl: USB_GET_REPORT (probably not supported by device): Input/output > error > > Anyway, let me know what you think about the first diff, or if I'm doing > something wrong with the second diff that is causing it to attach > multiple times. You're not doing anything wrong, it's just that your device has more than one interface. In your previous diff you matched only the first interface and now you match any interface of the device. Could you send me the output of "lsusb -v" for your device? (lsusb(1) is in the usbutils package). M.
Re: Wrong rights for ELF interpreters
> I don't get what's wrong with running execve on it. In all cases, > someone can load it through another executable. Using ld.so does not imply "execve'ing it". > If I have an interpreter that I chmod as exec-only, I want this > interpreter to be world-loadable without thereby letting other > users copy it. The same for a library. It is loadable. Because it is readable.
Re: Wrong rights for ELF interpreters
On 10/20/13 21:54, Theo de Raadt wrote: >> Indeed, the interpreter is not passed to execve. That's why I used >> >'get executed' >> >instead of >> >'are executed' >> >though the difference might not be clear. >> > >> >The kernel loads the interpreter, and the code of that interpreter >> >gets executed. So, actually, it plays as an executable. And as long >> >as code gets executed from it, it should have +x rights. >> > >> >Shouldn't it? > Absolutely not, because then someone can try to run execve on it. > Maybe I'm missing something. I don't get what's wrong with running execve on it. In all cases, someone can load it through another executable. If I have an interpreter that I chmod as exec-only, I want this interpreter to be world-loadable without thereby letting other users copy it. The same for a library. > You are not thinking clearly. I've just given a glance to FreeBSD and NetBSD. They both check exec rights, not read rights. So it looks like I'm not the only one who does not think clearly...
