-
Notifications
You must be signed in to change notification settings - Fork 563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot configure OneWire or UART for on bone-debian-9.5-iot #204
Comments
@kwijbrans , okay you have an issue another user posted a few week back.. So verison.sh is only detecting the version of u-boot on teh microSD drive:
and from the cmdline, we see a special flag isn't being passed..
Thus, you have "something" on the eMMC, can you please figure that out and share with me the "flasher" that programmed your eMMC? Then i can update version.sh to detect this issue and report it for the next user. (Technically you are the "2nd" user, but the "1st" user with this issue couln't remember anything..) Regards, |
@RobertCNelson: Unfortunately, I do not know the flasher that was used previously, this is a system that was configured to also use a harddisk and the harddisk crashed. Trying to get it up and running again. Is the eMMC on /dev/mmcblk1 when booted from the SD? I have dumped the first 4 MB using dd if=/dev/mmcblk1, would this be of use? |
One addition: I zeroed the eMMC with sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10 and now it works. |
@kwijbrans yeah, if you can send me the 4MB *.img i'll do some work on debugging what it was. ;) |
@RobertCNelson: attached the dump of the first 4 MB, hope it helps finding the issue. |
I may be having the same problem so I'm posting several items below. I'm also a relatively newbie to BBB and trying to get a DS18B20 temperature sensor working with 1-wire. Here is the output from version.sh (this was booted from an SD card). git:/opt/scripts/:[1aa73453b2c980b75e31e83dab7dd8b6696f10c7] Here is my uEnv.txt file. #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=4.14.71-ti-r80 ###U-Boot Overlays### ###Overide capes with eeprom ###Additional custom capes ###Custom Cape ###Disable auto loading of virtual capes (emmc/video/wireless/adc) ###PRUSS OPTIONS ###Cape Universal Enable ###Debug: disable uboot autoload of Cape ###U-Boot fdt tweaks... (60000 = 384KB) cmdline=coherent_pool=1M net.ifnames=0 quiet #In the event of edid real failures, uncomment this next line: #Use an overlayfs on top of a read-only root filesystem: ##enable Generic eMMC Flasher: So I booted by holding down the user button while pressing power on. I executed the two sudo modprobe commands with no errors report. All I see in /sys/bus/w1/devices is w1_bus_master1 Suggestions? |
@kwangwoo74 Please try with our current Debian image: |
icss_iep_perout_enable_hw() is invoked with spin_lock_irqsave() and hence cannot use sleeping lock. Enable regmap fast_io for iep_regmap_config so that it will use spinlock instead of mutex. This fixes the following dump BUG: sleeping function called from invalid context at kernel/locking/mutex.c:947 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1103, name: sh 5 locks held by sh/1103: #0: ffff00002b814438 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x6c/0xf8 #1: ffff0000322ae888 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf0/0x1b8 #2: ffff0000744837d0 (kn->active#158){++++}-{0:0}, at: kernfs_fop_write_iter+0xf8/0x1b8 #3: ffff0000344401b8 (&iep->ptp_clk_mutex){+.+.}-{3:3}, at: icss_iep_ptp_enable+0x168/0x2f0 [icss_iep] #4: ffff0000344401f8 (&iep->irq_lock){....}-{2:2}, at: icss_iep_ptp_enable+0x19c/0x2f0 [icss_iep] irq event stamp: 92858 hardirqs last enabled at (92857): [<ffff800010cbefa0>] _raw_spin_unlock_irqrestore+0x80/0x98 hardirqs last disabled at (92858): [<ffff800010cbf660>] _raw_spin_lock_irqsave+0xb0/0x144 softirqs last enabled at (92658): [<ffff80001001062c>] efi_header_end+0x62c/0x6b0 softirqs last disabled at (92645): [<ffff80001005993c>] irq_exit+0x1c4/0x1d8 Preemption disabled at: [<ffff800009491484>] icss_iep_ptp_enable+0x19c/0x2f0 [icss_iep] CPU: 1 PID: 1103 Comm: sh Not tainted 5.10.65-08510-g2bea885230fd-dirty #204 Hardware name: Texas Instruments AM642 EVM (DT) Call trace: dump_backtrace+0x0/0x1d0 show_stack+0x18/0x28 dump_stack+0xec/0x154 ___might_sleep+0x194/0x240 __might_sleep+0x50/0x88 __mutex_lock+0x5c/0x900 mutex_lock_nested+0x34/0x50 regmap_lock_mutex+0x14/0x20 regmap_write+0x3c/0x78 icss_iep_perout_enable_hw+0xd0/0x2c0 [icss_iep] icss_iep_ptp_enable+0x2b4/0x2f0 [icss_iep] pps_enable_store+0xc0/0xe0 dev_attr_store+0x18/0x30 sysfs_kf_write+0x4c/0x78 kernfs_fop_write_iter+0x120/0x1b8 new_sync_write+0xe8/0x188 vfs_write+0x2ac/0x450 ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 el0_svc_common.constprop.0+0x7c/0x1f0 do_el0_svc+0x24/0x90 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb8 el0_sync+0x180/0x1c0 ============================= [ BUG: Invalid wait context ] 5.10.65-08510-g2bea885230fd-dirty #204 Tainted: G W ----------------------------- sh/1103 is trying to lock: ffff000034440468 (icss_iep:959:(iep->plat_data->config)->lock){+.+.}-{3:3}, at: regmap_lock_mutex+0x14/0x20 other info that might help us debug this: context-{4:4} 5 locks held by sh/1103: #0: ffff00002b814438 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x6c/0xf8 #1: ffff0000322ae888 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf0/0x1b8 #2: ffff0000744837d0 (kn->active#158){++++}-{0:0}, at: kernfs_fop_write_iter+0xf8/0x1b8 #3: ffff0000344401b8 (&iep->ptp_clk_mutex){+.+.}-{3:3}, at: icss_iep_ptp_enable+0x168/0x2f0 [icss_iep] #4: ffff0000344401f8 (&iep->irq_lock){....}-{2:2}, at: icss_iep_ptp_enable+0x19c/0x2f0 [icss_iep] stack backtrace: CPU: 1 PID: 1103 Comm: sh Tainted: G W 5.10.65-08510-g2bea885230fd-dirty #204 Hardware name: Texas Instruments AM642 EVM (DT) Call trace: dump_backtrace+0x0/0x1d0 show_stack+0x18/0x28 dump_stack+0xec/0x154 __lock_acquire+0x1d38/0x1d60 lock_acquire+0x154/0x410 __mutex_lock+0x9c/0x900 mutex_lock_nested+0x34/0x50 regmap_lock_mutex+0x14/0x20 regmap_write+0x3c/0x78 icss_iep_perout_enable_hw+0xd0/0x2c0 [icss_iep] icss_iep_ptp_enable+0x2b4/0x2f0 [icss_iep] pps_enable_store+0xc0/0xe0 dev_attr_store+0x18/0x30 sysfs_kf_write+0x4c/0x78 kernfs_fop_write_iter+0x120/0x1b8 new_sync_write+0xe8/0x188 vfs_write+0x2ac/0x450 ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 el0_svc_common.constprop.0+0x7c/0x1f0 do_el0_svc+0x24/0x90 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb8 el0_sync+0x180/0x1c0 Fixes: 5d58df8 ("net: ethernet: ti: icss_iep: fix pps irq race vs pps disable") Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Vignesh Raghavendra <[email protected]>
I am trying to get my BBB to work with a OneWire interface a P9.12 and UART4 enabled. Added uboot_overlay_addr0=/lib/firmware/BB-UART4-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-W1-P9.12-00A0.dtbo
Somehow, it does not work: I do not see any devices on the OneWire bus even though two were present when I used Debian Jessie, and I do not see the UART4 device /dev/ttyO4.
sudo /opt/scripts/tools/version.sh gives:
What can be wrong? Output seems very similar to output of the working configuration in issue #142.
The text was updated successfully, but these errors were encountered: