• Content Count

  • Joined

  • Last visited

Everything posted by jkoller

  1. I did notice that this petalinux project sources a remote kernel from Digilent, and the configuration shows this. So the kernel source is downloaded to {$PROJECT/build/linux/kernel/download/linux-digilent} before being built. However, during project level petalinux-config, I noticed the autoconfig directory for device tree points to the default {/opt/petalinux-v2015.4-final/components//linux-kernel/xlnx-4.0/include} directory. My understanding is that both kernels are 4.0.0, so this will work until someone tries to build with a PMOD device that needs special drivers from the remote kernel...should the device tree autoconfig include directory be changed to point to the remote kernel code source directory, or does petalinux figure this out on it's own? I'd also like to modify the kernel source. Do you recommend I copy the Digilent kernel into $PROJECT/components/kernel first? Or should changes be made within build/linux/kernel/download? I'm not sure how the scripts and makefiles grab the source code for the kernel, and whether changes go into "download" or if they go into the linux-digilent directory. I'll go through the makefiles, but your help could save me some time. Thanks!
  2. Apologies for the long delay. I did get the Zybo Base demo working, and audio seems to be working OK. I think at this point I had a mix of petalinux not updating the BOOT.BIN with the correct .bit file (despite using the documented methods of forcing this rebuilt), but still using the expected system.dtb, so hardware and software were not aligned. So, I made some (more) petalinux projects, based solely on the default files found in the petalinux quick-start found here: https://github.com/Digilent/petalinux-bsps/wiki/Quick-start-guide I can use the prebuilt image and boot via jtag, or build my own (from all default configs), and boot that via SD card. I haven't been able to boot custom images via JTAG, unless I package them as a prebuilt image first. I'm not sure why, but I won't use JTAG for very long, once I get my rootfs back on line anyway. Next I'll try to get back to where I was...patch the linux kernel with preempt_RT, get a rootfs with all the software I am using (tigerVNC and a plethora of audio software), and then modify the hardware image to ditch the video hardware and free up the PL for custom logic. tigerVNC allows me to operate in a headless configuration, but still have command line and X programs, and using fluxbox as a window manager, it's fairly light on these processors and memory. Thanks for the updated quick start guides, and the BSP releases. I will migrate to a custom Yocto build eventually, but petalinux + Linaro as rootfs has the advantage of script builds and apt-get for the moment. Hopefully I don't get ".bit" again with hardware changes.
  3. Early next week, I'll try the zybo base design first, and see how that goes. Thanks for that tip Tommy, and if that doesn't work, I'll look into an RMA, thanks Sam! I also forget to mention, in the process, I found out the hard way about the makefile bugs for FSBL. I see them mentioned in your new petalinux guide. When I built images for testing the 12.000MHz clock for the codec, thinking back I'm not sure the FSBL and BOOT.bin were correctly made. So 12.000MHz may still be an option for the full palette of sample rates.
  4. Damn. Debugging further, and I started to hit several roadblocks during bootup. So I retraced my steps and went back to the beginning with a new project, kernel, etc. And now any time I enable the SSM2602, my boot sequence is stuck. Any boot without it, and all is well. I'll see if I can compile as a modprobe/module, and dig further, but I fear my codec is fried. I'll see if I can debug the kernel, but I may just move on to USB audio.... ( I had brought up an RT patched 4.4 kernel with low latency and such...)
  5. 48000 and 32000 seems to work OK, but 44100 does not play tones correctly. To check this, I used speaker-test -f 440 -t sine -c 2 -r 44100 (or 48000/32000) I hear the sine 440Hz is different, and using a chromatic tuner app on my phone, confirmed that 48k and 32k are correct.
  6. As an experiment, I modified the hardware design, to change the clk_wiz_0 generator from 12.288MHz to 12.000MHz. I also changed the device-tree file to match as follows: i2s_clk: i2s_clk { compatible = "fixed-clock"; #clock-cells = <0>; clock-frequency = <12000000>; clock-output-names = "i2s_clk"; }; Even though this is a USB mode, according to the ADI SSM260* spec, I can now see more typical rates available (such as 32kHz and 44.1KHz). Not sure why, but it seems ok after playing back files recorded at different sample rates. I tried to avoid software sample rate conversion, and the sample rates reported seemed correct, so maybe this way is easier than the alternative, which is to modify the driver and hardware to control the clk_wiz_0 to change the MCLK sent to the codec depending on the selected sample rate. I still have more digging to do to verify this.
  7. I can confirm this works!! I built this using a standard petalinux 2015.4 flow, with the device tree saved as .../subsystem/linux/configs/device-tree/system-top.dts The kernel config (dummy.config) saved as: .../subsystem/linux/configs/kernel/config I am also booting with linaro root_fs, so I also copied .../build/linux/rootfs/targetroot/lib/modules/4.0.0-xilinx to [MY SDCARD ROOT_FS]/lib/modules/. >>>>> [email protected]:~# aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server default:CARD=ZYBOSoundCard ZYBO-Sound-Card, Default Audio Device sysdefault:CARD=ZYBOSoundCard ZYBO-Sound-Card, Default Audio Device dmix:CARD=ZYBOSoundCard,DEV=0 ZYBO-Sound-Card, Direct sample mixing device dsnoop:CARD=ZYBOSoundCard,DEV=0 ZYBO-Sound-Card, Direct sample snooping device hw:CARD=ZYBOSoundCard,DEV=0 ZYBO-Sound-Card, Direct hardware device without any conversions plughw:CARD=ZYBOSoundCard,DEV=0 ZYBO-Sound-Card, Hardware device with all software conversions [email protected]:~# speaker-test speaker-test 1.0.25 Playback device is default Stream parameters are 48000Hz, S16_LE, 1 channels Using 16 octaves of pink noise Rate set to 48000Hz (requested 48000Hz) Buffer size range from 64 to 65536 Period size range from 32 to 32768 Using max buffer size 65536 Periods = 4 was set period_size = 16384 was set buffer_size = 65536 0 - Front Left Time per period = 1.375699 0 - Front Left Further, recording works! at least at "dat" quality, or 48000Hz for now. [email protected]:~# arecord -t wav -c 2 -d 5 -f dat input.wav Recording WAVE 'input.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo [email protected]:~# aplay -d 5 -f dat input.wav Playing WAVE 'input.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo this works, but will cause clicks in the audio: (I am fiddling with alsaloop to get a decent loopback from input to output) [email protected]:~# arecord -c 2 -f dat |aplay -c 2 -f dat Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Thanks!!!
  8. I was able to recreate the hardware, export to SDK, use this kernel config you provided, and also copied the device-tree provided into a petalinux system-top.dts. Builds and boots fine. However, there is no ALSA sound card registered, and I do not have a /dev that matches the ADI SSM2603, so I am trying to build these drivers as modules, instead of built-in. I'm using Linaro/Ubuntu as rootfs. What from the petalinux build gets copied into my rootfs /lib/modules? (I think this needs to be done, since the modprobe can't be run as /lib/modules isn't populated yet). I think it needs to come from build/linux/rootfs/targetroot, but there's a lot there, and I'd like to get the dir tree correct to avoid headaches in the rest of the module debug.
  9. The devil is always in the details, and thanks for noticing. I didn't realize there could be two root directories for digilent projects. However, the master branch I checked out seems to have much more recent activity than the master-next branch of the DigilentInc projects. That doesn't mean it'll work, or is better, but it seems like that is where the current attention is.
  10. I think it's in master now, NOT master-next anymore.
  11. I spoke too soon. I found some issues, and think they may have been due to the fact that I originally git cloned the repo from within windows, and then copied into my VM/CentOS home dir for building (so symlinks & such would work). So I re-cloned directly from within my linux VM. Now there is no zynq_zybo.h or zynq_zybo board config available. 1060 ~/ZYBO_linux_bd $ git clone -b master-next https://github.com/Digilent/u-boot-Digilent-Dev.git Initialized empty Git repository in /home/ME/ZYBO_linux_bd/u-boot-Digilent-Dev/.git/ remote: Counting objects: 252883, done. remote: Total 252883 (delta 0), reused 0 (delta 0), pack-reused 252883 Receiving objects: 100% (252883/252883), 71.40 MiB | 5.44 MiB/s, done. Resolving deltas: 100% (200876/200876), done. ... 1079 ~/ZYBO_linux_bd/u-boot-Digilent-Dev $ find -name *zybo* 1080 ~/ZYBO_linux_bd/u-boot-Digilent-Dev $
  12. Thanks for the response, and another tutorial (the first you listed). I have followed several others (from Digilent) that are out of date, inaccurate, or otherwise in need of touch up. After following the Linux on Zybo tutorial (through u-boot anyway), I can build it correctly. A few warnings and errors were cleaned up by converting scripts from DOS format to unix via dos2unix (mkconfig and tools/scripts/define2mk.sed had ^M as line endings that coughed up a few messages after I allowed the shell called in mkconfig to report errors.) Removing petlainux from my search path also may have helped. I'll follow up if I make it all the way through. I still like the petalinux methods, as the wrapper scripts keep everything simple & clean. But I prefer understanding the flow beneath those scripts, as these examples show. Thanks again.
  13. Somewhat out of curiosity, somewhat out of frustration to get zybo linux builds all complete manually, I decided to try configuring/compiling the Linux-Digilent-dev kernel source from within petalinux tools. This avoids a large number of steps (to generate uboot, fsbl, project management, etc). After creating a project via `petalinux-create -t project`, and then importing hardware bsp, I placed a copy of the Linux-Digilent-dev within %PETALINUX_PROJECT%/components/linux-kernel/Linux-Digilent-dev. I only had to run petalinux-config and set the device tree include dir manually to point within the above directory, and to select the above as the kernel source. Compiles mostly work, except for an exception looking for BITS_PER_LONG in various places. I found the ./arch/arm/include/uapi/asm/bitsperlong.h file missing, copied it from one of the other locations, and that got through a few errors, until I hit this one: [ALL ] In file included from ~/ZYBO_linux_bd/petalinux_bd/components/linux-kernel/Linux-Digilent-dev/scripts/mod/devicetable-offsets.c:2:0: [ALL ] ~/ZYBO_linux_bd/petalinux_bd/components/linux-kernel/Linux-Digilent-dev/include/linux/mod_devicetable.h:311:48: error: 'BITS_PER_LONG' undeclared here (not in a function) [ALL ] kernel_ulong_t evbit[INPUT_DEVICE_ID_EV_MAX / BITS_PER_LONG + 1]; [ALL ] ^ [ERROR] make[5]: *** [scripts/mod/devicetable-offsets.s] Error 1 [ERROR] make[4]: *** [scripts/mod] Error 2 [ERROR] make[3]: *** [scripts] Error 2 [ I am beginning to think some other config setting is incorrect. Does any one have an idea of what the issue could be? I'll go and try to compile the kernel manually, but I ran into issues trying to configure and compile u-boot, which is why I ended up taking this path.
  14. I am at this same place. Was this with the Digilent axi_i2s_adi_1.2 interface (as found in the latest digilent-vivado-library.git)? I did not see this updated IP in a release zybo_base_system.
  15. Hello, I have a Zybo that I've been using. Currently, I'm exploring the various "distros" of linux available, that have some example or history of running on Zybo...Petalinux, the Digilent variant of Xilinx Open Source Linux, and Xillinux. I've seen Ubuntu available as well. I'd like to bring up a headless system, but with audio working. Eventually, I'd like to migrate to an AMP Linux/Baremetal implementation. For the PL side, I have my own design in development to leverage the ACP for hardware acceleration. I'd welcome any experience and/or insight into bringing up a fast and low-latency linux or AMP system. I'd like the tool flow to be solid, and not have to spend too much time on integrating an odd ball flow with xilinx tools or debug when necessary. Thanks in advance, Justin