rpi4 new rt kernel no mouse or keyboard, screen has border all around

I've built an rt kernel using the same base as the normal kernel. a 4.19.y, but when booted to it, I have about a 16 pixel border all around the screen that I don't have with a stock kernel.

I have a pair if ssd's attached to a 4 port usb3 hub plugged into a usb3 port. Network is alive and well and I've been working on it over an ssh -Y login.
I started out with two logitech dongles plugged into the usb2 ports, and they are properly identified in the dmesg output, but now I have moved them to the separately powered usb3 hub, and again dmesg seems to show they are found. But the rpi4 ignores them. A snippet from its dmesg:
[ 47.524389] usb 1-1.3: new full-speed USB device number 6 using xhci_hcd
[ 47.665387] usb 1-1.3: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.09
[ 47.665410] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 47.665427] usb 1-1.3: Product: USB Receiver
[ 47.665444] usb 1-1.3: Manufacturer: Logitech
[ 67.711418] usb 1-1.4: USB disconnect, device number 5
[ 73.384593] usb 1-1.4: new full-speed USB device number 7 using xhci_hcd
[ 73.523902] usb 1-1.4: New USB device found, idVendor=3938, idProduct=1032, bcdDevice= 2.03
[ 73.523924] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 73.523942] usb 1-1.4: Product: 2.4G RF Keyboard & Mouse
[ 73.523959] usb 1-1.4: Manufacturer: MOSART Semi.
[ 73.539189] input: MOSART Semi. 2.4G RF Keyboard & Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:3938:1032.0009/input/input6
[ 73.605834] hid-generic 0003:3938:1032.0009: input,hidraw0: USB HID v1.10 Keyboard [MOSART Semi. 2.4G RF Keyboard & Mouse] on usb-0000:01:00.0-1.4/input0
[ 73.620149] input: MOSART Semi. 2.4G RF Keyboard & Mouse Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.1/0003:3938:1032.000A/input/input7
[ 73.620896] input: MOSART Semi. 2.4G RF Keyboard & Mouse Consumer Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.1/0003:3938:1032.000A/input/input8
[ 73.685006] input: MOSART Semi. 2.4G RF Keyboard & Mouse System Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.1/0003:3938:1032.000A/input/input9
[ 73.685387] input: MOSART Semi. 2.4G RF Keyboard & Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.1/0003:3938:1032.000A/input/input11
[ 73.686224] hid-generic 0003:3938:1032.000A: input,hiddev96,hidraw1: USB HID v1.10 Mouse [MOSART Semi. 2.4G RF Keyboard & Mouse] on usb-0000:01:00.0-1.4/input1
[ 83.586098] usb 1-1.3: USB disconnect, device number 6
[ 83.894606] usb 1-1.3: new full-speed USB device number 8 using xhci_hcd
[ 83.994950] usb 1-1.3: device descriptor read/64, error -32
[ 98.214642] usb 1-1.2.1: new full-speed USB device number 9 using xhci_hcd
[ 98.405646] usb 1-1.2.1: New USB device found, idVendor=046d, idProduct=c52b, bcdDevice=12.09
[ 98.405668] usb 1-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 98.405686] usb 1-1.2.1: Product: USB Receiver
[ 98.405702] usb 1-1.2.1: Manufacturer: Logitech
[ 109.189841] usb 1-1.4: USB disconnect, device number 7
[ 115.054656] usb 1-1.2.4: new full-speed USB device number 10 using xhci_hcd
[ 115.244053] usb 1-1.2.4: New USB device found, idVendor=3938, idProduct=1032, bcdDevice= 2.03
[ 115.244075] usb 1-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 115.244093] usb 1-1.2.4: Product: 2.4G RF Keyboard & Mouse
[ 115.244110] usb 1-1.2.4: Manufacturer: MOSART Semi.
[ 115.257053] input: MOSART Semi. 2.4G RF Keyboard & Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.0/0003:3938:1032.000E/input/input12
[ 115.325896] hid-generic 0003:3938:1032.000E: input,hidraw0: USB HID v1.10 Keyboard [MOSART Semi. 2.4G RF Keyboard & Mouse] on usb-0000:01:00.0-1.2.4/input0
[ 115.338390] input: MOSART Semi. 2.4G RF Keyboard & Mouse Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.1/0003:3938:1032.000F/input/input13
[ 115.339146] input: MOSART Semi. 2.4G RF Keyboard & Mouse Consumer Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.1/0003:3938:1032.000F/input/input14
[ 115.405067] input: MOSART Semi. 2.4G RF Keyboard & Mouse System Control as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.1/0003:3938:1032.000F/input/input15
[ 115.405445] input: MOSART Semi. 2.4G RF Keyboard & Mouse as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.4/1-1.2.4:1.1/0003:3938:1032.000F/input/input17
[ 115.406278] hid-generic 0003:3938:1032.000F: input,hiddev96,hidraw1: USB HID v1.10 Mouse [MOSART Semi. 2.4G RF Keyboard & Mouse] on usb-0000:01:00.0-1.2.4/input1

pi@rpi4:~ $ uname -a
Linux rpi4 4.19.71-rt24-v7l+ #1 SMP PREEMPT RT Fri Sep 20 14:17:36 EDT 2019 armv7l GNU/Linux

Anybody have a clue why its failing to be used.

Thanks all.

That is very close to what I did do. The diff is that I didn't install any dtb's because what I built, and the raspbian stuff installed was all the same exact size. I took advantage of a feature of /boot/config.txt I found while reading the forum stuff and copied zImage to kernel-rt, then named it as the kernel to use in config.txt. That way I'm back on a working default kernel with an added # in front of that line in config.txt.

But ATM its not in shape to redo, as I took that big heat sink back off as it interfered with a 40 pin connector to hook it up to the adapter and 26 pin cable to the 7i90HD. Needed about 1/16" wider on both ends, and possible a few thou cleared off behind it. Got it all clamped to the 6040's table, installed a new 4mm tool, fired it up, homed it and was driving it slowly toward the heat sink to modify it when a relay clicked, the overhead light went off above the 6040 and the screen filled up with sserial errors. Since all the electronics to run the 6040 are on a 2x4 shelf suspended from the ceiling, I drug a ladder over to see what was going on, and found the field supply blinking on dimly about once a second, along with the yellow led near the field power on the 7i76.

Shut it all down as it was time to switch hats and fix us some dinner since it was about 19:30 by then. I figure I can find out what went shorted later today. First candidate would be a 1n914 I put on each relay coil for a free wheeling diode since there's about 4 of them switching this and that. But, thinking that thru, thats not a high probability because theres no relays on at all till I enable lcnc. So start by disconnecting the hot side of field power from the 7i76D.

But I've other morning chores first. And I won't overly exert myself until they have installed a new aortic valve in my ticker, its leaky and only pumping about 30%, so I don't have a lot of stamina till then, which is now projected to happen on the 9th of Oct. By which time I'll be 85. Heart attacks, are in the future for all diabetics, dammit. My turn came around.

But I haven't gotten much farther than warming up half a pot of yesterdays coffee & haven't fed the missus yet.
First things first... First is fix the 6040, or move the job to the G0704 & make room for the 40 pin connector. If its the 7i76D, That will take some time to swap, I have spares already but thats also time on a ladder so I may move to the bigger mill. Play it by ear so to speak.


Thanks John

Fixed the field power short, sortof. It got well while I was checking it, and it just ran about 3 hours without a problem. Intermittents, the worst to troubleshoot.

I've had intermittents it took me years to find, John. And when I did find them to be stupid design mistakes, I've had the balls to call the designer of said junk at Chyron and told him the best part of him ran down his mothers leg. In that case, a spare nand gate in a cmos chip was used as an inverter, which is ok, but he only drove one gate. The chip books are overflowing with warnings about floating gates he never read. It worked about 65% of the time.

I've more such stories gathered over nearly 70 years in electronics. But thats your chuckle for today.

I feel your pain. I had an intermittent short that caused z position loss on an old Fanuc machine that took me 10 years to track down. No alarms, errors, or warning and bang z would miss a move and you are screwed. And a lot of very good techs looked at it and could not find the problem. If I had known about Linuxcnc back then it would be running it now instead of the ancient Fanuc 10m that still works fine.

I can nearly beat that. When, decades ago now, CBS tried to automate a 7 meter C-band sat dish, one of the things they bought a few pallets of was PDP-11/23's. All under contract with dec for maintenance. Ours started crashing, and the field techs replaced everything but the frame rail with the seriel number tag on it. But it got worse and worse until it was going away several times a day. And when it went away, we were airing the wrong commercials, which of course we did not get paid for. This hurt the cash cow and eventually the complaints got high enough that Hugo went thru the paperwork to move that maintenance contract to NYC, and he traded me his test mule for mine. Worked fine. But mine ran so poorly for Hugo that he could no longer do any maintenance for the rest of the systems specialty interface boards. About 3 months later I had ups 2 wheeler of boxes from CBS, walked in the front door, 20 minutes after a phone call to tell me it was coming. They had been forced to replace every pdp-11 based field system they had out there. The new system used an industrial rack mounted IBM just to hold and program an ARTIC card that ran the program and was the interface to the rest of the system. They also worked out that there was a private channel to the closed caption stuff, and sent programming up dates over that 99% of the time, and it all Just Worked for the first time in 2 decades.

This is the same CBS that sent me 4 copies of the specs for the base of this 7 meter dish, but only one copy of a mod sheet that listed how far off of true north this 14 yards of concrete was to be dug & poured. So when the dish arrived, along with a crew to install it, was when we found the pad was set to true north. We had to redrill the base flange of the post and re--attach the longitudinal arm that steered it left-right. About a 20 degree correction. That worked well, but the phone line to update the programming had a human on the other end who looked at its satellite tables and decided they were AFU and fixed them. I usually took me about 2 days to find all the birds again. I disconnected the phone line and told them to send me the updates, which I installed from my offices computer, a trs-80 color computer 3, running a vt-220 workalike program.

Some days you are the bird, somedays you are the statue.

BigJohnT wrote:

Gene your always on the bleeding edge, just curious why your not using the SD card?

This worked for me
gnipsel.com/linuxcnc/uspace/rpi4-rt.html

JT

When I get some more of that heat conductive pad stuff the big sink uses, I'll follow this to the T except my card is not ethernet, but spi, a 7i90HD, and since I've also the 7i42TA's for field i/o., is the device-tree now ready for the newest hm2_rpspi.ko driver?

This (stretch raspbian) is working well on a pi3 right now but with glacial video. The buster 10.1 version has video about 40x faster, and I'd love to have that, it would be the icing of the cake. The problem with the rpi4's BIG heat sink it that the heat sink impinges of the size of a 40 pin header connector, needed to connect the spi, requiring that quite a bit of its mounting legs at each end of the connector be machined away to the point of cutting into the screw threads that mount the sink, and the 40 pin header needs a trip to the grinder to shorten it about 3mm. And the rear must be pushed back enough to remove the first fin. So I'd recommend the smaller 3 sink kit and enough fan. Or use a less than 40 pin connector, at risk of misplacing it when plugging it in.

I also have a couple rock64's available, And Alan C. has made to noise about his success with it. but again using an ethernet interface, whereas I'd like to save the net port for regular use, and use the same spi interface as the pi to run the machine. But I haven't seen Alan's step by step yet. Could you post that please Alan? Can I assume you started with the armbian image since raspbian doesn't show one for the rock64's?

Thanks folks.

With the latest (not yet assembled) passive Aluminium headspeader
www.aliexpress.com/item/4000001902776.html
they incuded two female headers for prolongation. So you do not have to cutout the metal )
Mike