matrzh

  • Posts

    11
  • Joined

  • Last visited

matrzh's Achievements

  1. Thanks, everything back up and running. The firmware freeze held back the correct updates and a run of apt update/upgrade on the new installation worked well without breaking the boot process Matthias
  2. ok, I am giving up and will reinstall a new card with a working image. It will be faster and only take half a day to get everything re-installed.... I would appreciate if someone could give me any hints on what I need to do that the next "apt upgrade" is not bricking the device, again. Do I need to choose a different bootloader with armbian-config, before? Best Matthias
  3. Thanks again. Sorry if I am stuck again. In addition, the environment I had on my VirtualBox crashed completely and I set a new one, based on X64 Debian. compile.sh as suggested here:https://docs.armbian.com/Developer-Guide_Build-Preparation, I get an error Running this tool on non x86-x64 build host is not supported But I do have the an i386 Processor (Mac). dpkg --print-architechture gives 'i386' The code lines in general.sh 1013ff however suggest that only arm64 and amd64 are accepted. Can I build it on a i386 processor with virtualization, at all?
  4. I really appreciate your help, but I am not getting it (or at least I am not sure what is happening, the solution is really not that 'easy' to go through for me). The boot.scr file hast a datestamp of May 7 which likely was the initial installation when I etched the SD card (so ok, it's 8 weeks ;)). That apparently did not change, yesterday (as are boot.cmd, boot.bmp) Does this mean the old boot.bmp does not "fit" to the newly created initrd.img.... file (which has a datestamp of July 30, i.e. yesterday) Would locking this to "BOOTBRANCH='tag:v2020.10'" as suggested in the patch of the solution remedy it and avoid this in the future? So a possible solution would be to adopt the boot.* files. I found / am finding this confusing because they did not change. Best Matthias
  5. Thank you. The easiest for me would be to manipulate the SD card in a computer and then hope that it will not enter a bootloop, again. Can you tell me which files I need to revert? The manipulated files from the update in the /boot directory are uInitrd-5.10.43-sunxi (with uInitrd sym-linked to it) initrd.img-5.10.43-sunxi Can I download the files for the A20 processor somewhere without having to burn another SD card?
  6. For the second time within about 4 weeks my cubietruck is not coming up anymore after a sudo apt upgrade and reboot. Is there something systematically breaking? I think it is the initramfstools that is breaking it? Now, I have no radio, alarm-clock and I cannot turn on my coffee-maker over the internet and I will probably have to spend a day etching a new SD card etc. I bought a new SD card last time this happened since I figured ist would be related to that, now I think it is a software thing. I use the cubietruck headless over ssh and have no real video output, just audio. I also need to do some cumbersome operations to get it out of the box, it is in from which it is controlling all sorts of remote controls for receivers, projectors etc. So it is almost easier to etch a new card, but I am afraid I will find myself with the same problem in a few weeks again. I used the following image Armbian_21.05.1_Cubietruck_buster_current_5.10.34_xfce_desktop.img The latest upgrade did the following: The following packages will be upgraded: code firefox-esr libgssapi-krb5-2 libjavascriptcoregtk-4.0-18 libk5crypto3 libkrb5-3 libkrb5support0 libnss-myhostname libpam-systemd libsystemd0 libudev1 libwebkit2gtk-4.0-37 linux-u-boot-cubietruck-current systemd systemd-sysv udev In particular: Processing triggers for initramfs-tools (0.133+deb10u1) ... update-initramfs: Generating /boot/initrd.img-5.10.43-sunxi update-initramfs: Converting to u-boot format Is it now trying to boot from ramfs rather than the SD-card? Any suggestions on what I could do in a more "minimally invasive" way to get it back to work? Any updates I should hold back in the future to keep this from happening?
  7. I am answering my own question. I finally did play with the -a and -b options of squeezelite, and it seems that the option -a 400 does the trick, which is 400ms seconds of alsa buffer time, if I read the man page correctly. I have been listening to squeezelite for the last 10 minutes or so and did not have an interruption, so far. specifying a stream buffer with -b does not change anything (or only very marginally). So for me: To make squeezelite work well with spdif on a cubietruck (Allwinner A20 processor), I need to launch it as follows squeezelite -o hw:1 -a 400 To properly load it with systemd, the following lines need to be in /etc/default/squeezelite : SL_SOUNDCARD="hw:1" SB_EXTRA_ARGS="-a 400" Maybe it helps someone
  8. Hi, I have just changed from a custom legacy kernel to armbian and like the experience. I use the Logitech Media Server and squeezelite, mainly to play radio on the armbian box itself as well as on a Squeezebox Radio I still have. This works in principle, but using the spdif optical output, I get an interrupt every minute or so of about half a second. Is this common and do I need to install something in addition to use the spdif output? System information: Allwinner A20 cubietruck Kernel (uname -r): 4.19.62-sunxi Squeezelite v1.8 Logitech Media Server Version: 7.9.2 - 1565967976 @ Fri Aug 16 17:18:03 CEST 2019 output of aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sun4icodec [sun4i-codec], device 0: CDC PCM Codec-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: SPDIF [On-board SPDIF], device 0: spdif-dit-hifi dit-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 output of squeezelite -l Output devices: null - Discard all samples (playback) or generate zero samples (capture) default:CARD=sun4icodec - sun4i-codec, - Default Audio Device sysdefault:CARD=sun4icodec - sun4i-codec, - Default Audio Device dmix:CARD=sun4icodec,DEV=0 - sun4i-codec, - Direct sample mixing device dsnoop:CARD=sun4icodec,DEV=0 - sun4i-codec, - Direct sample snooping device hw:CARD=sun4icodec,DEV=0 - sun4i-codec, - Direct hardware device without any conversions plughw:CARD=sun4icodec,DEV=0 - sun4i-codec, - Hardware device with all software conversions default:CARD=SPDIF - On-board SPDIF, - Default Audio Device sysdefault:CARD=SPDIF - On-board SPDIF, - Default Audio Device dmix:CARD=SPDIF,DEV=0 - On-board SPDIF, - Direct sample mixing device dsnoop:CARD=SPDIF,DEV=0 - On-board SPDIF, - Direct sample snooping device hw:CARD=SPDIF,DEV=0 - On-board SPDIF, - Direct hardware device without any conversions plughw:CARD=SPDIF,DEV=0 - On-board SPDIF, - Hardware device with all software conversions I run squeezlite with option -o hw:1 other options I tried was -o default:CARD=SPDIF, -o hw:CARD=SPDIF,DEV=0, plughw:CARD=SPDIF,DEV=0 The default option was the worst in terms of interrupts, I think. Any hints? Cannot see anything suspicious in the logs. The interrupts do not appear if I use the hw:0 (sun4icodec), but the volume level and noise is much better with the spdif. I read somewhere that it is normally not necessary to mess with buffer or alsa parameters. (-b / -a options in squeezelite)
  9. O.k. I just had to include the path /usr/src/linux-headers-4.14...sunxi/include and the code sense works. Guess I can take it from here. The normal "cross compile" seems to work, too.
  10. No. But I am still at the stage to set up a decent IDE, so that I can include header files for other kernel drivers etc. I do not believe that the modules will just compile, the gpio is handled differently in the new kernel and I would actually like to explore the code a bit (without changing it). The *.h files will probably suffice to see what definitions exist. Actually, I would just have to know where the sources are, after compile.sh is being run.
  11. This may be a somewhat stupid question, but I just cannot find anything about it. I have custom-compiled the kernel for Allwinner A20/cubietruck as described here on a Virtual Box Ubuntu 18.04 Once done, I took the *.deb files out of output/debs, copied it to the machine and installed them. Everything worked fine and so far so good . But the "build" directory on the host with the compile.sh script is surprisingly empty. However, if I want to cross compile an additional kernel module on the virtual machine, how do I set this up? Is it enough to "make" with CROSS-COMPILE=arm-linux-gnueabihf-? or do I also need to somehow consider the linaro stuff in cache/toolchains? (the arm-linux-gnueabihf files are all in the /usr/bin of the host machine) I also want to reference some header-files (*.h) from the drivers sources, etc. can I copy the directory /usr/src/linux-headers-4.14....-sunxi? What happens if I extract the linux-source-next-sunxi_5.66_all.deb file to the virtual host machine? Also as a side note: if I want to recompile to enable an additional module, what do I do to use the old kernel configuration as a base? When I run "compile.sh" again, I get the choice to choose "cubietruck" again, but it starts from zero and does not consider any options I had previously disabled or changed. The reason, I am doing this, is that I am upgrading from a legacy kernel and I have some custom modules to control peripherals here and here, that I want to adapt to the new kernel.