On Sat, May 11, 2019 at 07:23:42PM -0400, Martin Pieuchot wrote:
> Document which fields are protected by the SCHED_LOCK(), ok?
>
> Index: sys/proc.h
> ===
> RCS file: /cvs/src/sys/sys/proc.h,v
> retrieving revision 1.263
> diff -u -p
erated with gpio(4) ioctl calls from userspace,
e.g.: for(;;) { HI(pin); usleep(1); LO(pin(); usleep(1); }
I'd like to see more folks test and other devs to share their
thoughts: What are the risks associated with bumping HZ globally?
Drawbacks? Reasons for hesitation?
Thanks,
Ian Sutton
&g
On Tue, Sep 18, 2018 at 2:16 AM, Jonathan Gray wrote:
> On Tue, Sep 18, 2018 at 08:34:55AM +0200, Claudio Jeker wrote:
>> On Tue, Sep 18, 2018 at 03:49:15PM +1000, Jonathan Gray wrote:
>> > Index: amdisplay.c
>> > ===
>> > RCS file: /
This is a highly theoretical and experimental mitigation which stops the
root password on newly upgraded/installed systems from being an empty
string. The thinking is that by not shipping an operating system with a
known root password, certain classes of attacks involving logging into
the root acco
On Fri, Sep 01, 2017 at 12:17:29AM +0300, Artturi Alm wrote:
> Hi,
>
> rather obvious diff below.
>
> -Artturi
Thanks, committed
committed, thanks
On Mon, Apr 03, 2017 at 01:33:28AM -0400, Ian Sutton wrote:
> The code below is a complete (fourth!) rewrite. It completely and
> correctly controls the hardware but still needs to be plugged into the
> rest of the system (wsdisplay for syscons, wsfb for Xorg, etc.) before
> it is us
p/amdisplay.c
===
RCS file: sys/arch/armv7/omap/amdisplay.c
diff -N sys/arch/armv7/omap/amdisplay.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/omap/amdisplay.c 3 Apr 2017 05:24:33 -
@@ -0,0 +1,628 @@
+/*
+ * Copyright (c) 2016 Ian Sutton
+ *
+ * Perm
Only print details about parsed EDID blocks if -DDIAGNOSTIC, consistent
with the surrounding printf()'s.
Ian
Index: edid.c
===
RCS file: /cvs/src/sys/dev/videomode/edid.c,v
retrieving revision 1.3
diff -u -p -r1.3 edid.c
--- edid.c
On Mon, Feb 27, 2017 at 08:08:16PM +1100, Jonathan Gray wrote:
> There is only one with "ti,edma3-tpcc".
Geez. It may be time to increase my font size.
Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrievi
On Mon, Feb 27, 2017 at 07:59:07PM +1100, Jonathan Gray wrote:
> On Mon, Feb 27, 2017 at 03:34:35AM -0500, Ian Sutton wrote:
> > This patch changes edma(4) to attach via device tree and re-enables it.
>
> Looks like the line wrapping got mangled.
Yes, I had just sent a fixed
Previous patch was malformed, d'oh.
Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -r1.71 GENERIC
--- conf/GENERIC23 Jan 2017 22:43:17 - 1.71
+++ conf/GENE
This patch changes edma(4) to attach via device tree and re-enables it.
Index: conf/GENERIC
===
RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
retrieving revision 1.71
diff -u -p -r1.71 GENERIC
--- conf/GENERIC23 Jan 2017 2
Currently, we do not have a way to iterate over child FDT nodes, which
is a problem when you have a devices like the USB system on the am335x
(Beaglebone Black):
https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=bbb-usb.git;a=blob;f=misc/fdt/am335x-boneblack.dts;h=8799dc1d171961d3cd9a941131a82a15bbe4
On Wed, Nov 23, 2016 at 05:48:27PM -0700, Theo de Raadt wrote:
> > I am assuming that arch/aarch64
>
> There should be no such thing.
>
> This game of calling things 5 names has to stop.
I'm equally irritated and would like to reach a consensus on a single,
final name. I see three candidates:
*
On Wed, Nov 23, 2016 at 08:49:44PM +0100, Patrick Wildt wrote:
> > $ MACHINE=armv8 armmake64-aarch64 -f Makefile.arm64
>
> Please call it arm64. We should distinquish between 32 and 64-bit ARMs
> now. Yes, the other one is called armv7, but that's just how it is.
>
> Typically the ports are cal
Hi,
Patch adds armv8/aarch64 EFI payload image build support. With
patrick@'s aarch64-none-elf- toolchain referenced in my last mail on
this list, you can build it via...
$ MACHINE=armv8 armmake64-aarch64 -f Makefile.arm64
...where armmake64-aarch64 is a simple env wrapper for the toolchain,
upl
(resending as list seemed to eat my last mail)
Hi,
I've got a natively-built bootloader working on the pine64 boards
generously donated to the foundation. Simply dd(1) the following image
directly to a uSD card, insert it, reset the pine64, and you will be
greeted by a u-boot prompt over the seri
On Wed, Oct 05, 2016 at 12:40:42AM -0400, Ian Sutton wrote:
> My driver needs to recognize cases where the root disk is MMC1 and abort
> as to avoid hanging the system when the kernel tries to init userspace
> on a disk it is no longer pinmuxxed to. I am not sure how to properly
> and
Hello,
I'm writing a driver (amdisplay) supporting the LCD controller on the
am335x (Beaglebone Black). The LCD controller pins and the MMC1 pins
(used for interacting with the onboard eMMC flash chip) exist on the
same set of pads such that only the LCD controller or the eMMC may be
used at once.
Some ARM systems have decoupled their display/LCD controllers from their
display transmitters, such as the am335x/beaglebone black whose LCD
controller (on am335x SoC) breaks out to a TDA19988 IC (on PCB). This
sometimes causes sync timing problems in that the timings purported by
the LCD controlle
===
RCS file: arch/armv7/omap/amdisplay.c
diff -N arch/armv7/omap/amdisplay.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ arch/armv7/omap/amdisplay.c 2 Sep 2016 05:06:06 -
@@ -0,0 +1,643 @@
+/*
+ * Copyright (c) 2016 Ian Sutton
On Fri, Aug 19, 2016 at 03:02:34PM +1000, Jonathan Gray wrote:
> On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote:
> > On Thu, Aug 18, 2016 at 04:34:38PM -0400, Ian Sutton wrote:
> > > On Sat, Aug 06, 2016 at 04:26:27AM -0400, Ian Sutton wrote:
> > > >
On Fri, Aug 19, 2016 at 02:38:32PM +1000, Jonathan Gray wrote:
> Have you considered directly attaching the i2c bus to your other
> driver without creating a new driver and using drm_edid.c ?
>
> Perhaps even handle the modesetting ioctls and use the modesetting
> driver with xorg?
I had consider
On Sat, Aug 06, 2016 at 04:26:27AM -0400, Ian Sutton wrote:
> Interestingly, the am335x SoC does not have a HDMI/DP/etc transmitter on
> silicon -- the BBB has its LCDC pins wired to a TDA19988 HDMI
> transmitter which is additionally backwired to one of the am335x's i2c
> ports:
@@ -0,0 +1,496 @@
+/*
+ * Copyright (c) 2016 Ian Sutton
+ *
+ * Permission to use, copy, modify, and distribute this software for
any
+ * purpose with or without fee is hereby granted, provided that the
above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOF
On Sun, Aug 07, 2016 at 10:50:49PM -0600, Theo de Raadt wrote:
> Your diff also contained:
>
> -.Fn config_detach "struct device *dev" "int flags"
> +.Fn config_detach "struct device *dev"
Argh! I had initially given config_deactivate() a flags parameter,
realized it lacked one in the code, and m
config_attach.9 seems to be the man page which best describes what
struct cfattach members do. The following patch adds a section
describing what the ca_activate function pointer within struct cfattach
does via a description of the corresponding config_deactivate function
as to follow config_attach
amdisplay.c
diff -N sys/arch/armv7/omap/amdisplay.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/omap/amdisplay.c 7 Aug 2016 07:40:40 -
@@ -0,0 +1,422 @@
+/*
+ * Copyright (c) 2016 Ian Sutton
+ *
+ * Permission to use, copy, modify, and distribute this software for
an
RCS file: sys/arch/armv7/omap/amdisplay.c
diff -N sys/arch/armv7/omap/amdisplay.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/omap/amdisplay.c 6 Aug 2016 07:59:48 -
@@ -0,0 +1,371 @@
+/*
+ * Copyright (c) 2016 Ian Sutton
+ *
+ * Permission to use, copy, mo
void imxccm_enable_sata(void);
void imxccm_enable_pcie(void);
+void imxccm_enable_hdmi(void);
#endif /* IMXCCMVAR_H */
Index: imx/imxdisplay.c
===
RCS file: imx/imxdisplay.c
diff -N imx/imxdisplay.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++
Be clear.
Ian
Index: sys/dev/rasops/rasops.h
===
RCS file: /cvs/src/sys/dev/rasops/rasops.h,v
retrieving revision 1.17
diff -u -p -r1.17 rasops.h
--- sys/dev/rasops/rasops.h 7 Sep 2015 18:00:58 - 1.17
+++ sys/dev/rasops
imxccm_enable_hdmi(void);
#endif /* IMXCCMVAR_H */
Index: sys/arch/armv7/imx/imxdisplay.c
===
RCS file: sys/arch/armv7/imx/imxdisplay.c
diff -N sys/arch/armv7/imx/imxdisplay.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys/arch/armv7/imx/imxdisplay.c 1 Aug 2016 07:32:00 -0
imxpcie at fdt
+file arch/armv7/imx/imxpcie.cimxpcie
Index: sys/arch/armv7/imx/imxpcie.c
===========
RCS file: sys/arch/armv7/imx/imxpcie.c
diff -N sys/arch/armv7/imx/imxpcie.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sys
OK -- I have tested and fixed the previous design. It is now working
exactly as stated in the man page from my prior mail. Below patch is now
in a review-ready state.
On Wed, Jul 6, 2016 at 3:27 AM, Ian Sutton wrote:
> mainbus -> fdt is next.
tipru(4) now attaches via flattened device tree
==
RCS file: share/man/man4/man4.armv7/tipru.4
diff -N share/man/man4/man4.armv7/tipru.4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/tipru.4 6 Jul 2016 07:45:07 -
@@ -0,0 +1,221 @@
+.\" Copyright (c) 2016 Ian Sutton
On Tue, Jul 5, 2016 at 12:56 AM, Jonathan Gray wrote:
> I don't have time to look into how tied to the rest of the
> system the pru is at the moment.
I can save you the trouble; page 198 of am335x TRM:
"The PRUs have access to all resources on the SoC through the
Interface/OCP Master port"
> Pe
On Mon, Jul 4, 2016 at 10:30 PM, Jonathan Gray wrote:
> Lack of fdt use aside, we don't want to enable something that
> allows userspace access to system memory like this.
I can understand this sentiment. Maybe next time..
Are you saying you are catagorically opposed to a PRU driver or just
oppo
ioctl param is always a pointer, previous wording implied int literal
could be passed (results in EFAULT)
Index: ioctl.2
===
RCS file: /cvs/src/lib/libc/sys/ioctl.2,v
retrieving revision 1.18
diff -u -p -r1.18 ioctl.2
--- ioctl.2
ll 1 Jan 1970 00:00:00 -
+++ share/man/man4/man4.armv7/tipru.4 4 Jul 2016 08:54:22 -
@@ -0,0 +1,113 @@
+.\" Copyright (c) 2016 Ian Sutton
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" purpose with or without fee is hereby gran
This gives me an idea for how to solve the lack of a first-stage
bootloader (like biosboot(8)) on armv7. Currently U-Boot loads the
kernel image directly into memory and jmp's to its entry point without
an intermediary stage to read /etc/random.seed from disk and provide it
to the kernel to kicksta
Hi,
Uwe & I have revised my earlier sdmmc patch adding support for
sector-mode bit setting on certain eMMC devices. Here were my tests
confirming it works:
> On Tue, Oct 27, 2015 at 10:49 PM, ian kremlin wrote:
> > On Tue, Oct 27, 2015 at 9:26 PM, Uwe Stuehler wrote:
> >> Can someone verify tha
> I tried enabling bits in the ccm, enabling clocks, making various
> changes to imxesdhc itself and didn't get anywhere. Similiar story
> with the usb otg port on the cubox.
I have made some headway. Compiling with -DSDHC_DEBUG shows imxesdhc
follows all the nessecary steps for initialization, v
43 matches
Mail list logo
