-
Notifications
You must be signed in to change notification settings - Fork 103
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
"edma 49000000.edma: Entry slot allocation failed for channel 0" in 4.4.x-bone-rt kernels #42
Comments
can you replicate the issue on 4.4.x when using cape overlays: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays (kernel overlays are to error prone, specially with clock sub-systems) Regards, |
U-Boot overlays seem to be a very new feature. Is this really less error prone than using the cape_enable option in /boot/uEnv.txt? Currently, I am loading the overlay on demand using cape manager. I will check if this is the problem. |
it's about a month/2 months old for us. (u-boot got in in v2016.11). It's less error prone then kernel overlays, as you don't fight kernel races. |
Thanks, that's good to know. Meanwhile I have tested 4.4.55-ti-rt-r94 and it works as expected when loading on demand using cape manager or via the cape_enable option in uEnv.txt. When using the cape_enable option in uEnv.txt under 4.4.59-bone-rt-r17 nothing changes. Except that there is no kernel crash. I did the following tests with cape_eable=BB-UART1,BB-UART2,BB-BONE-LOGIBONE: 4.4.59-bone-rt-r17: Loading via uEnv.txt/ cape_enable 4.4.59-bone-rt-r17: Loading on demand 4.4.55-ti-rt-r94: Loading via uEnv.txt/ cape_enable 4.4.55-ti-rt-r94: Loading on demand It is really strange that the ti kernel reports pin 97 as conflicting but works whereas the bone kernel reports pin 85 as conflicting and fails. There are obviously differences in the default device tree configuration between the two kernels. |
Following are the conflicting addresses: The bone kernel loads 2 spi related modules whereas the ti kernel does not. This might be the culprit. |
After removing /lib/modules/4.4.59-bone-rt-r17/kernel/drivers/spi/spi-omap2-mcspi.ko the pinmux problems are gone but there's still "bone_capemgr bone_capemgr: loader: failed to load slot-7 BB-BONE-LOGIBONE:00A0 (prio 0)" when using the cape_enable option in uEnv.txt. Update: The loader error is now gone by adding ":00A3" to the cape_enable line. There are now no warnings/errors during boot. However, the original problems is still there. After the first write operation to /dev/logibone_mem, the last thing I can see in terminal is "Entry slot allocation failed for channel 0". |
Is there any news on this topic? Would it be better to move the issue to https://github.com/beagleboard/linux? |
Sorry @QuickJack day job and home life have been keeping me occupied, haven't had much free time for kernel hacking. You can submit there, but it'll still get routed to me. Any luck with using U-Boot overlays? Regards, |
I am using U-Boot 2017.03-rc3-00002-g16d7481d17 and kernel 4.4.59-bone-rt-r17. I made the following changes in uEnv.txt:
However, U-Boot doesn't report that it loads the overlay. Indeed cape manager doesn't report the cape as beeing present during booting. By the way, I am currently not using the cape eeprom feature as it complicates things even further. |
make sure you don't have "/uEnv.txt" in the way, u-boot just needs to load /boot/uEnv.txt if you copy your serial log we can debug it too Regards, |
The eMMC needs to be disabled when using the Logibone. I pressed the S2 switch to force booting via the SDCard which contains an up to date version of U-Boot. I also renamed /uEnv.txt. Now, the dtbo for the Logibone is loaded. But there are lots of FDT_ERR_ messages. I do not understand why U-Boot tries to load all theses strange overlays. The system does not boot as expected. Following is the boot log:
|
sorry about this:
i thought i had back-ported the dtc changes i needed to make that work. 4.4.60-bone17 = broken I'm now taking a look at the patch diff between 4.4.60-bone17 / 4.4.59-ti-r96 to see what i missed. Regards, |
I have now debugged the driver code using kernel 4.4.61-bone-rt-r17. When calling dma_request_channel() a valid channel (4 in my case) is returned. However there‘s the „edma 49000000.edma: Entry slot allocation failed for channel 0“ message in dmesg. Channel allocation doesn't seem to work correctly. This problem is present in 4.4.x-bone kernels only. The relevant code fragment is as follows:
|
Is there any progress on this issue? |
@QuickJack u-boot overlays are fixed in: 4.4.64-bone17/4.4.64-bone-rt-r17 |
Thanks for you work regarding the u-boot overlays. I have just tested 4.4.65-bone-rt-r17. The error „edma 49000000.edma: Entry slot allocation failed for channel 0“ still exists. I doubt that it will vanish when using u-boot overlays. The same kernel module does work on any other kernel I have tested. The problem is present in the 4.4.x-bone kernels only. I did a quick test of u-boot overlays and this is part of the boot log:
It is trying to load BB-HDMI-TDA998x-00A0.dtbo and BB-BONE-eMMC1-01-00A0.dtbo. I few lines above it says that it's loading am335x-boneblack-overlay.dtb which should ignore HDMI/ eMMC. The Logibone does not work if HDMI/ eMMC is enabled. What is going on here? |
OK, I activated the following additional options:
We can see that am335x-boneblack-overlay.dtb is ignored in some way. This is a bit confusing. After adding the above options, u-boot is working as expected. However, there a lots of problems during boot. The system seems to get very laggy and hangs at "[ OK ] Reached target Login Prompts.". Following is my boot log:
|
This problem occurs on the BBB when calling dma_request_channel(). I am using this driver https://github.com/fpga-logi/logi-kernel. When doing a write operation on /dev/logibone_mem, the system hangs (kernel crash?).
The same driver works on 4.1.x-bone-rt and 4.8.x-bone-rt without issues.
The text was updated successfully, but these errors were encountered: