Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

833 profile views
  1. thank you @martinayotte for the tip. @orangepower : as you, I was in such a trouble: my solution was to remove emmc module from the nanoPi and then from my PC erase emmc's content using an usb2emmc adapter. Kind of brutal solution but really efficient
  2. do you hav both boards : the pecanpi and the tinkerboard ?
  3. I agree with Guidol's point of view. But, so far if you already have a tinkerboard lying on your desk if you know how to use etcher (or any other tool for creating a bootable disk) Then by following instructions given above and these on how to compile armbian you should be able to get your DAC up and running under armbian. And, maybe you will just have to adapt the "compatibility" line in the dts file ... I would be glad to help you further, but without having the tinkerboard, and without having this dac it's hard to do more ...
  4. do you have any board in mind. Armbian runs on a wide variety of hardware. See here: https://www.armbian.com/download/?device_support=Supported and here for the boards in testing stage: https://www.armbian.com/download/?device_support=Suitable+for+testing+(WIP) They are boards that haven't got any i2s interface. Have a look at this thread for some guidance: You will have to compile driver pcm179x-i2c or pcm179x-spi depending on the hardware control protocol used by your device, I'm quiet sure that it isn't enabled by default in armbian. The device tree overlay for rpi-dac is quiet simple and should easily adaptable: https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/overlays/rpi-dac-overlay.dts // Definitions for RPi DAC /dts-v1/; /plugin/; / { compatible = "brcm,bcm2835"; fragment@0 { target = <&i2s>; __overlay__ { status = "okay"; }; }; fragment@1 { target-path = "/"; __overlay__ { pcm1794a-codec { #sound-dai-cells = <0>; compatible = "ti,pcm1794a"; status = "okay"; }; }; }; fragment@2 { target = <&sound>; __overlay__ { compatible = "rpi,rpi-dac"; i2s-controller = <&i2s>; status = "okay"; }; }; }; Again, post mentioned above will give most of what you are looking for. Good luck
  5. Well, I own a nanopi m4v2 + nVme hat and ssd, but for an unknown reason, the board doesn't start anymore. I suspect that some component has been toasted elsewhere ... So sad ... First, I've got to say that I'm far from being a guru in all these uboot, bootloader stuff. But that is the case for the m4v2 + nvme ssd => you need sd card for booting the board and then access root filesystem on the ssd. By swapping the sd card I had the ability to install and choose to use legacy or mainline on two separate partitions. => so while booting the board with a fresh armbian sd card, you can backup a ssd partition or even the whole drive with dd. But I don't know if it is feasible on the emmc drive. Btw, there is a "recovery" button on the board, what is that use for, it's a mystery
  6. I mean, if you can boot on a sd card with armbian on it, you should be able to copy the content (using dd command) of the emmc to an external hard drive connected via usb.
  7. @pkfox, once you have installed armbian on emmc, you can't boot on the sd card anymore (unless you remove the emmc) ?
  8. Woua, specs are quiet excellent but it's... an expensive stuff ,🙄
  9. Hi, that is a great news ! the provided dts file is for what kind of board ? Do you plan to get the touch to work too ?
  10. Hi Werner, hi Myy I like big challenge I went through all the building process (without having initialized any FLAGS as said above) on the nanoPi itself. But I don't realize how it can impact on software performance, or compilation speed or .... I will run the process again with Thank you
  11. Hi, that's great ! I will try your fix later next week on nanoPi m4v2 and will keep you informed if it works.
  12. Hi, I'm trying to build a zynthian synthesizer on a nanoPi m4v2. The principle is to start from a minimal buster image and run a bunch of compilation scripts (see here on github) to create all the needed software. But all that stuff is for Raspberry Pi. In an initialization script (see here on github) they define compilation flags like this: if [ "$ZYNTHIAN_FORCE_RBPI_VERSION" ]; then hw_architecture="armv7l" rbpi_version=$ZYNTHIAN_FORCE_RBPI_VERSION else hw_architecture=`uname -m 2>/dev/null` if [ -e "/sys/firmware/devicetree/base/model" ]; then rbpi_version=`tr -d '\0' < /sys/firmware/devicetree/base/model` else rbpi_version="" fi fi if [ "$hw_architecture" = "armv7l" ]; then # default is: RPi3 CPU="-mcpu=cortex-a53 -mtune=cortex-a53" FPU="-mfpu=neon-fp-armv8 -mneon-for-64bits" if [[ "$rbpi_version" =~ [2] ]]; then CPU="-mcpu=cortex-a7 -mtune=cortex-a7" FPU="-mfpu=neon-vfpv4" fi #CPU="${CPU} -Ofast" #Breaks mod-ttymidi build FPU="${FPU} -mfloat-abi=hard -mlittle-endian -munaligned-access -mvectorize-with-neon-quad -ftree-vectorize" CFLAGS_UNSAFE="-funsafe-loop-optimizations -funsafe-math-optimizations -ffast-math" fi export MACHINE_HW_NAME=$hw_architecture export RBPI_VERSION=$rbpi_version export CFLAGS="${CPU} ${FPU}" export CXXFLAGS=${CFLAGS} export CFLAGS_UNSAFE="" export RASPI=true I'm totally confused with aarch64, arm64, armv7, armv8 ... Can someone help me to set the right options here. What I've done so far, was to remove all these FLAGS initialization (because of errors), but this is for sure not the best way to optimize that Thank you for your input!
  13. Yes, you can go that way. ADCLRC and DACLRC will share the same GPIO pin number 35
  14. That board has a 12.288 MHz crystal. You'll have to adjust the clock settings accordingly in the dts file. The sample rate will be 44100 hz. Btw, did you notice that mikroe's proto board only has got one microphone input ?
  • Create New...