Segmentation fault
Opened this issue · 24 comments
need help,
when insmod opencores-i2s a segmentation fault accures:
here is the output:
insmod snd-soc-opencores-i2s.ko
opencores_i2s at f00f4000
Unhandled fault: imprecise external abort (0x406) at 0xbf000000
Internal error: : 406 [#1] SMP ARM
Modules linked in: snd_soc_opencores_i2s(O+)
CPU: 1 PID: 83 Comm: insmod Tainted: G O 3.17.0-00210-g9d03095-dirty #29
task: ee4e9c80 ti: ee4ee000 task.ti: ee4ee000
PC is at regmap_mmio_read+0x108/0x124
LR is at _regmap_raw_read+0xc4/0x1d0
pc : [] lr : [] psr: 60000093
sp : ee4efbd8 ip : ee4efc00 fp : ee4efbfc
r10: 00000004 r9 : c0877150 r8 : ee550a80
r7 : 00000004 r6 : ee550a80 r5 : ee550a00 r4 : 00000004
r3 : f00f4004 r2 : 00000000 r1 : 00000004 r0 : ffffffed
Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 2e4c804a DAC: 00000015
Process insmod (pid: 83, stack limit = 0xee4ee248)
Stack: (0xee4efbd8 to 0xee4f0000)
fbc0: ee550a80 ee4c3800
fbe0: 00000000 eee04610 00000004 eedb1840 ee4efc44 ee4efc00 c034b014 c03502d4
fc00: 00000004 00000000 c0419720 c0597bc0 ee550a80 00000004 eee04610 ee4c3800
fc20: 00000004 ee4efcbc ee4efcbc eedb1840 00000000 ee4ee000 ee4efc64 ee4efc48
fc40: c034b470 c034af5c c034b43c ee4c3800 00000004 ee4c3800 ee4efc94 ee4efc68
fc60: c034aa00 c034b448 c0349698 ee4c3800 00000004 ee4efcbc bf001270 eedb1840
fc80: 00000000 ee4ee000 ee4efcb4 ee4efc98 c034ab18 c034a990 ff200000 eee04610
fca0: ee438c10 00000004 ee4efce4 ee4efcb8 bf0007c0 c034aad4 bf00122c eee04610
fcc0: bf00122c eee04610 bf00122c c0879080 bf00122c 00000005 ee4efcfc ee4efce8
fce0: c033c7dc bf000600 eee04610 c08ee6e0 ee4efd2c ee4efd00 c033abc0 c033c7ac
fd00: ee4efd2c ee4efd10 eee04610 bf00122c eee04644 00000000 bf003000 ee4ee000
fd20: ee4efd4c ee4efd30 c033af20 c033ab24 eec3e65c 00000000 bf00122c c033ae84
fd40: ee4efd74 ee4efd50 c0338ed4 c033ae90 eec3e65c eedad9b4 eec3e670 bf00122c
fd60: ee44cf80 c0859148 ee4efd84 ee4efd78 c033a624 c0338e7c ee4efdac ee4efd88
fd80: c033a20c c033a604 bf001028 ee4efd98 bf00122c c083db98 ee5507c0 ee5506c0
fda0: ee4efdc4 ee4efdb0 c033b7c4 c033a120 c083db98 c083db98 ee4efdd4 ee4efdc8
fdc0: c033c6d8 c033b748 ee4efde4 ee4efdd8 bf003018 c033c68c ee4efe7c ee4efde8
fde0: c0008944 bf00300c ef7d3660 00000000 00000000 0000002d ee4a5840 c01057f4
fe00: 000006e1 00000001 bf0013f0 c00863e0 ee4efe44 ee4efe20 c0111280 c0591b2c
fe20: 0000002d ee4a5840 f0111000 00000001 00000001 c00863e0 ee4efe64 ee4efe48
fe40: c01057f4 c0111188 ee4eff48 00000001 bf0013fc ee4eff48 00000001 bf0013fc
fe60: ee5506c0 00000001 bf0013f0 c00863e0 ee4eff3c ee4efe80 c0088f68 c0008890
fe80: bf0013fc 00007fff c008685c 000000d2 ee4a5840 f0111000 00000000 bf0013fc
fea0: 00000000 ee4efed4 0001d948 ee4ee000 bf001438 bf001558 ee4eff04 00001b02
fec0: ee4effa4 ee4efed0 c0013b58 c000846c f0133000 00000000 00000000 00000000
fee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ff00: 00000000 00000000 00000000 00000000 20000013 0002c5aa b6e0e000 0001d948
ff20: 00000080 c000f8e4 ee4ee000 00000000 ee4effa4 ee4eff40 c0089884 c0087718
ff40: 0000c009 00000000 f0111000 0002c5aa f0131f38 f0131d55 f013d018 00001568
ff60: 00001708 bf001270 00000010 00000000 00000030 00000031 00000018 00000000
ff80: 0000000f 00000000 00000000 00028d10 b6e0e000 00028060 00000000 ee4effa8
ffa0: c000f6c0 c00897dc 00028d10 b6e0e000 b6e0e000 0002c5aa 0001d948 00028da8
ffc0: 00028d10 b6e0e000 00028060 00000080 00000002 bef21d98 00000002 00000000
ffe0: b6eca5a0 bef21ba8 00016578 b6eca5b0 80000010 b6e0e000 2f7fd821 2f7fdc21
[] (regmap_mmio_read) from [] (_regmap_raw_read+0xc4/0x1d0)
[] (_regmap_raw_read) from [] (_regmap_bus_read+0x34/0x64)
[] (_regmap_bus_read) from [] (_regmap_read+0x7c/0x144)
[] (_regmap_read) from [] (regmap_read+0x50/0x70)
[] (regmap_read) from [] (opencores_i2s_probe+0x1cc/0x3cc [snd_soc_opencores_i2s])
[] (opencores_i2s_probe [snd_soc_opencores_i2s]) from [] (platform_drv_probe+0x3c/0x6c)
[] (platform_drv_probe) from [] (driver_probe_device+0xa8/0x36c)
[] (driver_probe_device) from [] (__driver_attach+0x9c/0xa0)
[] (__driver_attach) from [] (bus_for_each_dev+0x64/0x98)
[] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30)
[] (driver_attach) from [] (bus_add_driver+0xf8/0x214)
[] (bus_add_driver) from [] (driver_register+0x88/0x104)
[] (driver_register) from [] (__platform_driver_register+0x58/0x6c)
[] (__platform_driver_register) from [] (opencores_i2s_driver_init+0x18/0x24 [snd_soc_opencores_i2s])
[] (opencores_i2s_driver_init [snd_soc_opencores_i2s]) from [] (do_one_initcall+0xc0/0x1f0)
[] (do_one_initcall) from [] (load_module+0x185c/0x20c4)
[] (load_module) from [] (SyS_init_module+0xb4/0x120)
[] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x30)
Code: e5953000 e0833001 e5932000 f57ff04f (e5862000)
---[ end trace 9e28bccdff66bcd5 ]---
Segmentation fault
Hi,
Looks like you get a bus error as soon as the driver accesses the register file.
Could it be that the AXI interface (bridge between ARM processor and FPGA fabric) is not enabled?
Or perhaps that the registers in your Qsys design ends up differently from what the dts file references?
-br
hi,
Thank you for your answer and this project too;
you are right, AXI interface wasn't enable (faulty uboot.scr);
opencore module is now loaded correctly
wm8731 module fail with this messages:
des1soc-audio sound: ASoc: CODEC (null) not registred
des1soc-audio sound: snd_soc_register_card() failed
flatform sound: Driver des1soc-audio requests probe deferral
Any suggestion?
Hi,
You will need to modprobe/insmod the actual codec (wm8731.ko) before loading the de1-soc-wm8731.ko module. There's a patch for this codec to support 32 bit data, which is needed by the i2s driver.
-br
Hi,
Still not getting it to work :(
insmod snd-soc-opencores-i2s.ko
opencores_i2s at f00de000
insmod snd-soc-wm8731.ko
insmod snd-soc-de1-soc-wm8731.ko
0-001a supply AVDD not found, using dummy regulator
0-001a supply HPVDD not found, using dummy regulator
0-001a supply DCVDD not found, using dummy regulator
0-001a supply DBVDD not found, using dummy regulator
wm8731 0-001a: Failed to issue reset: -121
wm8731 0-001a: ASoC: failed to probe CODEC -121
de1soc-audio sound: ASoC: failed to instantiate card -121
de1soc-audio sound: snd_soc_register_card() failed
de1soc-audio: probe of sound failed with error -121
The "..... using dummy regulator" messages from wm8731 are normal. But "Failed to issue reset" message suggests that the wm8731 driver is not able to talk to the codec on i2c. Did you set the drive strength and pull-up as suggested in my README file? Could it be that your design is setting the i2c mux so that it's driven by the FPGA fabric rather than by the HPS?
-br
Hi,
Actually i'm using the wm8731 codec built in the de1-soc board, so i guess that the drive strength and pull-up are already satisfied by Terrasic. Do you agree?
Nope, I don't agree. At least on my own board, I couldn't talk to the codec with the standard Terasic pin assignments. Maybe it's because Terasic only talks to the code from the FPGA side in their demo design, and going through the mux changes something electrically. I don't know.
-br
I had a similar error but sadly I don't have the DE1 board anymore; that said, and before I gave the board back, I updated your project to 16.1 and socfpga-4.9(?) plus got a working FB demo project using mainline u-boot patches and fixed-up hand-off process. Anyway, if you want to look at upgraded Sound project and try it I can make a pull request.
https://github.com/VCTLabs/DE1-SoC-Sound
https://github.com/VCTLabs/vct-socfpga-bsp-platform
Also I pushed a u-boot patch to Robert and he updated his wiki/patch to enable fpga:
https://eewiki.net/display/linuxonarm/DE0-Nano-SoC+Kit
https://github.com/RobertCNelson/socfpga-kernel-dev
Lastly I pushed a u-boot readme.socfpga patch that describes the build/handoff process with mainline and Qsys:
Hi,
I looked at your changes and liked most of them very much, so please feel free to send a pull request. But how come your DTS refers to adx1345 rather than wm8731? And isn't adxl345 an accelerometer rather than a codec?
-br
That's the "gsensor" on-board the DE-1 and iirc I was just trying to make sure i2c was working and I could talk to something. Are you saying the .dts file is missing codec stuff? That was the first time I've touched one of these hybrid boards before, so I'm a bit light on clues... That said, I could probably borrow it back again for some testing, but I have some other more pressing crap to do first...
Yes, the "sound" node in the dts is supposed to connect an i2s controller to a codec. Connecting an i2s controller to an accelerometer doesn't really make sense...
Crap, then that's a mental typo, since the gsensor is on i2c (doh!). I really need some new reading glasses...
I'd like to open a PR but the (assumed) build process seems pretty finicky, ie, I only got it to build once via command line (quartus_sh --flow compile on the bare git code) and once just now doing the full Quartus/Qsys thing (now briefly documented in u-boot readme). Can you check those readme steps and describe your build process with the github source? See this commit:
http://git.denx.de/?p=u-boot.git;a=commit;h=8baa17832fa2406dc8dc36174d5ca5b06d39cb33
Should I open another issue for this?
If I sound vague and mumble a bit, it's because I haven't really re-visited this project for a couple of years, and my memory isn't what it used to be, as far as I can remember. Maybe it never was, I forget...
Anyway, I have never used the work-flow that's described in the README file from mainline u-boot. For the FPGA part (producing the .rbf bitstream file) I used the Quartus GUI. Press the right buttons in the right sequence, and magic happens...
For SPL/u-boot, most of the time, I simply used a pre-compiled SPL and u-boot that I copied from one of the Terasic reference designs for this board. I seem to remember compiling my own u-boot at some time, but then I just used the Embedded Development Suite from Altera to make an SPL and u-boot compatible with the design. Again a matter of pressing the right buttons in the right sequence for magic to happen... But the Terasic supplied binaries are perfectly OK for this simple design, as long as the the correct register gets the correct value to bring the FPGA interface to the DMA controller out of reset, something which can be done with suitable u-boot "write memory" command.
As for opening another issue, I have no strong opinions..
Yeah, I got the magic GUI to work but with many warnings - did you have "benign" warnings with 14.1? It seems the GUI does add a little magic compared to the command-line steps; the only other project I hacked on besides yours is the FB demo project, and that one includes a lot more files than yours (most of which get rebuilt anyway). The vendor Makefile in the project has two clean targets, and the "extra" clean target breaks the build; making it that clean takes it back to a similar state as yours I think.
2 questions left ;) I got the impression the I2C mux wasn't needed any more so it's currently disabled in the dts. Should I re-enable it? And what u-boot command do I need for DMA? I patched two u-boot branches, 2016 for boot.scr support (so it works like legacy Altera u-boot examples, etc) and the latest 2017.05 with uEnv.txt config and autoloading of fpga blob file. Both are in my work area along with a fork of rcn's kernel builder with patches for dts and config:
https://github.com/VCTLabs/u-boot
https://github.com/VCTLabs/socfpga-kernel-dev
Note you don't actually have to do anything unless you still have enough interest (but a pointer to the DMA thing would help). Thanks...
Quartus will list lots of warnings, at least for me. I don't think you should let some warnings worry you too much.
The i2c mux selects if the FPGA fabric is in control of the system i2c bus or if the i2c interface of the ARM SOC will control it. The card driver (de1-soc-wm8731.c) will attempt to read a the name of the GPIO controlling the mux from the dts, and if found, will set the mux to let the ARM i2c interface control it. So, if you choose to NOT list the GPIO in the dts, you will either need to set that GPIO correctly outside the driver, or you will have to implement an i2c interface in the FPGA fabric and connect the codec to that other i2c instance in the dts.
Enabling the DMA interface to the FPGA fabric can be done either using the Altera tools (e.g. in the EDS) to create a new u-boot SPL (based on the Quartus design where these DMA requests have been enabled, the correct initialization code will be added to SPL) or alternatively by setting some register (in u-boot) to the correct value BEFORE starting the kernel. The register is called "per2modrst" at address 0xFFD05018, and you should be able to read the description in Altera documentation for Cyclone V. I seem to remember that the value should be set to 0 for the channels used, one bit per channel at the least significant bits.
Try "mm.b 0xffd05018" and see if the existing value ends with 4 bits set (0xff). If so, clear those bits (0xf0).
Back to the first way, are you saying running the bsb settings tool and then the u-boot script to update the those header files will set DMA up correctly? If so, then that's already done, but I should go back and re-enable the mux so it should hopefully Just Work (if everything gets built correctly). Thanks.
I do know it was sufficient to build a new SPL using the Altera tools. I'm not so sure if it sufficient to build a new SPL using mainline u-boot sources. I briefly looked at the "qts-filter.sh"-generated sources in your u-boot repository, and I couldn't see anything there setting the right registers. Looking at the sources for the qts-filter.sh script makes me think that this is perhaps only intended to extract the absolute minimum amount of information from the qsys file to get u-boot going, and that all the bells-and-whistles in the Altera workflow has been left out. Maybe. I haven't used the process you are using, so I don't know for sure. But clearing the last four bits of 0xffd05018 with a memory command in u-boot should do the trick anyway..
How did you enable the AXI interface?
I didn't do anything special.. I believe this is all handled by the altera-hps2fpga driver and possibly also the other altera system drivers. Are these modules loaded and running? If not, one possible cause could be your device tree.
Oh right well I am able to write to the memory in Uboot using mw and then checking it with the md command. But when I try to use mmap it faults out with MAP_FAILED and then a segmentation fault appears. Been trying to sort it out for weeks but can’t get anywhere :(.
Sorry, I have never used mmap to map the AXI memory to user-space.. I assume you have read https://rocketboards.org/foswiki/pub/Documentation/WS3DevelopingDriversForAlteraSoCLinux/WS3_Developing_Drivers_for_Altera_SoC.pdf or similar documentation?