Can someone explain how to get the serial ports to work on a beaglebone with the nodeJS resinOS image? I figure the solution is to add something to my Dockerfile. What is it?
My confusion is below:
I have no problems doing this on a beaglebone without resin.os.
There seems to be 2 methods of doing this for a beaglebone: writing to uEnv.txt, or echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots
They don’t work inside the container. COPYing a uEnv.txt into the container (in the dockerfile), does nothing (there is no uEnv.txt in the filesystem anyway), and the result of running the following inside the container: echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots is echo: write error: File exists.
What am I missing here?
Thanks a lot.
More info following, trying to explain, may not make any sense.
echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots
I get the error “echo: write error: file exists” for all UARTS except UART 3. That makes me believe the uEnv.txt file has been processed.
After a “cat slots” inside /sys/devices/platform/bone_capemgr , I saw 6 slots.
I did a “echo -6 slots” , to remove the 6th slot, which worked.
But a subsequent echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots gave me the same write error: file exists.
I still don’t see a ttyO4 or ttyO* inside /dev
Also, I tried using the beaglebone-python image as well as the -node image, same thing.
Any tips?
Thanks a lot.
Hi, we are checking this out. Can you tell us what resinOS version are you running on the device?
v2.0.0+rev4 is that what you mean?
Yes, that’s the one, thanks!
Try ttyS4
instead of ttyO4
.
With your cat slots
did it show an overlay for BB-UART4?
Hi, I was checking it out, and found the following:
The first time I run echo BB-UART4 > /sys/devices/platform/bone_capemgr/slots
, it succeeds fine and triggers capemgr. If I re-running the command after that, I’ll get a echo: write error: file exists
, which indeed shows that the settings are already applied, no need again (until next boot).
I could see the results in the kernel messages using dmesg
, here are the relevant lines:
[ 223.795986] bone_capemgr bone_capemgr: part_number 'BB-UART4', version 'N/A'
[ 223.805436] bone_capemgr bone_capemgr: slot #4: override
[ 223.820155] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 223.831940] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-UART4'
[ 223.861614] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 199, base_baud = 3000000) is a 8250
[ 223.919764] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-UART4-00A0.dtbo' loaded; overlay id #0
Shows that indeed as @fenris says, you need to connect to ttyS4
. Tried it out to communicate over an USB-Serial line, and works.
So I’m guessing you need to run that echo ...
command or something equivalent in your start script. If the error is file exists, then you can just continue with your code, everything is already set up earlier (would happen eg. if you restart the container, but not the whole device).
What do you think?
Thanks a lot! That helps.
I must have screwed something up but I don’t know what. I get a similar output with dmesg -T, except the following line from your output is missing from mine:
[ 223.861614] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 199, base_baud = 3000000) is a 8250
However, if I look in the past of the dmesg logs, I do get that line of output. I am seeing the UARTs when I do a cat slots. I got that to work by removing the universal cape, which was conflicting with the UARTs.
Anyway I’m going to take the easy next step and reflash my beaglebone with a fresh OS, then I believe it should work.
Perfect! Works.
As indicated in the dmesg logs, the path to the serial port is /dev/ttyS* .
Did the same test, put a FTDI into the beaglebone’s USB port and connected to BB serial port. Now I know the ttyUSB0 works too!
Here’s more info in case that helps in the future:
I used the same SD card to reflash the Beaglebone onboard flash. I also used the same resin.io application.
Therefore I believe the problem was introduced in one of my past commits, and didn’t go away with later commits. But as I said above, a fresh install with the same latest commit works fine.
I did swap back and forth to the simple-server-node and the adc-node app (check spelling) using git push -f. I think maybe possibly running the adc app at one time messed things up.
2 Likes
Hi all,
I’m having very similar issues and the solution in this post is not working for me. I’m on a BeagleBone Black running 2.15.1+rev1. When I run BB-UART4 > /sys/devices/platform/bone_capemgr/slots
I get a bunch of journal broadcasts printed on the console.
If I then run echo "test" > /dev/ttyS4
I get an IO error. A check of cat slots reveals:
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O--- -1 Override Board Name,00A0,Override Manuf,BB-UART4
When I check dmesg I see the following. I saw this exact trace on two devices so I’m thinking the NULL pointer error is something to do with capemanager.
CAN device driver interface
[ 1552.223088] bone_capemgr bone_capemgr: part_number 'BB-UART4', version 'N/A'
[ 1552.249059] bone_capemgr bone_capemgr: slot #4: override
[ 1552.259230] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 1552.281559] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-UART4'
[ 1552.304094] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[ 1552.312525] pgd = da60c000
[ 1552.319888] [0000000c] *pgd=9a4ec831, *pte=00000000, *ppte=00000000
[ 1552.328574] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
[ 1552.334016] Modules linked in: ipt_REJECT nf_reject_ipv4 aes_arm_bs crypto_simd cryptd ipt_MASQUERADE nf_nat_masquerade_ipv4 br_netfilter nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo bnep wl18xx wlcore mac80211 cfg80211 hci_uart btqca bluetooth ecdh_generic wlcore_sdio evdev uio_pdrv_genirq uio sch_fq_codel nls_ascii nls_cp437
[ 1552.363717] CPU: 0 PID: 2339 Comm: bash Not tainted 4.14.53+ #2
[ 1552.369663] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 1552.375784] task: da69d680 task.stack: da332000
[ 1552.380358] PC is at __of_overlay_create+0x43c/0xb60
[ 1552.385347] LR is at __of_overlay_create+0x448/0xb60
[ 1552.390332] pc : [<c0aab160>] lr : [<c0aab16c>] psr: 200e0013
[ 1552.396625] sp : da333d58 ip : da530a98 fp : da333dec
[ 1552.401872] r10: 00000000 r9 : c11286dc r8 : dc601e80
[ 1552.407119] r7 : 00000003 r6 : 00000003 r5 : da5bd4c9 r4 : da530a88
[ 1552.413674] r3 : c0aaa398 r2 : 00000000 r1 : 0000002f r0 : 00000000
[ 1552.420232] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 1552.427397] Control: 10c5387d Table: 9a60c019 DAC: 00000051
[ 1552.433169] Process bash (pid: 2339, stack limit = 0xda332218)
[ 1552.439027] Stack: (0xda333d58 to 0xda334000)
[ 1552.443406] 3d40: 00000000 014000c0
[ 1552.451623] 3d60: 00000000 c0cf7108 da333d94 da333d78 c016db38 dc601e84 c1cd3c70 dc601ea0
[ 1552.459840] 3d80: c1c05e08 da333d90 dc601e98 c0d03ee8 da333dac 00000000 c0d03ee8 da5bd000
[ 1552.468057] 3da0: c11b7af4 da333db0 00000010 c0aaa398 da627410 da333e3c 000000a6 e98dcc59
[ 1552.476275] 3dc0: c1c05e08 da627410 00000028 db653418 00000000 c1c05e08 db653418 c115bdf0
[ 1552.484493] 3de0: da333dfc da333df0 c0aab8a4 c0aaad30 da333e74 da333e00 c0882230 c0aab890
[ 1552.492709] 3e00: 00000002 da333e10 c039607c c0882f24 00000000 c1c05e08 db653420 00000003
[ 1552.500926] 3e20: dc23b410 00000003 db653410 da5bd000 da62765b dc23b410 dc23b410 e0ceb0c8
[ 1552.509144] 3e40: c0850d94 e98dcc59 da333e70 da68f600 c1c05e08 db653410 da68f080 dc23b410
[ 1552.517361] 3e60: 00000000 da627410 da333eb4 da333e78 c08833a4 c0881dbc 00000000 c0197d80
[ 1552.525578] 3e80: c1c05e08 e98dcc59 0000000a c0883254 da49fb80 00000000 00000000 da333f68
[ 1552.533796] 3ea0: da68f080 da49fb90 da333ecc da333eb8 c084f1e8 c0883260 c084f1c0 da49fb80
[ 1552.542013] 3ec0: da333ee4 da333ed0 c0394cf8 c084f1cc 00000009 da49fb80 da333f1c da333ee8
[ 1552.550230] 3ee0: c0394344 c0394cb4 00000000 00000000 db66ed88 c039424c db1ed000 005daa08
[ 1552.558448] 3f00: da333f68 00000000 005daa08 00000009 da333f34 da333f20 c0308a14 c0394258
[ 1552.566665] 3f20: 00000009 db1ed000 da333f64 da333f38 c0308bf8 c03089f8 c0207f50 c032b3a0
[ 1552.574882] 3f40: c1c05e08 db1ed000 00000000 00000000 db1ed000 005daa08 da333fa4 da333f68
[ 1552.583099] 3f60: c0308e60 c0308b50 00000000 00000000 da333fa4 e98dcc59 c010ba34 00000009
[ 1552.591317] 3f80: 005daa08 b6e9fb50 00000004 c01090e4 da332000 00000020 00000000 da333fa8
[ 1552.599534] 3fa0: c01090c0 c0308e10 00000009 005daa08 00000001 005daa08 00000009 00000000
[ 1552.607750] 3fc0: 00000009 005daa08 b6e9fb50 00000004 00000009 00000000 000c5758 00000000
[ 1552.615967] 3fe0: 00000000 beb8a5f4 b6e02c85 b6e3df26 400e0030 00000001 9fde6861 9fde6c61
[ 1552.624203] [<c0aab160>] (__of_overlay_create) from [<c0aab8a4>] (of_overlay_create+0x20/0x24)
[ 1552.632872] [<c0aab8a4>] (of_overlay_create) from [<c0882230>] (capemgr_load_slot+0x480/0x5d0)
[ 1552.641532] [<c0882230>] (capemgr_load_slot) from [<c08833a4>] (slots_store+0x150/0x328)
[ 1552.649672] [<c08833a4>] (slots_store) from [<c084f1e8>] (dev_attr_store+0x28/0x34)
[ 1552.657373] [<c084f1e8>] (dev_attr_store) from [<c0394cf8>] (sysfs_kf_write+0x50/0x54)
[ 1552.665332] [<c0394cf8>] (sysfs_kf_write) from [<c0394344>] (kernfs_fop_write+0xf8/0x1d4)
[ 1552.673555] [<c0394344>] (kernfs_fop_write) from [<c0308a14>] (__vfs_write+0x28/0x48)
[ 1552.681426] [<c0308a14>] (__vfs_write) from [<c0308bf8>] (vfs_write+0xb4/0x1c0)
[ 1552.688773] [<c0308bf8>] (vfs_write) from [<c0308e60>] (SyS_write+0x5c/0xbc)
[ 1552.695867] [<c0308e60>] (SyS_write) from [<c01090c0>] (__sys_trace_return+0x0/0x10)
[ 1552.703651] Code: e584902c e5843034 e584403c e584a028 (e590500c)
[ 1552.729554] ---[ end trace a38642589a40878e ]---
If I run BB-UART4 > /sys/devices/platform/bone_capemgr/slots
again the command hangs indefinitely. On device restart it also seems to prevent the container from starting again.
In the end I’m trying to use the Bonescript library for serial control, but I figured I would start here to get it working first. Any help is greatly appreciated!
Relevant journal broadcasts:
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.270736] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.375332] Process bash (pid: 1558, stack limit = 0xda72c218)
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.381191] Stack: (0xda72dd58 to 0xda72e000)
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.385568] dd40: 00000000 014000c0
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.393785] dd60: 00000000 c0cf7108 da72dd94 da72dd78 c016db38 dc10ff84 c1cd3c70 dc10ffa0
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.402003] dd80: c1c05e08 da72dd90 dc10ff98 c0d03ee8 da72ddac 00000000 c0d03ee8 da693000
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.410221] dda0: c11b7af4 da72ddb0 00000010 c0aaa398 da5fec10 da72de3c 000000a6 e98dcc59
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.418438] ddc0: c1c05e08 da5fec10 00000028 db653218 00000000 c1c05e08 db653218 c115bdf0
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.426655] dde0: da72ddfc da72ddf0 c0aab8a4 c0aaad30 da72de74 da72de00 c0882230 c0aab890
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.434871] de00: 00000002 da72de10 c039607c c0882f24 00000000 c1c05e08 db653220 00000003
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.443088] de20: dc23b410 00000003 db653210 da693000 da5fee5b dc23b410 dc23b410 e0ccb0c8
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.451306] de40: c0850d94 e98dcc59 da72de70 dc5c94c0 c1c05e08 db653210 dc5c9700 dc23b410
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.459523] de60: 00000000 da5fec10 da72deb4 da72de78 c08833a4 c0881dbc 00000000 c0197d80
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.467741] de80: c1c05e08 e98dcc59 0000000a c0883254 da4e7380 00000000 00000000 da72df68
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.475958] dea0: dc5c9700 da4e7390 da72decc da72deb8 c084f1e8 c0883260 c084f1c0 da4e7380
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.484176] dec0: da72dee4 da72ded0 c0394cf8 c084f1cc 00000009 da4e7380 da72df1c da72dee8
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.492392] dee0: c0394344 c0394cb4 00000000 00000000 db66e588 c039424c da5bf240 00be5a08
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.500610] df00: da72df68 00000000 00be5a08 00000009 da72df34 da72df20 c0308a14 c0394258
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.508826] df20: 00000009 da5bf240 da72df64 da72df38 c0308bf8 c03089f8 c0207f50 c032b3a0
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.517043] df40: c1c05e08 da5bf240 00000000 00000000 da5bf240 00be5a08 da72dfa4 da72df68
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.525260] df60: c0308e60 c0308b50 00000000 00000000 da72dfa4 e98dcc59 c010ba34 00000009
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.533476] df80: 00be5a08 b6f3ab50 00000004 c01090e4 da72c000 00000020 00000000 da72dfa8
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.541693] dfa0: c01090c0 c0308e10 00000009 00be5a08 00000001 00be5a08 00000009 00000000
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.549911] dfc0: 00000009 00be5a08 b6f3ab50 00000004 00000009 00000000 000c5758 00000000
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.558127] dfe0: 00000000 bea115f4 b6e9dc85 b6ed8f26 400e0030 00000001 00000000 00000000
Broadcast message from systemd-journald@14f4739 (Fri 2018-10-05 00:39:06 UTC):
kernel[575]: [ 458.645809] Code: e584902c e5843034 e584403c e584a028 (e590500c)
I’m having the exact same problem with 2.15.1+rev1 on a Beaglebone Black. Any attempt to echo an overlay to a slot results in the same error. I’ve tried BB-W1-P9.12 and BB-I2C1 with the same results.
[ 54.133885] udevd[26]: starting version 3.2.4
[ 54.242373] udevd[27]: starting eudev-3.2.4
[ 56.408448] bone_capemgr bone_capemgr: part_number 'BB-W1-P9.12', version 'N/A'
[ 56.598546] bone_capemgr bone_capemgr: slot #4: override
[ 56.636911] bone_capemgr bone_capemgr: Using override eeprom data at slot 4
[ 56.668778] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-W1-P9.12'
[ 56.767535] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[ 56.934124] pgd = da504000
[ 56.981717] [0000000c] *pgd=00000000
[ 57.048988] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 57.054349] Modules linked in: aes_arm_bs crypto_simd cryptd ipt_MASQUERADE nf_nat_masquerade_ipv4 br_netfilter nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211 evdev uio_pdrv_genirq uio nls_ascii nls_cp437 sch_fq_codel
[ 57.079406] CPU: 0 PID: 1145 Comm: bash Not tainted 4.14.53+ #2
[ 57.085352] Hardware name: Generic AM33XX (Flattened Device Tree)
[ 57.091474] task: da42d680 task.stack: db360000
[ 57.096049] PC is at __of_overlay_create+0x43c/0xb60
[ 57.101037] LR is at __of_overlay_create+0x448/0xb60
[ 57.106023] pc : [<c0aab160>] lr : [<c0aab16c>] psr: 20010113
[ 57.112315] sp : db361cc0 ip : da403498 fp : db361d54
[ 57.117561] r10: 00000000 r9 : c11286dc r8 : dc7de800
[ 57.122808] r7 : 00000003 r6 : 00000003 r5 : da4174c9 r4 : da403488
[ 57.129363] r3 : c0aaa398 r2 : 00000000 r1 : 0000002f r0 : 00000000
[ 57.135920] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 57.143087] Control: 10c5387d Table: 9a504019 DAC: 00000051
[ 57.148858] Process bash (pid: 1145, stack limit = 0xdb360218)
[ 57.154715] Stack: (0xdb361cc0 to 0xdb362000)
[ 57.159096] 1cc0: 00000000 014000c0 00000000 c0cf7108 db361cfc db361ce0 c016db38 dc7de804
[ 57.167314] 1ce0: c1cd3c70 dc7de820 c1c05e08 db361cf8 dc7de818 c0d03ee8 db361d14 00000000
[ 57.175531] 1d00: c0d03ee8 da417000 c11b7af4 db361d18 00000010 c0aaa398 da4a1c10 e0a5216c
[ 57.183748] 1d20: 00000097 d700b7f6 c1c05e08 da4a1c10 00000028 db689a18 00000000 c1c05e08
[ 57.191965] 1d40: db689a18 c115bdf0 db361d64 db361d58 c0aab8a4 c0aaad30 db361ddc db361d68
[ 57.200182] 1d60: c0882230 c0aab890 00000000 db361d78 c039607c c0882f24 00000000 c1c05e08
[ 57.208399] 1d80: db689a20 00000001 dc23c410 00000001 db689a10 da417000 da4a1e5b dc23c410
[ 57.216616] 1da0: c02f26e8 e0a520bc 00000001 d700b7f6 db361dd8 db313600 c1c05e08 db689a10
[ 57.224833] 1dc0: db3130c0 dc23c410 00000000 da4a1c10 db361e1c db361de0 c08833a4 c0881dbc
[ 57.233049] 1de0: 00000000 db319840 db361e8c d700b7f6 c031808c c0883254 dc7de380 00000000
[ 57.241266] 1e00: 00000000 db361f58 db3130c0 dc7de390 db361e34 db361e20 c084f1e8 c0883260
[ 57.249483] 1e20: c084f1c0 dc7de380 db361e4c db361e38 c0394cf8 c084f1cc 0000000b dc7de380
[ 57.257699] 1e40: db361e84 db361e50 c0394344 c0394cb4 00000000 00000000 db361ec4 db319840
[ 57.265916] 1e60: 0000000b db361ec4 00000000 db361f58 c039424c bebb37b0 db361eb4 db361e88
[ 57.274133] 1e80: c0307cf8 c0394258 db361eb4 db361e98 c1c05e08 db319840 00000000 db361ec4
[ 57.282350] 1ea0: db361f58 00000000 db361f44 db361eb8 c0307de4 c0307ba0 db361ec0 db361ec4
[ 57.290567] 1ec0: 00000000 00000001 00000000 0000000c db361edc 00000002 c032b48c b6f67c7f
[ 57.298784] 1ee0: 0000000b bebb37e7 00000001 00000000 db3550c0 c0304df0 00000000 db3550c0
[ 57.307002] 1f00: db361f2c db361f10 c0304df0 c03131c4 00000001 db323c00 db3550c0 d700b7f6
[ 57.315218] 1f20: db361f44 c1c05e08 db319840 db319840 00000000 00000000 db361f94 db361f48
[ 57.323434] 1f40: c0307ebc c0307d70 00000000 00000020 db361f8c 00000002 00000000 00000000
[ 57.331652] 1f60: 00000092 d700b7f6 00000092 b6f66120 bebb37b0 0000000c 00000092 c01090e4
[ 57.339869] 1f80: db360000 00000020 db361fa4 db361f98 c03094a4 c0307e54 00000000 db361fa8
[ 57.348087] 1fa0: c01090c0 c0309494 b6f66120 bebb37b0 00000001 bebb37b0 00000002 b6f67c7f
[ 57.356304] 1fc0: b6f66120 bebb37b0 0000000c 00000092 00000001 00000002 00000092 bebb3810
[ 57.364521] 1fe0: 004de768 bebb37b0 b6f15588 b6f157f8 60000010 00000001 00000000 00000000
[ 57.372757] [<c0aab160>] (__of_overlay_create) from [<c0aab8a4>] (of_overlay_create+0x20/0x24)
[ 57.381427] [<c0aab8a4>] (of_overlay_create) from [<c0882230>] (capemgr_load_slot+0x480/0x5d0)
[ 57.390086] [<c0882230>] (capemgr_load_slot) from [<c08833a4>] (slots_store+0x150/0x328)
[ 57.398225] [<c08833a4>] (slots_store) from [<c084f1e8>] (dev_attr_store+0x28/0x34)
[ 57.405926] [<c084f1e8>] (dev_attr_store) from [<c0394cf8>] (sysfs_kf_write+0x50/0x54)
[ 57.413884] [<c0394cf8>] (sysfs_kf_write) from [<c0394344>] (kernfs_fop_write+0xf8/0x1d4)
[ 57.422107] [<c0394344>] (kernfs_fop_write) from [<c0307cf8>] (do_iter_write+0x164/0x19c)
[ 57.430327] [<c0307cf8>] (do_iter_write) from [<c0307de4>] (vfs_writev+0x80/0xe4)
[ 57.437847] [<c0307de4>] (vfs_writev) from [<c0307ebc>] (do_writev+0x74/0x110)
[ 57.445106] [<c0307ebc>] (do_writev) from [<c03094a4>] (SyS_writev+0x1c/0x20)
[ 57.452288] [<c03094a4>] (SyS_writev) from [<c01090c0>] (__sys_trace_return+0x0/0x10)
[ 57.460161] Code: e584902c e5843034 e584403c e584a028 (e590500c)
[ 59.026534] ---[ end trace 4e745bc7b5b22dc4 ]---
I’m wondering if it has to do with the move to use U-Boot overlays instead of capemgr (https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays ). The version of U-Boot (2017.01) included in 2.15 seems to be old enough such that it doesn’t have load the overlays. I attempted to use the U-Boot overlays as described in the official docs but the overlays don’t seem to load. This is what I have in uEnv.txt
and what ends up in /proc/cmdline
root@b3ea527:~# ls /dev/i2c*
/dev/i2c-0 /dev/i2c-2
root@b3ea527:~# cat /proc/cmdline
console=ttyO0,115200n8 root=PARTUUID=ea80bed7-02 rootfstype=ext4 rootwait
root@b3ea527:~# cat /mnt/boot/uEnv.txt
enable_uboot_overlays=1
disable_uboot_overlay_video=1
uboot_overlay_addr0=/lib/firmware/BB-W1-P9.12-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-I2C1-00A0.dtbo
At this point going back to 2.12 seems like the only viable option.
Any help would be appreciated.
xginn8
November 8, 2018, 10:07pm
17
Hi @idahoakl –
The kernel oops you have noted appears to be from capemgr
, which is in the process of deprecation upstream in the Beaglebone linux fork , in favor of u-boot
. As you noted, u-boot
was available in previous versions of the OS. We are tracking the fix for that here .
gelbal
January 23, 2019, 2:08pm
27
Hello everyone,
This issue is fixed by the version v2.29.2.
Cheers…
gelbal
January 23, 2019, 2:09pm
28
Hello everyone,
This issue is fixed by the version v2.29.2.
Cheers…