• Content Count

  • Joined

  • Last visited

About ChrisK

  • Rank

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

870 profile views
  1. That's just way too overgeneralized. Of course it is possible to speed up boot time, use a custom kernel and custom u-boot, while staying compatible to the "distro", which is merely the whole userspace stuff. Customizing a u-boot build, with ethernet and USB disabled will save the init tme for that. Removing the wait-time for user input gives another few seconds to save. Just because a system has some init system installed by default doesn't mean one has to use it. One can always tell the kernel what to use as init (PID 1). That can be the required app, or a shell, or some rudiment
  2. The isolcpus belongs into the bootargs in boot.cmd. For example, this will reserve core number 4: setenv bootargs console=ttyS0,115200 noinitrd root=/dev/mmcblk0p2 rootfstype=ext4 rootwait isolcpus=3 This will reserve cores 3 and 4: setenv bootargs console=ttyS0,115200 noinitrd root=/dev/mmcblk0p2 rootfstype=ext4 rootwait isolcpus=2,3 This will reserve cores 2 to 4: setenv bootargs console=ttyS0,115200 noinitrd root=/dev/mmcblk0p2 rootfstype=ext4 rootwait isolcpus=1-3 The isolcpus argument starts counting cores at 0. Keep in mind that the above are just examples, you may have the roo
  3. Funny, it looks exactly like the FriendlyArm NanoPi M1. Down to the silkscreen, even! The only change seems to be the removal of the FA label, and placing the pcDuino label there instead on the silkscreen.
  4. You can try to reserve one of the cores to the audio process(es). First you isolate a core by using the kernel parameter (boot argument) "isolcpus=...", and then you can use taskset to place threads/threads onto that core. In addition you should then also set a higher priority for those processes/threads. That way you have a complete core only for the audio processing, which should help a bit. Greetings, Chris
  5. It can, it uses GPIOG12 as the OTG-ID input. That is true for the NanoPi Neo as well as the NanoPi M1. It's right there in the schematic... Greetings, Chris
  6. What does the syslog/dmesg say? Does the ethernet disconnect and reconnect often? Here's the thing with chinese vendors: They like to cut corners wherever they can. This doesn't mean that the OPi folks want it that way, it could easily be their own supplier. Cheap chinese power supplies are known for being of lousy quality (frankly, i personally wouldn't leave them plugged in unattended). Those QC stickers, if there are any, are just decoration. I think it would be at least worth try, don't you think? Use the charger plug from your phone, assuming that is of a decent quality, and see w
  7. Ha, it seems that the BananaPI M2+ _does_ have the SPDIF output. I just checked the datasheet: I was checking it because i was wondering why the heck they would use a PA pin on the cam header, whereas the NanoPI's just use all the PE signals, since PE has everything that is needed for the camera (it's the cam interface, after all). Turns out they made a a rather nasty typo. Check page 2, upper-left. In the chip symbol itself you see PA17/SPDIF_OU
  8. That's not possible. The OWA interface (which is what they call SPDIF in the Allwinner datasheet) can only use PA17, there is no other routing/multiplexing option. The same holds true for any other hardware peripherial of the chip. Check chapter 3.7 of the datasheet, "GPIO Multiplexing Functions". And if you do direct register access to set up pin functions, check chapter 4.22/4.23 to see what register settings are required to chose what pin is selected for which function/peripherial. The case of 1-Wire sensors etc. is different, since that is implemented in software (the H3 does not h
  9. Check the output of dmesg repeatedly. If you see a lot of ETH disconnects/connects, it is possible that your power supply is the issue. I had such an effect on a NanoPI M1, getting a lot of dis-/reconnects (and sometimes just settling at 10MBit after a while). The problem was the power supply, which simply wasn't stable enough. Used a different one (the charger of my Samsung phone), and the problem went away instantly. BTW, power supply quality also plays a big role in the stability in general. With a bad supply i can freeze my boards reliably when starting "stress -c 4 -i 4". Sometimes al
  10. Hi Igor, what exactly is the issue with the 39-112 patch? The overlay-patch (02-0003-linux-sunxi-3.4.108-overlayfs.patch) is included in that one. I have tested it here, and so far it works. Let me know what the issue is, the i can re-crete it and possibly fix the large patch. Greetings, Chris
  11. Hi, my current project is about using a NanoPI M1 as a controller for a 3D printer. As such, one wants to have very tight timing on the GPIO output, with as little jitter as possible, to get smooth motion of the stepper motors. However, it is common belief that getting a fast timing with little jitter is virtually impossible to do under linux, without the help of a dedicated chip just for the IO. While that is true in general on stock kernels, it's possible to vastly improve on that front by spending a little effort. One way on ARM chips is to use the FIQ. That is an interrupt that
  12. Just to make sure the edit isn't overlooked: There was a bug in the full RT patch in the post above. Fixed it, and replaced the file in the previous post. Greetings, Chris
  13. Hi, Igor asked me if i could consolidate the RT patches into a single one, and only doing the extra patches seperately, so here they are. First, i added the fix for firmware_class.c in the 02-0005-backport-firmware-loader.patch, because that is what introduces the issue in the first place. So, that patch can be replaced by this file: 02-0005-backport-firmware-loader.patch.gz Then i took the liberty to consolidate all the patches that brings the kernel from 2.4.39 to 2.4.112 into a single one. I did so by first disabling all the patches from 02-0001-patch... down to z-0003... (l
  14. Hi, and here is another patch that should be added if the RT patch is applied. This one fixes BUG's that are triggered when using the interactive cpufreq governor. The probelm is that spin_lock_irqsave and spin_lock_irqrestore are used there, which leads to: BUG: scheduling while atomic: swapper/0/0/0x00000002 This patch makes it use the raw_ versions of those in case the PREEMPT_RT_FULL patch is applied. I wasn't aware of the issue until now, since i usually use the "userpsace" governor. Greetings, Chris 0006-cpufreq_interactive-spin_lock_for_rt.patch.gz
  15. Hi, attached is a patch for U-Boot (should work on 2016.09-rc1 and 2016-09-rc2-dirty, will probably work on older ones as well) that makes it use the plain text file uEnv.txt instead of boot.scr, which has to be translated to a binary file first. This way changing the environment means only editing a text file, instead of editing a file, converting it to binary, and copying it over to the /boot partition on the SD. This becomes active if the U-Boot config has the option OLD_SUNXI_COMPAT disabled (in the menuconfig this is under ARM architecture -> Enable workarounds for booting old kern