[ANNOUNCE] v5.4.10-rt5

[ANNOUNCE] v5.4.10-rt5

[Sebastian Andrzej Siewior]

Dear RT folks!

I'm pleased to announce the v5.4.10-rt5 patch set. 

Changes since v5.4.10-rt4:

  - Dick Hollenbeck reported that the printk rework had a negative
    impact on the 8250 driver if not used as a console. Patch by John
    Ogness.

Known issues
     - None

The delta patch against v5.4.10-rt4 is appended below and can be found here:
 
     https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch-5.4.10-rt4-rt5.patch.xz

You can get this release via the git tree at:

    git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git v5.4.10-rt5

The RT patch against v5.4.10 can be found here:

    https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/older/patch-5.4.10-rt5.patch.xz

The split quilt queue is available at:

    https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/older/patches-5.4.10-rt5.tar.xz

Sebastian

diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 4e6c74330829d..b29aed97a54dc 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -96,10 +96,6 @@ struct serial8250_config {
 #define SERIAL8250_SHARE_IRQS 0
 #endif
 
-void set_ier(struct uart_8250_port *up, unsigned char ier);
-void clear_ier(struct uart_8250_port *up);
-void restore_ier(struct uart_8250_port *up);
-
 #define SERIAL8250_PORT_FLAGS(_base, _irq, _flags)		\
 	{							\
 		.iobase		= _base,			\
@@ -134,21 +130,55 @@ static inline void serial_dl_write(struct uart_8250_port *up, int value)
 	up->dl_write(up, value);
 }
 
+static inline void serial8250_set_IER(struct uart_8250_port *up,
+				      unsigned char ier)
+{
+	struct uart_port *port = &up->port;
+	unsigned int flags;
+	bool is_console;
+
+	is_console = uart_console(port);
+
+	if (is_console)
+		console_atomic_lock(&flags);
+
+	serial_out(up, UART_IER, ier);
+
+	if (is_console)
+		console_atomic_unlock(flags);
+}
+
+static inline unsigned char serial8250_clear_IER(struct uart_8250_port *up)
+{
+	struct uart_port *port = &up->port;
+	unsigned int clearval = 0;
+	unsigned int prior;
+	unsigned int flags;
+	bool is_console;
+
+	is_console = uart_console(port);
+
+	if (up->capabilities & UART_CAP_UUE)
+		clearval = UART_IER_UUE;
+
+	if (is_console)
+		console_atomic_lock(&flags);
+
+	prior = serial_port_in(port, UART_IER);
+	serial_port_out(port, UART_IER, clearval);
+
+	if (is_console)
+		console_atomic_unlock(flags);
+
+	return prior;
+}
+
 static inline bool serial8250_set_THRI(struct uart_8250_port *up)
 {
 	if (up->ier & UART_IER_THRI)
 		return false;
 	up->ier |= UART_IER_THRI;
-	serial_out(up, UART_IER, up->ier);
-	return true;
-}
-
-static inline bool serial8250_set_THRI_sier(struct uart_8250_port *up)
-{
-	if (up->ier & UART_IER_THRI)
-		return false;
-	up->ier |= UART_IER_THRI;
-	set_ier(up, up->ier);
+	serial8250_set_IER(up, up->ier);
 	return true;
 }
 
@@ -157,16 +187,7 @@ static inline bool serial8250_clear_THRI(struct uart_8250_port *up)
 	if (!(up->ier & UART_IER_THRI))
 		return false;
 	up->ier &= ~UART_IER_THRI;
-	serial_out(up, UART_IER, up->ier);
-	return true;
-}
-
-static inline bool serial8250_clear_THRI_sier(struct uart_8250_port *up)
-{
-	if (!(up->ier & UART_IER_THRI))
-		return false;
-	up->ier &= ~UART_IER_THRI;
-	set_ier(up, up->ier);
+	serial8250_set_IER(up, up->ier);
 	return true;
 }
 
diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 8c40472eff194..eabb9274c0a9d 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -275,7 +275,7 @@ static void serial8250_timeout(struct timer_list *t)
 static void serial8250_backup_timeout(struct timer_list *t)
 {
 	struct uart_8250_port *up = from_timer(up, t, timer);
-	unsigned int iir, lsr;
+	unsigned int iir, ier = 0, lsr;
 	unsigned long flags;
 
 	spin_lock_irqsave(&up->port.lock, flags);
@@ -285,7 +285,7 @@ static void serial8250_backup_timeout(struct timer_list *t)
 	 * based handler.
 	 */
 	if (up->port.irq)
-		clear_ier(up);
+		ier = serial8250_clear_IER(up);
 
 	iir = serial_in(up, UART_IIR);
 
@@ -308,7 +308,7 @@ static void serial8250_backup_timeout(struct timer_list *t)
 		serial8250_tx_chars(up);
 
 	if (up->port.irq)
-		restore_ier(up);
+		serial8250_set_IER(up, ier);
 
 	spin_unlock_irqrestore(&up->port.lock, flags);
 
diff --git a/drivers/tty/serial/8250/8250_dma.c b/drivers/tty/serial/8250/8250_dma.c
index c91dafbca57c9..890fa7ddaa7f3 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
@@ -35,7 +35,7 @@ static void __dma_tx_complete(void *param)
 
 	ret = serial8250_tx_dma(p);
 	if (ret)
-		serial8250_set_THRI_sier(p);
+		serial8250_set_THRI(p);
 
 	spin_unlock_irqrestore(&p->port.lock, flags);
 }
@@ -98,7 +98,7 @@ int serial8250_tx_dma(struct uart_8250_port *p)
 	dma_async_issue_pending(dma->txchan);
 	if (dma->tx_err) {
 		dma->tx_err = 0;
-		serial8250_clear_THRI_sier(p);
+		serial8250_clear_THRI(p);
 	}
 	return 0;
 err:
diff --git a/drivers/tty/serial/8250/8250_fsl.c b/drivers/tty/serial/8250/8250_fsl.c
index aa0e216d5eadb..8f711afadd4b5 100644
--- a/drivers/tty/serial/8250/8250_fsl.c
+++ b/drivers/tty/serial/8250/8250_fsl.c
@@ -57,9 +57,18 @@ int fsl8250_handle_irq(struct uart_port *port)
 
 	/* Stop processing interrupts on input overrun */
 	if ((orig_lsr & UART_LSR_OE) && (up->overrun_backoff_time_ms > 0)) {
+		unsigned int ca_flags;
 		unsigned long delay;
+		bool is_console;
 
+		is_console = uart_console(port);
+
+		if (is_console)
+			console_atomic_lock(&ca_flags);
 		up->ier = port->serial_in(port, UART_IER);
+		if (is_console)
+			console_atomic_unlock(ca_flags);
+
 		if (up->ier & (UART_IER_RLSI | UART_IER_RDI)) {
 			port->ops->stop_rx(port);
 		} else {
diff --git a/drivers/tty/serial/8250/8250_ingenic.c b/drivers/tty/serial/8250/8250_ingenic.c
index 424c07c5f6299..47f1482bd818a 100644
--- a/drivers/tty/serial/8250/8250_ingenic.c
+++ b/drivers/tty/serial/8250/8250_ingenic.c
@@ -146,6 +146,8 @@ OF_EARLYCON_DECLARE(x1000_uart, "ingenic,x1000-uart",
 
 static void ingenic_uart_serial_out(struct uart_port *p, int offset, int value)
 {
+	unsigned int flags;
+	bool is_console;
 	int ier;
 
 	switch (offset) {
@@ -167,7 +169,12 @@ static void ingenic_uart_serial_out(struct uart_port *p, int offset, int value)
 		 * If we have enabled modem status IRQs we should enable
 		 * modem mode.
 		 */
+		is_console = uart_console(p);
+		if (is_console)
+			console_atomic_lock(&flags);
 		ier = p->serial_in(p, UART_IER);
+		if (is_console)
+			console_atomic_unlock(flags);
 
 		if (ier & UART_IER_MSI)
 			value |= UART_MCR_MDCE | UART_MCR_FCM;
diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
index 4d067f515f748..b509c3de0301f 100644
--- a/drivers/tty/serial/8250/8250_mtk.c
+++ b/drivers/tty/serial/8250/8250_mtk.c
@@ -212,12 +212,37 @@ static void mtk8250_shutdown(struct uart_port *port)
 
 static void mtk8250_disable_intrs(struct uart_8250_port *up, int mask)
 {
-	serial_out(up, UART_IER, serial_in(up, UART_IER) & (~mask));
+	struct uart_port *port = &up->port;
+	unsigned int flags;
+	unsigned int ier;
+	bool is_console;
+
+	is_console = uart_console(port);
+
+	if (is_console)
+		console_atomic_lock(&flags);
+
+	ier = serial_in(up, UART_IER);
+	serial_out(up, UART_IER, ier & (~mask));
+
+	if (is_console)
+		console_atomic_unlock(flags);
 }
 
 static void mtk8250_enable_intrs(struct uart_8250_port *up, int mask)
 {
-	serial_out(up, UART_IER, serial_in(up, UART_IER) | mask);
+	struct uart_port *port = &up->port;
+	unsigned int flags;
+	unsigned int ier;
+
+	if (uart_console(port))
+		console_atomic_lock(&flags);
+
+	ier = serial_in(up, UART_IER);
+	serial_out(up, UART_IER, ier | mask);
+
+	if (uart_console(port))
+		console_atomic_unlock(flags);
 }
 
 static void mtk8250_set_flow_ctrl(struct uart_8250_port *up, int mode)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 51d9a79b70db3..7767701122236 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -721,7 +721,7 @@ static void serial8250_set_sleep(struct uart_8250_port *p, int sleep)
 			serial_out(p, UART_EFR, UART_EFR_ECB);
 			serial_out(p, UART_LCR, 0);
 		}
-		set_ier(p, sleep ? UART_IERX_SLEEP : 0);
+		serial8250_set_IER(p, sleep ? UART_IERX_SLEEP : 0);
 		if (p->capabilities & UART_CAP_EFR) {
 			serial_out(p, UART_LCR, UART_LCR_CONF_MODE_B);
 			serial_out(p, UART_EFR, efr);
@@ -1390,7 +1390,7 @@ static void serial8250_stop_rx(struct uart_port *port)
 
 	up->ier &= ~(UART_IER_RLSI | UART_IER_RDI);
 	up->port.read_status_mask &= ~UART_LSR_DR;
-	set_ier(up, up->ier);
+	serial8250_set_IER(up, up->ier);
 
 	serial8250_rpm_put(up);
 }
@@ -1408,7 +1408,7 @@ static void __do_stop_tx_rs485(struct uart_8250_port *p)
 		serial8250_clear_and_reinit_fifos(p);
 
 		p->ier |= UART_IER_RLSI | UART_IER_RDI;
-		set_ier(p, p->ier);
+		serial8250_set_IER(p, p->ier);
 	}
 }
 static enum hrtimer_restart serial8250_em485_handle_stop_tx(struct hrtimer *t)
@@ -1459,7 +1459,7 @@ static void __stop_tx_rs485(struct uart_8250_port *p)
 
 static inline void __do_stop_tx(struct uart_8250_port *p)
 {
-	if (serial8250_clear_THRI_sier(p))
+	if (serial8250_clear_THRI(p))
 		serial8250_rpm_put_tx(p);
 }
 
@@ -1509,7 +1509,7 @@ static inline void __start_tx(struct uart_port *port)
 	if (up->dma && !up->dma->tx_dma(up))
 		return;
 
-	if (serial8250_set_THRI_sier(up)) {
+	if (serial8250_set_THRI(up)) {
 		if (up->bugs & UART_BUG_TXEN) {
 			unsigned char lsr;
 
@@ -1616,7 +1616,7 @@ static void serial8250_disable_ms(struct uart_port *port)
 	mctrl_gpio_disable_ms(up->gpios);
 
 	up->ier &= ~UART_IER_MSI;
-	set_ier(up, up->ier);
+	serial8250_set_IER(up, up->ier);
 }
 
 static void serial8250_enable_ms(struct uart_port *port)
@@ -1632,7 +1632,7 @@ static void serial8250_enable_ms(struct uart_port *port)
 	up->ier |= UART_IER_MSI;
 
 	serial8250_rpm_get(up);
-	set_ier(up, up->ier);
+	serial8250_set_IER(up, up->ier);
 	serial8250_rpm_put(up);
 }
 
@@ -1991,54 +1991,6 @@ static void wait_for_xmitr(struct uart_8250_port *up, int bits)
 	}
 }
 
-static atomic_t ier_counter = ATOMIC_INIT(0);
-static atomic_t ier_value = ATOMIC_INIT(0);
-
-void set_ier(struct uart_8250_port *up, unsigned char ier)
-{
-	struct uart_port *port = &up->port;
-	unsigned int flags;
-
-	console_atomic_lock(&flags);
-	if (atomic_read(&ier_counter) > 0)
-		atomic_set(&ier_value, ier);
-	else
-		serial_port_out(port, UART_IER, ier);
-	console_atomic_unlock(flags);
-}
-
-void clear_ier(struct uart_8250_port *up)
-{
-	struct uart_port *port = &up->port;
-	unsigned int ier_cleared = 0;
-	unsigned int flags;
-	unsigned int ier;
-
-	console_atomic_lock(&flags);
-	atomic_inc(&ier_counter);
-	ier = serial_port_in(port, UART_IER);
-	if (up->capabilities & UART_CAP_UUE)
-		ier_cleared = UART_IER_UUE;
-	if (ier != ier_cleared) {
-		serial_port_out(port, UART_IER, ier_cleared);
-		atomic_set(&ier_value, ier);
-	}
-	console_atomic_unlock(flags);
-}
-EXPORT_SYMBOL_GPL(clear_ier);
-
-void restore_ier(struct uart_8250_port *up)
-{
-	struct uart_port *port = &up->port;
-	unsigned int flags;
-
-	console_atomic_lock(&flags);
-	if (atomic_fetch_dec(&ier_counter) == 1)
-		serial_port_out(port, UART_IER, atomic_read(&ier_value));
-	console_atomic_unlock(flags);
-}
-EXPORT_SYMBOL_GPL(restore_ier);
-
 #ifdef CONFIG_CONSOLE_POLL
 /*
  * Console polling routines for writing and reading from the uart while
@@ -2070,10 +2022,11 @@ static int serial8250_get_poll_char(struct uart_port *port)
 static void serial8250_put_poll_char(struct uart_port *port,
 			 unsigned char c)
 {
+	unsigned int ier;
 	struct uart_8250_port *up = up_to_u8250p(port);
 
 	serial8250_rpm_get(up);
-	clear_ier(up);
+	ier = serial8250_clear_IER(up);
 
 	wait_for_xmitr(up, BOTH_EMPTY);
 	/*
@@ -2086,7 +2039,7 @@ static void serial8250_put_poll_char(struct uart_port *port,
 	 *	and restore the IER
 	 */
 	wait_for_xmitr(up, BOTH_EMPTY);
-	restore_ier(up);
+	serial8250_set_IER(up, ier);
 	serial8250_rpm_put(up);
 }
 
@@ -2394,7 +2347,7 @@ void serial8250_do_shutdown(struct uart_port *port)
 	 */
 	spin_lock_irqsave(&port->lock, flags);
 	up->ier = 0;
-	set_ier(up, 0);
+	serial8250_set_IER(up, 0);
 	spin_unlock_irqrestore(&port->lock, flags);
 
 	synchronize_irq(port->irq);
@@ -2679,7 +2632,7 @@ serial8250_do_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (up->capabilities & UART_CAP_RTOIE)
 		up->ier |= UART_IER_RTOIE;
 
-	set_ier(up, up->ier);
+	serial8250_set_IER(up, up->ier);
 
 	if (up->capabilities & UART_CAP_EFR) {
 		unsigned char efr = 0;
@@ -3189,12 +3142,13 @@ void serial8250_console_write_atomic(struct uart_8250_port *up,
 {
 	struct uart_port *port = &up->port;
 	unsigned int flags;
+	unsigned int ier;
 
 	console_atomic_lock(&flags);
 
 	touch_nmi_watchdog();
 
-	clear_ier(up);
+	ier = serial8250_clear_IER(up);
 
 	if (atomic_fetch_inc(&up->console_printing)) {
 		uart_console_write(port, "\n", 1,
@@ -3204,7 +3158,7 @@ void serial8250_console_write_atomic(struct uart_8250_port *up,
 	atomic_dec(&up->console_printing);
 
 	wait_for_xmitr(up, BOTH_EMPTY);
-	restore_ier(up);
+	serial8250_set_IER(up, ier);
 
 	console_atomic_unlock(flags);
 }
@@ -3220,13 +3174,14 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
 {
 	struct uart_port *port = &up->port;
 	unsigned long flags;
+	unsigned int ier;
 
 	touch_nmi_watchdog();
 
 	serial8250_rpm_get(up);
 	spin_lock_irqsave(&port->lock, flags);
 
-	clear_ier(up);
+	ier = serial8250_clear_IER(up);
 
 	/* check scratch reg to see if port powered off during system sleep */
 	if (up->canary && (up->canary != serial_port_in(port, UART_SCR))) {
@@ -3243,7 +3198,7 @@ void serial8250_console_write(struct uart_8250_port *up, const char *s,
 	 *	and restore the IER
 	 */
 	wait_for_xmitr(up, BOTH_EMPTY);
-	restore_ier(up);
+	serial8250_set_IER(up, ier);
 
 	/*
 	 *	The receive handling will happen properly because the
diff --git a/localversion-rt b/localversion-rt
index ad3da1bcab7e8..0efe7ba1930e1 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt4
+-rt5

Re: [ANNOUNCE] v5.4.10-rt5

[Gene Heskett]

On Friday 10 January 2020 15:14:30 Sebastian Andrzej Siewior wrote:

> Dear RT folks!
>
> I'm pleased to announce the v5.4.10-rt5 patch set.
>
> Changes since v5.4.10-rt4:
>
>   - Dick Hollenbeck reported that the printk rework had a negative
>     impact on the 8250 driver if not used as a console. Patch by John
>     Ogness.
>
> Known issues
>      - None
>
> The delta patch against v5.4.10-rt4 is appended below and can be found
> here:
>
>     
> https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch-5.4
>.10-rt4-rt5.patch.xz
>
> You can get this release via the git tree at:
>
>    
> git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
> v5.4.10-rt5

I grabbed a copy of this, then turned off anything not needed to run 
LinuxCNC on an rpi4 in armhf config.  Then I noted its make had a make 
deb-pkg option.  But it isn't making what I told it to make as I'm 
sitting here watching it ALL go by. Did I miss something in  a make 
menuconfig that triggered a make all? It was supposedly set for armhf.  
But I'm even seeing x86 stuff go by. Obviously I know just enough to 
screw it up. Point me at the right docs for arm builds please.

Thank you.
[...]

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [ANNOUNCE] v5.4.10-rt5

[Alexander Dahl]

Hello Gene,

Am Sonntag, 12. Januar 2020, 21:22:10 CET schrieb Gene Heskett:
> I grabbed a copy of this, then turned off anything not needed to run
> LinuxCNC on an rpi4 in armhf config.  Then I noted its make had a make
> deb-pkg option.  But it isn't making what I told it to make as I'm
> sitting here watching it ALL go by. Did I miss something in  a make
> menuconfig that triggered a make all? It was supposedly set for armhf.
> But I'm even seeing x86 stuff go by. Obviously I know just enough to
> screw it up. Point me at the right docs for arm builds please.

Building a RT kernel is no different than building any other kernel with 
patches. Patch your kernel source, configure, compile … 

You can use any howto or docs for building the kernel for your platform. 
Speaking of RPi4, it depends on your Linux distribution and whether you 
compile on the target or do cross compiling from another machine. But if you 
got this sorted out, you just need to apply the RT patch and build again.

However this list is probably not the right place for that sort of questions.

HTH & Greets
Alex

Re: [ANNOUNCE] v5.4.10-rt5

[Paul Thomas]

On Sun, Jan 12, 2020 at 9:44 PM Gene Heskett <gheskett@shentel.net> wrote:
>
> On Friday 10 January 2020 15:14:30 Sebastian Andrzej Siewior wrote:
>
> > Dear RT folks!
> >
> > I'm pleased to announce the v5.4.10-rt5 patch set.
> >
> > Changes since v5.4.10-rt4:
> >
> >   - Dick Hollenbeck reported that the printk rework had a negative
> >     impact on the 8250 driver if not used as a console. Patch by John
> >     Ogness.
> >
> > Known issues
> >      - None
> >
> > The delta patch against v5.4.10-rt4 is appended below and can be found
> > here:
> >
> >
> > https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch-5.4
> >.10-rt4-rt5.patch.xz
> >
> > You can get this release via the git tree at:
> >
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git
> > v5.4.10-rt5
>
> I grabbed a copy of this, then turned off anything not needed to run
> LinuxCNC on an rpi4 in armhf config.  Then I noted its make had a make
> deb-pkg option.  But it isn't making what I told it to make as I'm
> sitting here watching it ALL go by. Did I miss something in  a make
> menuconfig that triggered a make all? It was supposedly set for armhf.
> But I'm even seeing x86 stuff go by. Obviously I know just enough to
> screw it up. Point me at the right docs for arm builds please.

Hi Gene,

I recently stumbled into deb-pkg, and it's awesome building up the
source and standard debian packages all in one command, but it takes
the same arguments as a standard make. For rpi4 this is arm64 not
armhf so you probably want something like below to configure for
arm64. If you are doing this on the rpi4 you don't need the
CROSS_COMPILE= option.[1][2]
make -j4 ARCH=arm64 CROSS_COMPILE=aarch64-elf- defconfig
Or if the kernel you're already running has a /proc/config.gz you can
use that directly (zcat /proc/config.gz > .config).
Then you can use the main make.
make -j4 ARCH=arm64 CROSS_COMPILE=aarch64-elf- deb-pkg
Keep in mind that even with the debian package this may not be enough
to install the kernel for u-boot correctly, You'll have to see if all
the scripts in /etc/kernel/postinst.d/ are doing everything that is
needed, but it should give you at least a /boot/vmlinuz... When I use
this I have to extract the compressed Image to where u-boot grabs the
kernel.

Hope this helps.

thanks,
Paul

[1] The -j4 says to use up to 4 jobs which will speed up the compile
with a 4-core processor
[2] aarch64-elf- is you're cross-compiler prefix if you are
cross-compiling. If you don't have this, read up on cross-compilers
and check out Linaro (https://www.linaro.org/downloads/)

Re: [ANNOUNCE] v5.4.10-rt5

[Gene Heskett]

On Tuesday 14 January 2020 08:54:30 Paul Thomas wrote:

> On Sun, Jan 12, 2020 at 9:44 PM Gene Heskett <gheskett@shentel.net> 
wrote:
> > On Friday 10 January 2020 15:14:30 Sebastian Andrzej Siewior wrote:
> > > Dear RT folks!
> > >
> > > I'm pleased to announce the v5.4.10-rt5 patch set.
> > >
> > > Changes since v5.4.10-rt4:
> > >
> > >   - Dick Hollenbeck reported that the printk rework had a negative
> > >     impact on the 8250 driver if not used as a console. Patch by
> > > John Ogness.
> > >
> > > Known issues
> > >      - None
> > >
> > > The delta patch against v5.4.10-rt4 is appended below and can be
> > > found here:
> > >
> > >
> > > https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch
> > >-5.4 .10-rt4-rt5.patch.xz
> > >
> > > You can get this release via the git tree at:
> > >
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.gi
> > >t v5.4.10-rt5
> >
> > I grabbed a copy of this, then turned off anything not needed to run
> > LinuxCNC on an rpi4 in armhf config.  Then I noted its make had a
> > make deb-pkg option.  But it isn't making what I told it to make as
> > I'm sitting here watching it ALL go by. Did I miss something in  a
> > make menuconfig that triggered a make all? It was supposedly set for
> > armhf. But I'm even seeing x86 stuff go by. Obviously I know just
> > enough to screw it up. Point me at the right docs for arm builds
> > please.
> >
> > Hi Gene,
>
> I recently stumbled into deb-pkg, and it's awesome building up the
> source and standard debian packages all in one command, but it takes
> the same arguments as a standard make. For rpi4 this is arm64 not
> armhf so you probably want something like below to configure for
> arm64

armhf (32 bit) runs fine in on an RPI4, been doing it for a couple months 
now. With a 32 bit stack frame, context switch latencies are several 
microseconds better which linuxcnc loves. However with mesa interface 
cards handling all the sub-millisecond stuffs and using preempt-rt 
running in userspace, it all works quite well as the  max latency stays 
below 200 microseconds 99.99% of the time. Thats well within the 
servo-thread time of 1 millisecond the mesa cards need. 

> If you are doing this on the rpi4 you don't need the 
> CROSS_COMPILE= option.[1][2] make -j4 ARCH=arm64
> CROSS_COMPILE=aarch64-elf- defconfig
> Or if the kernel you're already running has a /proc/config.gz you can
> use that directly (zcat /proc/config.gz > .config).
> Then you can use the main make.

The kernel I an running was built, by me (queue the raspberry noises), 
with only the ondemand governer so while its working, its stuck in low 
gear. And the pi has plenty of cooling.

that kernel running now is a 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT, but 
there has since been added another video speedup option, so ATM I am 
trying to build a 4.19.94-rt38 announced last week. But the git clone I 
pulled doesn't have the rt patch. And pulling that patch with curl today 
fails:

pi@rpi4:/media/pi/workspace $ curl  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.94-rt38.patch.xz
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

But firefox pulled it, I've unpacked it, but the usual patch -p1 
<../patches/* syntax fails, ambiguous redirect 

Obviously a greenhorn at work, been running a linux only house since '98. 
And the wet ram is 85 yo.

Next? & thank you a bunch

> make -j4 ARCH=arm64 CROSS_COMPILE=aarch64-elf- deb-pkg
> Keep in mind that even with the debian package this may not be enough
> to install the kernel for u-boot correctly, You'll have to see if all
> the scripts in /etc/kernel/postinst.d/ are doing everything that is
> needed, but it should give you at least a /boot/vmlinuz... When I use
> this I have to extract the compressed Image to where u-boot grabs the
> kernel.
>
> Hope this helps.
>
> thanks,
> Paul
>
I have a recipe that installs to a u-boot already.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [ANNOUNCE] v5.4.10-rt5

[Paul Thomas]

On Tue, Jan 14, 2020 at 11:24 AM Gene Heskett <gheskett@shentel.net> wrote:
>
> On Tuesday 14 January 2020 08:54:30 Paul Thomas wrote:
>
> > On Sun, Jan 12, 2020 at 9:44 PM Gene Heskett <gheskett@shentel.net>
> wrote:
> > > On Friday 10 January 2020 15:14:30 Sebastian Andrzej Siewior wrote:
> > > > Dear RT folks!
> > > >
> > > > I'm pleased to announce the v5.4.10-rt5 patch set.
> > > >
> > > > Changes since v5.4.10-rt4:
> > > >
> > > >   - Dick Hollenbeck reported that the printk rework had a negative
> > > >     impact on the 8250 driver if not used as a console. Patch by
> > > > John Ogness.
> > > >
> > > > Known issues
> > > >      - None
> > > >
> > > > The delta patch against v5.4.10-rt4 is appended below and can be
> > > > found here:
> > > >
> > > >
> > > > https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/patch
> > > >-5.4 .10-rt4-rt5.patch.xz
> > > >
> > > > You can get this release via the git tree at:
> > > >
> > > >
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.gi
> > > >t v5.4.10-rt5
> > >
> > > I grabbed a copy of this, then turned off anything not needed to run
> > > LinuxCNC on an rpi4 in armhf config.  Then I noted its make had a
> > > make deb-pkg option.  But it isn't making what I told it to make as
> > > I'm sitting here watching it ALL go by. Did I miss something in  a
> > > make menuconfig that triggered a make all? It was supposedly set for
> > > armhf. But I'm even seeing x86 stuff go by. Obviously I know just
> > > enough to screw it up. Point me at the right docs for arm builds
> > > please.
> > >
> > > Hi Gene,
> >
> > I recently stumbled into deb-pkg, and it's awesome building up the
> > source and standard debian packages all in one command, but it takes
> > the same arguments as a standard make. For rpi4 this is arm64 not
> > armhf so you probably want something like below to configure for
> > arm64
>
> armhf (32 bit) runs fine in on an RPI4, been doing it for a couple months
> now. With a 32 bit stack frame, context switch latencies are several
> microseconds better which linuxcnc loves. However with mesa interface
> cards handling all the sub-millisecond stuffs and using preempt-rt
> running in userspace, it all works quite well as the  max latency stays
> below 200 microseconds 99.99% of the time. Thats well within the
> servo-thread time of 1 millisecond the mesa cards need.
Ah, makes sense.

>
> > If you are doing this on the rpi4 you don't need the
> > CROSS_COMPILE= option.[1][2] make -j4 ARCH=arm64
> > CROSS_COMPILE=aarch64-elf- defconfig
> > Or if the kernel you're already running has a /proc/config.gz you can
> > use that directly (zcat /proc/config.gz > .config).
> > Then you can use the main make.
>
> The kernel I an running was built, by me (queue the raspberry noises),
> with only the ondemand governer so while its working, its stuck in low
> gear. And the pi has plenty of cooling.
>
> that kernel running now is a 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT, but
> there has since been added another video speedup option, so ATM I am
> trying to build a 4.19.94-rt38 announced last week. But the git clone I
> pulled doesn't have the rt patch. And pulling that patch with curl today
> fails:
>
> pi@rpi4:/media/pi/workspace $ curl
> http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.94-rt38.patch.xz
Hmm, this seems fine for me:
 wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.94.tar.xz
 tar -xf linux-4.19.94.tar.xz
 cd linux-4.19.94/
 wget http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.94-rt38.patch.xz
 unxz patch-4.19.94-rt38.patch.xz
 patch -p1 < patch-4.19.94-rt38.patch
 make ARCH=armhf defconfig

-Paul

> <html>
> <head><title>301 Moved Permanently</title></head>
> <body>
> <center><h1>301 Moved Permanently</h1></center>
> <hr><center>nginx</center>
> </body>
> </html>
>
> But firefox pulled it, I've unpacked it, but the usual patch -p1
> <../patches/* syntax fails, ambiguous redirect

>
> Obviously a greenhorn at work, been running a linux only house since '98.
> And the wet ram is 85 yo.
>
> Next? & thank you a bunch
>
> > make -j4 ARCH=arm64 CROSS_COMPILE=aarch64-elf- deb-pkg
> > Keep in mind that even with the debian package this may not be enough
> > to install the kernel for u-boot correctly, You'll have to see if all
> > the scripts in /etc/kernel/postinst.d/ are doing everything that is
> > needed, but it should give you at least a /boot/vmlinuz... When I use
> > this I have to extract the compressed Image to where u-boot grabs the
> > kernel.
> >
> > Hope this helps.
> >
> > thanks,
> > Paul
> >
> I have a recipe that installs to a u-boot already.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [ANNOUNCE] v5.4.10-rt5

[Gene Heskett]

On Tuesday 14 January 2020 12:15:37 Paul Thomas wrote:

> On Tue, Jan 14, 2020 at 11:24 AM Gene Heskett <gheskett@shentel.net> 
wrote:
> > On Tuesday 14 January 2020 08:54:30 Paul Thomas wrote:
> > > On Sun, Jan 12, 2020 at 9:44 PM Gene Heskett
> > > <gheskett@shentel.net>
> >
> > wrote:
> > > > On Friday 10 January 2020 15:14:30 Sebastian Andrzej Siewior 
wrote:
> > > > > Dear RT folks!
> > > > >
> > > > > I'm pleased to announce the v5.4.10-rt5 patch set.
> > > > >
> > > > > Changes since v5.4.10-rt4:
> > > > >
> > > > >   - Dick Hollenbeck reported that the printk rework had a
> > > > > negative impact on the 8250 driver if not used as a console.
> > > > > Patch by John Ogness.
> > > > >
> > > > > Known issues
> > > > >      - None
> > > > >
> > > > > The delta patch against v5.4.10-rt4 is appended below and can
> > > > > be found here:
> > > > >
> > > > >
> > > > > https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/p
> > > > >atch -5.4 .10-rt4-rt5.patch.xz
> > > > >
> > > > > You can get this release via the git tree at:
> > > > >
> > > > >
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-deve
> > > > >l.gi t v5.4.10-rt5
> > > >
> > > > I grabbed a copy of this, then turned off anything not needed to
> > > > run LinuxCNC on an rpi4 in armhf config.  Then I noted its make
> > > > had a make deb-pkg option.  But it isn't making what I told it
> > > > to make as I'm sitting here watching it ALL go by. Did I miss
> > > > something in  a make menuconfig that triggered a make all? It
> > > > was supposedly set for armhf. But I'm even seeing x86 stuff go
> > > > by. Obviously I know just enough to screw it up. Point me at the
> > > > right docs for arm builds please.
> > > >
> > > > Hi Gene,
> > >
> > > I recently stumbled into deb-pkg, and it's awesome building up the
> > > source and standard debian packages all in one command, but it
> > > takes the same arguments as a standard make. For rpi4 this is
> > > arm64 not armhf so you probably want something like below to
> > > configure for arm64
> >
> > armhf (32 bit) runs fine in on an RPI4, been doing it for a couple
> > months now. With a 32 bit stack frame, context switch latencies are
> > several microseconds better which linuxcnc loves. However with mesa
> > interface cards handling all the sub-millisecond stuffs and using
> > preempt-rt running in userspace, it all works quite well as the  max
> > latency stays below 200 microseconds 99.99% of the time. Thats well
> > within the servo-thread time of 1 millisecond the mesa cards need.
>
> Ah, makes sense.
>
> > > If you are doing this on the rpi4 you don't need the
> > > CROSS_COMPILE= option.[1][2] make -j4 ARCH=arm64
> > > CROSS_COMPILE=aarch64-elf- defconfig
> > > Or if the kernel you're already running has a /proc/config.gz you
> > > can use that directly (zcat /proc/config.gz > .config).
> > > Then you can use the main make.
> >
> > The kernel I an running was built, by me (queue the raspberry
> > noises), with only the ondemand governer so while its working, its
> > stuck in low gear. And the pi has plenty of cooling.
> >
> > that kernel running now is a 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT,
> > but there has since been added another video speedup option, so ATM
> > I am trying to build a 4.19.94-rt38 announced last week. But the git
> > clone I pulled doesn't have the rt patch. And pulling that patch
> > with curl today fails:
> >
> > pi@rpi4:/media/pi/workspace $ curl
> > http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.9
> >4-rt38.patch.xz
>
> Hmm, this seems fine for me:
>  wget
> https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.94.tar.xz 
> tar xf linux-4.19.94.tar.xz
> cd linux-4.19.94/
>  wget
> http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.94-
>rt38.patch.xz 
> unxz patch-4.19.94-rt38.patch.xz 
> patch -p1 < patch-4.19.94-rt38.patch
I blew away my git clone and followed this, which all worked to here, 
but:
>  make ARCH=armhf defconfig

Makefile:527: arch/armhf/Makefile: No such file or directory
make: *** No rule to make target 'arch/armhf/Makefile'.  Stop.

There is an arch/arm/configs/bcm2835_defconfig however, trying several 
variations of that went all aglay:

pi@rpi4:/media/pi/workspace/linux-4.19.94 $ make ARCH=arm/config/bcm2835 
defconfig
Makefile:527: arch/arm/configs/bcm2835/Makefile: No such file or 
directory
make: *** No rule to make target 'arch/arm/congigs/bcm2835/Makefile'.  
Stop.
pi@rpi4:/media/pi/workspace/linux-4.19.94 $ make 
ARCH=arm/bcm2835_defconfig
Makefile:527: arch/arm/bcm2835_defconfig/Makefile: No such file or 
directory
make[1]: *** No rule to make 
target 'arch/arm/bcm2835_defconfig/Makefile'.  Stop.
Makefile:621: include/config/auto.conf.cmd: No such file or directory
make: *** [Makefile:633: include/config/auto.conf.cmd] Error 2
pi@rpi4:/media/pi/workspace/linux-4.19.94 $ make 
ARCH=arm/bcm2835_defconfig defconfig
Makefile:527: arch/arm/bcm2835_defconfig/Makefile: No such file or 
directory
make: *** No rule to make target 'arch/arm/bcm2835_defconfig/Makefile'.  
Stop.

That msg is not explicit enough for my ancient wet ram to go much 
further.

I can pull in the older .config its running on now, but the last time it 
stripped the whole timers menu with all the preempt-rt stuffs out when I 
did a make menuconfig.

So I'll quit putzing and await instructions before I screw it up again.

Thanks Paul
> > > Hope this helps.
> > >
> > > thanks,
> > > Paul
> >
> > I have a recipe that installs to a u-boot already.
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> >  soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > If we desire respect for the law, we must first make the law
> > respectable. - Louis D. Brandeis
> > Genes Web page <http://geneslinuxbox.net:6309/gene>


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

Re: [ANNOUNCE] v5.4.10-rt5

[Paul Thomas]

On Tue, Jan 14, 2020 at 4:04 PM Gene Heskett <gheskett@shentel.net> wrote:
>
> On Tuesday 14 January 2020 12:15:37 Paul Thomas wrote:
>
> > On Tue, Jan 14, 2020 at 11:24 AM Gene Heskett <gheskett@shentel.net>
> wrote:
> > > On Tuesday 14 January 2020 08:54:30 Paul Thomas wrote:
> > > > On Sun, Jan 12, 2020 at 9:44 PM Gene Heskett
> > > > <gheskett@shentel.net>
> > >
> > > wrote:
> > > > > On Friday 10 January 2020 15:14:30 Sebastian Andrzej Siewior
> wrote:
> > > > > > Dear RT folks!
> > > > > >
> > > > > > I'm pleased to announce the v5.4.10-rt5 patch set.
> > > > > >
> > > > > > Changes since v5.4.10-rt4:
> > > > > >
> > > > > >   - Dick Hollenbeck reported that the printk rework had a
> > > > > > negative impact on the 8250 driver if not used as a console.
> > > > > > Patch by John Ogness.
> > > > > >
> > > > > > Known issues
> > > > > >      - None
> > > > > >
> > > > > > The delta patch against v5.4.10-rt4 is appended below and can
> > > > > > be found here:
> > > > > >
> > > > > >
> > > > > > https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/incr/p
> > > > > >atch -5.4 .10-rt4-rt5.patch.xz
> > > > > >
> > > > > > You can get this release via the git tree at:
> > > > > >
> > > > > >
> > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-deve
> > > > > >l.gi t v5.4.10-rt5
> > > > >
> > > > > I grabbed a copy of this, then turned off anything not needed to
> > > > > run LinuxCNC on an rpi4 in armhf config.  Then I noted its make
> > > > > had a make deb-pkg option.  But it isn't making what I told it
> > > > > to make as I'm sitting here watching it ALL go by. Did I miss
> > > > > something in  a make menuconfig that triggered a make all? It
> > > > > was supposedly set for armhf. But I'm even seeing x86 stuff go
> > > > > by. Obviously I know just enough to screw it up. Point me at the
> > > > > right docs for arm builds please.
> > > > >
> > > > > Hi Gene,
> > > >
> > > > I recently stumbled into deb-pkg, and it's awesome building up the
> > > > source and standard debian packages all in one command, but it
> > > > takes the same arguments as a standard make. For rpi4 this is
> > > > arm64 not armhf so you probably want something like below to
> > > > configure for arm64
> > >
> > > armhf (32 bit) runs fine in on an RPI4, been doing it for a couple
> > > months now. With a 32 bit stack frame, context switch latencies are
> > > several microseconds better which linuxcnc loves. However with mesa
> > > interface cards handling all the sub-millisecond stuffs and using
> > > preempt-rt running in userspace, it all works quite well as the  max
> > > latency stays below 200 microseconds 99.99% of the time. Thats well
> > > within the servo-thread time of 1 millisecond the mesa cards need.
> >
> > Ah, makes sense.
> >
> > > > If you are doing this on the rpi4 you don't need the
> > > > CROSS_COMPILE= option.[1][2] make -j4 ARCH=arm64
> > > > CROSS_COMPILE=aarch64-elf- defconfig
> > > > Or if the kernel you're already running has a /proc/config.gz you
> > > > can use that directly (zcat /proc/config.gz > .config).
> > > > Then you can use the main make.
> > >
> > > The kernel I an running was built, by me (queue the raspberry
> > > noises), with only the ondemand governer so while its working, its
> > > stuck in low gear. And the pi has plenty of cooling.
> > >
> > > that kernel running now is a 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT,
> > > but there has since been added another video speedup option, so ATM
> > > I am trying to build a 4.19.94-rt38 announced last week. But the git
> > > clone I pulled doesn't have the rt patch. And pulling that patch
> > > with curl today fails:
> > >
> > > pi@rpi4:/media/pi/workspace $ curl
> > > http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.9
> > >4-rt38.patch.xz
> >
> > Hmm, this seems fine for me:
> >  wget
> > https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.94.tar.xz
> > tar xf linux-4.19.94.tar.xz
> > cd linux-4.19.94/
> >  wget
> > http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19.94-
> >rt38.patch.xz
> > unxz patch-4.19.94-rt38.patch.xz
> > patch -p1 < patch-4.19.94-rt38.patch
> I blew away my git clone and followed this, which all worked to here,
> but:
> >  make ARCH=armhf defconfig
Sorry that was a cut/paste typo, there is no arch/armhf just arm, so you want
make ARCH=arm defconfig
I had tried the command that's why it was in my history and thus the
copy/paste mistake. I believe how this works is the kernel just has
CONFIG_AEABI=y as the ABI config, then userspace compilers have to
decide if they want to compile for a hardware floating point or not,
and what debian has decided is that they would have a special
architecture just for hardfloat:
https://wiki.debian.org/ArmHardFloatPort

thanks,
Paul

Re: [ANNOUNCE] v5.4.10-rt5

[Gene Heskett]

On Tuesday 14 January 2020 16:26:02 Paul Thomas wrote:

> On Tue, Jan 14, 2020 at 4:04 PM Gene Heskett <gheskett@shentel.net> 
wrote:
> > On Tuesday 14 January 2020 12:15:37 Paul Thomas wrote:
> > > On Tue, Jan 14, 2020 at 11:24 AM Gene Heskett
> > > <gheskett@shentel.net>
> >
> > wrote:
> > > > On Tuesday 14 January 2020 08:54:30 Paul Thomas wrote:
> > > > > On Sun, Jan 12, 2020 at 9:44 PM Gene Heskett
> > > > > <gheskett@shentel.net>
> > > >
> > > > wrote:
> > > > > > On Friday 10 January 2020 15:14:30 Sebastian Andrzej Siewior
> >
> > wrote:
> > > > > > > Dear RT folks!
> > > > > > >
> > > > > > > I'm pleased to announce the v5.4.10-rt5 patch set.
> > > > > > >
> > > > > > > Changes since v5.4.10-rt4:
> > > > > > >
> > > > > > >   - Dick Hollenbeck reported that the printk rework had a
> > > > > > > negative impact on the 8250 driver if not used as a
> > > > > > > console. Patch by John Ogness.
> > > > > > >
> > > > > > > Known issues
> > > > > > >      - None
> > > > > > >
> > > > > > > The delta patch against v5.4.10-rt4 is appended below and
> > > > > > > can be found here:
> > > > > > >
> > > > > > >
> > > > > > > https://cdn.kernel.org/pub/linux/kernel/projects/rt/5.4/in
> > > > > > >cr/p atch -5.4 .10-rt4-rt5.patch.xz
> > > > > > >
> > > > > > > You can get this release via the git tree at:
> > > > > > >
> > > > > > >
> > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-
> > > > > > >deve l.gi t v5.4.10-rt5
> > > > > >
> > > > > > I grabbed a copy of this, then turned off anything not
> > > > > > needed to run LinuxCNC on an rpi4 in armhf config.  Then I
> > > > > > noted its make had a make deb-pkg option.  But it isn't
> > > > > > making what I told it to make as I'm sitting here watching
> > > > > > it ALL go by. Did I miss something in  a make menuconfig
> > > > > > that triggered a make all? It was supposedly set for armhf.
> > > > > > But I'm even seeing x86 stuff go by. Obviously I know just
> > > > > > enough to screw it up. Point me at the right docs for arm
> > > > > > builds please.
> > > > > >
> > > > > > Hi Gene,
> > > > >
> > > > > I recently stumbled into deb-pkg, and it's awesome building up
> > > > > the source and standard debian packages all in one command,
> > > > > but it takes the same arguments as a standard make. For rpi4
> > > > > this is arm64 not armhf so you probably want something like
> > > > > below to configure for arm64
> > > >
> > > > armhf (32 bit) runs fine in on an RPI4, been doing it for a
> > > > couple months now. With a 32 bit stack frame, context switch
> > > > latencies are several microseconds better which linuxcnc loves.
> > > > However with mesa interface cards handling all the
> > > > sub-millisecond stuffs and using preempt-rt running in
> > > > userspace, it all works quite well as the  max latency stays
> > > > below 200 microseconds 99.99% of the time. Thats well within the
> > > > servo-thread time of 1 millisecond the mesa cards need.
> > >
> > > Ah, makes sense.
> > >
> > > > > If you are doing this on the rpi4 you don't need the
> > > > > CROSS_COMPILE= option.[1][2] make -j4 ARCH=arm64
> > > > > CROSS_COMPILE=aarch64-elf- defconfig
> > > > > Or if the kernel you're already running has a /proc/config.gz
> > > > > you can use that directly (zcat /proc/config.gz > .config).
> > > > > Then you can use the main make.
> > > >
> > > > The kernel I an running was built, by me (queue the raspberry
> > > > noises), with only the ondemand governer so while its working,
> > > > its stuck in low gear. And the pi has plenty of cooling.
> > > >
> > > > that kernel running now is a 4.19.71-rt24-v7l+ #1 SMP PREEMPT
> > > > RT, but there has since been added another video speedup option,
> > > > so ATM I am trying to build a 4.19.94-rt38 announced last week.
> > > > But the git clone I pulled doesn't have the rt patch. And
> > > > pulling that patch with curl today fails:
> > > >
> > > > pi@rpi4:/media/pi/workspace $ curl
> > > > http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.
> > > >19.9 4-rt38.patch.xz
> > >
> > > Hmm, this seems fine for me:
> > >  wget
> > > https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.94.tar.xz
> > > tar xf linux-4.19.94.tar.xz
> > > cd linux-4.19.94/
> > >  wget
> > > http://www.kernel.org/pub/linux/kernel/projects/rt/4.19/patch-4.19
> > >.94- rt38.patch.xz
> > > unxz patch-4.19.94-rt38.patch.xz
> > > patch -p1 < patch-4.19.94-rt38.patch
> >
> > I blew away my git clone and followed this, which all worked to
> > here,
> >
> > but:
> > >  make ARCH=armhf defconfig
>
That was the fix. make -j4 zImage underway now.

> Sorry that was a cut/paste typo, there is no arch/armhf just arm, so
> you want make ARCH=arm defconfig
> I had tried the command that's why it was in my history and thus the
> copy/paste mistake. I believe how this works is the kernel just has
> CONFIG_AEABI=y as the ABI config, then userspace compilers have to
> decide if they want to compile for a hardware floating point or not,
> and what debian has decided is that they would have a special
> architecture just for hardfloat:
> https://wiki.debian.org/ArmHardFloatPort
>
> thanks,
> Paul

I'll put this on a fresh 64Gig card, that way I'll have a fallback.

Thank you very much Paul.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>