Heisath

Nah, all good from here. I'll try to do the release this sunday. Might hop in the IRC if I need assistance. Release on sunday evening is good IMHO because if something critical goes wrong, we can fix on monday.

Hi, so I merged master into release candidate branch. Can you please check the Jira issues that are still "In Progress", or can I assume they are all not done? Or are some expected to be closed in May? https://armbian.atlassian.net/secure/RapidBoard.jspa?rapidView=2&projectKey=AR

So planned release candidate period is almost over. Not much feedback here... Any comments from the devs / testers on state? Igors testfarm looks good. Also please tell me if any of the commits on master (since rc) need to be included in this release (as they are bugfixes): https://github.com/armbian/build/compare/v21.05.0-rc...master @tparys @piter75 @Igor @lanefu @Werner @Rich Neese @Paolo @redchenjs (dont know the forum tags)

To add to @tparysexcellent answer: The original code with commented problems: const int left_Trig = 1; const int left_Echo = 2; const int center_Trig = 3; const int center_Echo = 4; const int right_Trig = 5; const int right_Echo = 6; float a; float b; float c; void setup() { Serial.begin(9600); pinMode(left_Trig, OUTPUT); pinMode(center_Trig, OUTPUT); pinMode(right_Trig, OUTPUT); pinMode(left_Echo, INPUT); pinMode(center_Echo, INPUT); pinMode(right_Echo, INPUT); Serial.println("Ultrasonic sensor:"); } void loop() { digitalWrite(left_Trig, LOW); delayMicroseconds(2); digitalWrite(center_Trig, LOW); delayMicroseconds(2); digitalWrite(right_Trig, LOW); delayMicroseconds(2); // Why the delay when turning them all off? Why not just turn all low at the same time? digitalWrite(left_Trig, HIGH); delayMicroseconds(10); digitalWrite(center_Trig, HIGH); delayMicroseconds(10); digitalWrite(right_Trig, HIGH); delayMicroseconds(10); // Delay after turning each one on, guarantees at this point the left one was on for 30µs already, the center for 20µs and the right one for 10µs that cant be right? // maybe again turn them all on, then wait 10µs? digitalWrite(left_Trig, LOW); digitalWrite(center_Trig, LOW); digitalWrite(right_Trig, LOW); // this seems ok a = pulseIn(left_Echo, HIGH) / 58.00; Serial.println(a); b = pulseIn(center_Echo, HIGH) / 58.00; Serial.println(b); c = pulseIn(right_Echo, HIGH) / 58.00; Serial.println(c); // this has problems because as tparys assumed pulseIn blocks. So the first pulseIn waits for the first echo, but then the second and so on might have been already missed! // https://www.arduino.cc/reference/en/language/functions/advanced-io/pulsein/ a = (int(a * 100.0)) / 100.0; b = (int(b * 100.0)) / 100.0; c = (int(c * 100.0)) / 100.0; // not sure what you are trying to do here? Multiply by 100 then divide by 100 just gives 1. So might just scrap it? Serial.println(a); Serial.println(b); Serial.println(c); Serial.println(); delay(10）; } Improved code, using one function to get rid of duplication and read one sensor after the other: const int left_Trig = 1; const int left_Echo = 2; const int center_Trig = 3; const int center_Echo = 4; const int right_Trig = 5; const int right_Echo = 6; float a; float b; float c; void setup() { Serial.begin(9600); pinMode(left_Trig, OUTPUT); pinMode(center_Trig, OUTPUT); pinMode(right_Trig, OUTPUT); pinMode(left_Echo, INPUT); pinMode(center_Echo, INPUT); pinMode(right_Echo, INPUT); Serial.println("Ultrasonic sensor:"); } void loop() { a = getEchoTime(left_Trig); // use a funtion here to get rid of the duplicate code b = getEchoTime(center_Trig); c = getEchoTime(right_Trig); Serial.println(a); Serial.println(b); Serial.println(c); Serial.println(); delay(10）; } float getEchoTime(int channel) { digitalWrite(channel, LOW); delayMicroseconds(2); // turn channel of, and wait digitalWrite(channel, HIGH); delayMicroseconds(10); // turn channel on, then wait 10µs digitalWrite(channel, LOW); // turn off, total pulse time 10µs return pulseIn(channel + 1, HIGH) / 58.00; // use +1 here, as the echo channel seems to be trigger channel + 1 } An even better way would be to use interrupts (either external or pinchange) as this would allow you to fire the pulse and then do something else while waiting for the echo. I'm sure there are plenty of tutorials out there on how to read ultrasonic sensors in arduino without blocking.

Sure, you can first build a debian on an usb stick and try to boot or chroot from it. Only other way, I could think of, would be, to pay someone else (or at least provide a/the DNS340 to them).

https://askubuntu.com/questions/627842/what-does-the-form-field-enter-auth-username-during-the-boot-proccess-mean

Ok, so now you know that the box is running linux kernel 3.2, something you probably do not want to use, when building/running your own stuff. Uboot 2011 is not that horrible, and it supports the hardware so I'd leave that alone for the time beeing. I checked the GPL sources, but also couldn't figure out how to easily build an image from them. Doesnt matter though, because you wouldn't want to build from them anyway (as you'd then get the same kernel thats on the box right now). For the next steps, I'd go with what I wrote before. Check the web resources linked in previous posts, try to get a serial log from bootup (regarding uboot, probably try to grab the uboot vars on the way) and then try to prepare mainline debian and chroot into it. Go from there. It is hard to really tell you exact steps, as we don't know the exact results you get. Work like this is very much experimental

Is this on cli or desktop? I am confused because I never saw Armbian printing out a prompt like "Enter Auth Username" and "Enter Auth Password". This makes me think, maybe you have some third party software, which is asking for some info there? (ex. the VPN). Or is this some flavor of the image? You could start with a clean image on SD card, just boot it up once, and then (without installing / setting up any of your services), reboot it. Does it show the same prompt? Also try to attach screenshot / serial log.

Code freeze has happened. I have branched an rc version (https://github.com/armbian/build/tree/v21.05.0-rc ) please send bugfixes here (additionally to the master branch). Also the version of the master branch has been set to 21.08.0-trunk. Please check the remaining Jira and Github PRs to see if anything in Jira needs closing (will be used to generate the changelog). Testing and Bugfixing will be until beginning of May. Kind regards, Heisath

DLINK has pretty easily accessible sources, go to their product page: https://eu.dlink.com/uk/en/products/dns-340l-sharecenter-4-bay-cloud-network-storage-enclosure And to their "GPL Support" page: https://tsd.dlink.com.tw/dlist?OS=GPL If you search for the device there, you actually get the tar.gz. with all the used files for building the firmware. Good way to figure out the kernel, uboot and compiler version used.

It might be. At least there you can check for an uncluttered way of building kernel and custom initramfs. But you seem to already have access to some linux terminal. So my suggestion is to: - gather information about the system from there (which kernel is it running, which modules, what partition layout, grab the device tree etc. ) ( see lsblk, lsmod, uname ...) - try to prepare a debian (with debootstrap or similar) on a usb stick. Insert the usb stick into the DLink and chroot over to your debian. Then you can try how it works w/o removing the old system. - look for a hardware uart (serial interface) and have a look at the bootup. Without a hardware serial it will be hard / dangerous to do any permanent changes as you will not be able to see boot errors - if you have access to hw uart: - try to stop in uboot and look at the version and parameters there. I would probably not recommend reflashing the uboot - try to get uboot to load the linux kernel from an alternative source (usb stick for example, often possible for FW recovery) - if it is possible to boot from somewhere else (uboot on flash, kernel on usb stick) try to compile a mainline kernel and initrd for the device, put on usb stick and try to load that - if it is not possible to boot from somewhere else, I'd seriously think about going further. If you break it, you might not be able to fix it. Maybe check if the DLINK page has recovery instructions via usb? If it has, you might at least have a way back. - if you get a boot from seperate device (usb stick or internal hdd) and everything works, I'd prepare the root system on the usb stick (easy to swap into other computer to add files etc.). Afterwards if you're happy with the system, try to replicate the steps on the internal flash. (or just keep running from USB, would not make a big difference probably). EDIT: As I'm personally interested in the device, is it available somewhere cheaply? Like used one without hdd on ebay? Also if you have gathered the information from the first steps, post it. I will look at it and try to help. EDIT2: I found this on the interwebs: https://jamie.lentin.co.uk/devices/dlink-dns325/ Is meant for DNS325 but has a good step-by-step explanation how this guy found the serial port etc.

There are no Armada 370 devices currently supported by Armbian. You can try to adopt one of the Armada 385 devices (helios4 & clearfog) or check if there ever were other Armada devices supported (dont think so). Probably you want to check here first: https://github.com/armbian/build/tree/master/config/boards https://github.com/armbian/build/tree/master/config/sources/families (mvebu) You can also check out my build tree for the WD MyCloud (which is Armada 375 based) https://github.com/heisath/wdmc2-kernel

Yeah that should be right. A ran into similiar errors when using some PCIe devices with newer kernels.

@those who didnt make it: No problem, just check the meeting log http://meeting.armbian.de/ , the irc chat log (irc.armbian.com/logs) and the Jira issues for the next release (https://armbian.atlassian.net/secure/RapidBoard.jspa?projectKey=AR&rapidView=2) @all: For the next weeks, remember to try and fix Jira issues (also mark them as done), review open PRs and issues on github. And try to get your work done before the codefreeze 2021-04-19 (Monday April 19th). @Igor: Wouldn't say so. I asked about the holiday thing in first post, also with note to possible reschedule. People could've said something beforehand @the new release dude: Show yourself! It's easy and a good way to help the project without needing to get all technical.

You can plug the circuit in some simulator (like falstad.com, LTSpice or similar) to check what the parameters do. I did that for you here: https://tinyurl.com/yemxbzmt As you guessed R6 in combination with LM358 B does work as a schmitt trigger. See also this circuit with just the B half. https://tinyurl.com/yehg4ooh The exact size of R6 probably does not matter all that much.

As I said, try adding CLEAN="" to stop the script from cleaning the kernel tree in cache/

If you want to continue using the armbian buildscript but want the compilation to run faster (when doing small changes to kernel tree each time), you can also try to call ./compile.sh CLEAN="" This will skip cleaning the uboot and kernel sources and thus make compilation much faster. Warning, the patches will still be applied and might fail, shouldnt be a problem though. See https://docs.armbian.com/Developer-Guide_Build-Options/ for more options.

Release Planning: April 3rd. Meeting in IRC channel #armbian on freenode. Meeting starts at 2pm GMT. (let me know if this is a bad date, because it is around easter holiday in Germany for example) Code Freeze: 2021-04-19 (Monday April 19th) Release Date: 2021-05-09 (Sunday May 9th) Release Candidate: https://github.com/armbian/build/tree/v21.05.0-rc Changelog: https://docs.armbian.com/Release_Changelog/#v2105-2021-05-09 Coordinator: @Heisath The goal of this thread is to discuss testing, bugfixes, and the overall quality of the release. Open topics: - complete desktop branch merge into master (this seems generally done, but might need fine tuning) - enable 3D support (also done? Bugfixing) - discuss support for desktops (IIRC it was planned to have a longer supported LTS desktop version, we need a maintainer for that, if it happens) - check if remaining boards can / have been updated to LK5.10 (some were left out last release) - check possible u-boot updates - complete remaining Jira issues - cycle and check board support status (espressobin for example needs a new maintainer (otherwise EOS) @Pali maybe?) - late topics: - business meeting schedule - kernel config changes on arm64 Release Planning Meeting Agenda: Please add developers and more topics below, I will then also add them here. @Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava @Mangix @Pali

Hi, sorry for the late reply. Current state @Technicavolous : Hijax and I are pretty busy at the moment so project is progressing rather slow, but: Hijax is done with the final (?) revision of the power&serial mux board. You can check it out here: https://github.com/armbian/mpads/tree/serial-mux-updated Also we are working on the SD card muxing which is surprisingly hard: https://github.com/armbian/mpads/tree/sd-card-mux-redesign On the master branch I am working on the firmware for SD card muxer: https://github.com/armbian/mpads/tree/master (warning, the kicad files there are outdated. We should merge the branches). Current state of the software/hardware combo is something like: - Power/Serial working and controllable via i2c with a small script. - sd card can be selected via I2C and gets accessible to the host with STM32 - sd card can be attached to the slave. Main problem is stability and powering of the sdcards (related). Also there are some issues with the usb/mass storage driver in the STM32 but it is somewhat working.

Yes this rebuildability is something we have been thinking/working on for a while. There even is an existing Jira Ticket for it: https://armbian.atlassian.net/browse/AR-175?atlOrigin=eyJpIjoiN2FhZTgyMTIxZWMxNDA2NmE5NjIxOTEzYTI4YWNiNDAiLCJwIjoiaiJ9 and the original post As of know this has not been implemented (probably because no one had enough time / interest / motivation to do it). Maybe you can? We'd also need to define how many old tags we support and for how long...

You could figure out what armbian-config does when installing the bootloader and do it manually while changing the relevant paths to your SD card. Or copy the needed files to the new sd card with bootloader. armbian-config source: https://github.com/armbian/config You will find out, that armbian-config uses the nand-sata-install script: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install In there you find the call write_uboot_platform "$DIR" "${root_partition_device}" This function comes from the uboot package that you installed. Looking and the DL page of Odroid HC2 (https://www.armbian.com/odroid-hc1/) I see that it uses the XU4 packages. So I went and grabbed the uboot deb for XU4 (https://apt.armbian.com/pool/main/l/linux-u-boot-odroidxu4-current/) Then I extracted the deb and checked the platform_install.sh script inside: DIR=/usr/lib/linux-u-boot-current-odroidxu4_21.02.0-trunk.62_armhf write_uboot_platform () { if [[ $2 == /dev/mmcblk* && -b ${2}boot0 ]]; then local device=${2}boot0; echo 0 > /sys/block/$(basename $device)/force_ro; local is_emmc=1; signed_bl1_position=0; bl2_position=30; uboot_position=62; else local device=${2}; signed_bl1_position=1; bl2_position=31; uboot_position=63; fi; if [[ $is_emmc == 1 ]]; then tzsw_position=1502; else tzsw_position=1503; fi; env_position=2015; dd if=$1/bl1.bin.hardkernel of=$device seek=$signed_bl1_position conv=fsync > /dev/null 2>&1; dd if=$1/bl2.bin.hardkernel.720k_uboot of=$device seek=$bl2_position conv=fsync > /dev/null 2>&1; dd if=$1/u-boot-dtb.bin of=$device bs=512 seek=$uboot_position conv=fsync > /dev/null 2>&1; dd if=$1/tzsw.bin.hardkernel of=$device seek=$tzsw_position conv=fsync > /dev/null 2>&1; dd if=/dev/zero of=$device seek=$env_position bs=512 count=32 conv=fsync > /dev/null 2>&1 } write_uboot_platform_mtd () { if [[ -f $1/rkspi_loader.img ]]; then dd if=$1/rkspi_loader.img of=$2 conv=notrunc status=none > /dev/null 2>&1; else echo "SPI u-boot image not found!"; exit 1; fi } setup_write_uboot_platform () { local tmp=$(cat /proc/cmdline); tmp="${tmp##*root=}"; tmp="${tmp%% *}"; [[ -n $tmp ]] && local part=$(findfs $tmp 2>/dev/null); [[ -n $part ]] && local dev=$(lsblk -n -o PKNAME $part 2>/dev/null); [[ -n $dev && $dev == mmcblk* ]] && DEVICE="/dev/${dev}" } There I see the exact dd commands needed to write the uboot. In your case, (as you should have an installed uboot deb on the new sd card), I would only try to write a small script, taken from nand-sata-install that calls write_uboot_platform to the correct sd card. Have a backup ready I dont have an Odroid so can't test above steps. This should be seen as a general guide. Hope it helps, Heisath

Is there also a status page for the status page? Just to make sure, we know what to do, if the status page is not available

I assume the original thinking of the authors of fancontrol was, that when the programm crashes/unexpectedly get closed, it does not leave the fans at a low speed and possibly endanger the system. The fancontrol does not differentiate between shutdown and exit / kill. And from a system perspective it is much better to have annoying loud fans (but a cool and healthy system) than slowly burning away components while no sound is heard I guess that also answers your second question, if you comment those lines away, the fans wont auto speed up if fancontrol crashes or similar.

You need to assign a fix version. Compare yours https://armbian.atlassian.net/browse/AR-600 with this one from Igor: https://armbian.atlassian.net/browse/AR-630

This has been fixed via a patch to mvebu-current (LK5.10) so should be available via nightly or with the next armbian release : https://github.com/armbian/build/blob/master/patch/kernel/mvebu-current/0001-Revert-block-simplify-set_init_blocksize-to-regain-l.patch It is fixed in LK 5.11 in mainline, but unsure if Armbian will get LK5.11 on mvebu or if we wait until the next LTS kernel version.