Hans Kurscheidt
-
Posts
37 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by Hans Kurscheidt
-
-
vor 2 Minuten schrieb Igor:
Remove -legacy- kernels from the system
I think, I asked you this question already. How to do this?? armbian-config doesn't have such cmd. Just deleting the legacy dirs in /boot??
RGDS
-
OK, so I'm there!
but rather than doing a fresh install, I used the following method:
using armbian-config under kernel 6.1.92 to unfreeze
using armbian-config to switch to "other kernel" -> 6.6.44
That worked OK and gave me Debian Bullseye w/ kernel 6.6.44
I then edited /etc/apt/sources.list and /etc/apt/sources.list.d/armbian.list, replacing Bullseye w/ Bookworm. I then started apt-get update/upgrade. After a huge upgrade I ended up w/ Debian Bookworm, but had fallen back to kernel 6.1.104.
I then applied the method as described by robertoj to finally get Debian Bookworm w/ kernel 6.6.44
-
Well, I tried my very best to find a solution, just to run into other Armbian peculiarities.
1st, the problem with the missing signature can be solved by telling apt to ignore it.
ZitatUNSIGNED REPOSITORIES
If an archive has an unsigned Release file or no Release file at all current APT versions will refuse to download data from them by default in update operations and even if forced to download front-ends like apt-get(8) will require explicit confirmation if an installation request includes a package from such an unauthenticated archive.
You can force all APT clients to raise only warnings by setting the configuration option Acquire::AllowInsecureRepositories to true. Individual repositories can also be allowed to be insecure via the sources.list(5) option allow-insecure=yes. Note that insecure repositories are strongly discouraged and all options to force apt to continue supporting them will eventually be removed. Users also have the Trusted option available to disable even the warnings, but be sure to understand the implications as detailed in sources.list(5).
A repository which previously was authenticated but would loose this state in an update operation raises an error in all APT clients irrespective of the option to allow or forbid usage of insecure repositories. The error can be overcome by additionally setting Acquire::AllowDowngradeToInsecureRepositories to true or for Individual repositories with the sources.list(5) option allow-downgrade-to-insecure=yes.
Hence I created my apt.config settings in /etc/apt/apt.config.d as following:
cat 99mysettings Acquire::AllowInsecureRepositories "1"; Acquire::AllowWeakRepositories "0"; Acquire::AllowDowngradeToInsecureRepositories "1";So apt started to work on it, giving the appropriate warnings:
which I ignored, so it started the upgrade:
just to learn, that I'm stuck again w/ Armbian. something w/ "unknown compression"
-
I'm sorry, but you misinterpreted the screenshots.
Please refer to my 1st line in my 1st post:
>>>>I had to freeze my device on Kernel 6.1.92 & Bullseye to remain operational. Now trying to update/upgrade to Kernel 6.6.nn <<<<
I was always on Bullseye since years now and Kernel 6.1.92 frozen since early this year. Trying to move from 6.1.92 to 6.6.42 (switching kernel after defreeze in armbian-config) created a mess including throwing me back onto Buster, God knows why and how!
May be, that I am using a code that is not supported on a hardware that is not supported, but normal Linux' way of upgrade should still work and for the time being, I am almost sure, that the upgrade doesn't work, because you guys haven't created the proper public key for apt.security to accept the upgrade.
RGDS
hk
-
OK, I can certainly do this, but is this supposed 2b the "normal way" or isn't there an issue w/ signing the package, so that "normal" apt ops would do the trick?
BTW thanks 4 Help
BR
hk
-
Hi there,
as expected, in my frozen image, they are pointing to 6.1.92. After unfreeze and apt-get update/upgrade I'm now lifted to 6.1.104 & Bullseye
However its not want I want, 6.644. a new issued apt-get update/upgrade has no effect.
looks like a security issue to me, now. https://github.armbian.... is not signed
RGDS
hk
-
vor 15 Stunden schrieb Igor:
Uninstall one variant alongside with DT and headers if installed.
Thank-you for reply. Sorry for the beginners question, but "How to"? I used armbian-config
to move from 6.1.92 to 6.6.44 and I was assuming that 6.6.44 would replace 6.1.92; apparently it did not, as you said in your reply. So how can I make 6.6.44 the new 1 and only new kernel. I currently back to my old image w/ kernel 6.1.92 frozen and Debian Bullseye. I have a complex APP with tons of middleware and 3rd party SW; a fresh new installation would be a PITA.
-
I had to freeze my device on Kernel 6.1.92 & Bullseye to remain operational. Now trying to update/upgrade to Kernel 6.6.nn I run into following probs:
1) Using Armbian-config defreeze and subsequently switch to kernel 6.6.nn works OK 4me, but subsequent apt-get update/upgrade throws me back to kernel 6.1.104. Armbian-config has changed significantly w/ No other Kernel available.
2) Using Armbian-config defreeze, only and going directly to apt-get update/upgrade throws me back to kernel 6.1.104 as well and from Bullseye back to Buster! Its a mess!
Will this eventually be corrected and when?
RGDS
-
The internet is full of reports, that USB devices get disconnected at random after some time. Camera or disc-drives, keyboards etc. For me it was a GPS device.
The solution is described here https://hamwaves.com/usb.autosuspend/en/
and here https://www.kernel.org/doc/Documentation/usb/power-management.txt
-
vor 15 Stunden schrieb going:
This problem will not be considered by the armbian maintainers.
I'll try to explain.
This problem relates to the work\development of the kernel gpio subsystem.
The kernel has a corresponding gpio driver for the Raspberry Board.For boards using Allwinner processors, there is no native driver in the kernel yet.
Armbian members are not developers of kernel drivers.
My and your personal interest in the gpio topic and the fact that you and I are discussing it here is relevant only to us.
I will return to development only in late autumn. If my actions are successful. I'll let you know.
But again, this is only a personal initiative.Thank you very much. Its understood and appreciated! However I hope that the old sysfs i/f will stay in place until the issue will be solved.
-
After this open problem has ended up in "old bug tracker (read only)", I would like to bring this up here again. Could somebody please illuminate my ignorance, how this issue will be treated further?
RGDS
hk
-
vor 19 Stunden schrieb usual user:
The task of my discussion was to define a uniform GPIO naming scheme for the 40-pin connector of different devices, so that if e.g. user space addresses "con1-07", it does not matter on which device it is executed.
This is in fact an excellent idea! the key word is UNIFORM
@going:
For the time being, gpiod can only handle PIO; why block something very useful for something which does not yet exist (UART etc. func. in gpiod) Today, Users have no chances to find the pin, they are looking for. One has to scroll through 645 pages of chip documentation to understand which logical pin is allocated in which chipset. After this, the user has to crawl through the schematics to understand which SoC-Pin is connected to which Pin-header. Names like con1-xy would make things clear right from the beginning!
-
its all about these:
-
Let me more precise; pse follow the following simple recipe w/ gpiod V1.65+ installed:
Power up
Connect 1 Pin of your choice to GND using a patch wire
Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset> // rising edge, pull-up, exit after 1 event
expected behavior: cmd should "hang" and wait for rising edge @ Pin
Pull the wire
expected behavior: cmd should exit w/ event and timestamp
Reconnect the patch wire to ground, then
Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>
expected behavior: cmd should "hang" and wait for rising edge @ Pin
failure: cmd exits immediately w/ false event and timestamp although there was no rising edge (Pin was wired to GND)
Exe the same cmd a 2nd time w/out having touched the wire: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>
expected behavior: cmd should "hang" and wait for rising edge @ Pin
Now pull the wire
expected behavior: cmd should exit w/ event and timestamp
Leave the wire open (Pull-up will pull the Pin permanently up
Exe: sudo gpiomon -r -n1 -Bpull-up <chip> <offset>
expected behavior: cmd should "hang" and wait for rising edge @ Pin
failure: cmd exits w/ false event and timestamp although there was no rising edge (Pin was permanently high)
all subsequent calls to gpiomon will fail w/ false event (behavior as "Level" Interrupt)
- The issue is most likely related to initialization problems. Pins can be connected to various points internally in the SoC. UART, I2C, PIO... as well to pull-up/down, Highend/lowend FETS, etc. To do this, an internal microcode needs to be executed in the chip. In many uControllers, the Pin becomes unstable during the execution of the uCode. I expect that upon each execution of the gpiomon cmd, the pin is newly initialized. The new 2nd & ff initializations could lead to a false rising edge flag in the chip register, which will then trigger a spurious interrupt, when enabled. I suggest to consider, writing the chip config registers only after reading them before and in case that the new config would be different, from what was read back, before.
- Attaching the wire/button to a pin leads to line bouncing effects. The rising edge flag in the SoC may be re-triggered during the ISR execution of the 1st rising edge. The next execution of gpiomon, which will enable interrupts again, will then be trapped by the pending int flag. Enabling interrupts in the SoC PIO should always happen, after making sure that there is no pending int-flag, somewhere.
RGDS
hk
-
Hello, again,
Nobody feeling responsible for this??
When this issue would be solved, gpiod V. 1.65 +newer could indeed become an acceptable utility replacing the depreciated sysfs feature for future development.
RGDS
hk
-
vor 10 Stunden schrieb schwar3kat:
I've not looked at permissions for gpoid. The file would probably need to be tweaked to cover the device structure.
I just changed /dev/gpiochip* to group "gpio" as I did for sysfs, and gpiod now works w/out root priv.
Wouldn't it be a good idea to put the rules file for sysfs and /dev/gpiochip* into the normal distro??
-
Hi Kat,
appears to be working.
Welcome to Armbian 22.02.1 with Linux 5.15.32-sunxi64 System load: 19% Up time: 0 min Memory usage: 22% of 482M IP: 192.168.1.37 192.168.100.1 CPU temp: 53°C Usage of /: 24% of 29G RX today: 39.5 MiB [ General system configuration (beta): armbian-config ] Last login: Wed Apr 6 11:04:11 2022 from 192.168.1.31 hk@orangepizeroplus:~$ uname -a Linux orangepizeroplus 5.15.32-sunxi64 #trunk.0038 SMP Thu Apr 7 15:18:59 UTC 2022 aarch64 GNU/Linux hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 -rwxrwx--- 1 root gpio 4096 Apr 7 20:56 export lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 -rwxrwx--- 1 root gpio 4096 Apr 7 20:56 unexport hk@orangepizeroplus:~$ echo 6 > /sys/class/gpio/export hk@orangepizeroplus:~$ ll /sys/class/gpio total 0 -rwxrwx--- 1 root gpio 4096 Apr 7 20:59 export lrwxrwxrwx 1 root gpio 0 Apr 7 20:59 gpio6 -> ../../devices/platform/soc/1c20800.pinctrl/gpiochip1/gpio/gpio6 lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root gpio 0 Apr 7 20:56 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 -rwxrwx--- 1 root gpio 4096 Apr 7 20:56 unexport hk@orangepizeroplus:~$ gpiodetect gpiochip0 Permission denied Segmentation fault hk@orangepizeroplus:~$ sudo gpiodetect [sudo] password for hk: gpiochip0 [1f02c00.pinctrl] (32 lines) gpiochip1 [1c20800.pinctrl] (224 lines) hk@orangepizeroplus:~$ gpio readall +-----+-----+----------+------+-Orange Pi Zero 2-+------+----------+-----+-----+ | H5 | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | H5 | +-----+-----+----------+------+---+----++----+---+------+----------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 12 | 8 | SDA.0 | ALT3 | 0 | 3 || 4 | | | 5V | | | | 11 | 9 | SCL.0 | ALT3 | 0 | 5 || 6 | | | 0v | | | | 6 | 7 | GPIO.7 | ALT3 | 0 | 7 || 8 | 0 | ALT3 | TxD3 | 15 | 198 | | | | 0v | | | 9 || 10 | 0 | ALT3 | RxD3 | 16 | 199 | | 1 | 0 | RxD2 | ALT3 | 0 | 11 || 12 | 0 | ALT3 | GPIO.1 | 1 | 7 | | 0 | 2 | TxD2 | ALT3 | 0 | 13 || 14 | | | 0v | | | | 3 | 3 | CTS2 | ALT3 | 0 | 15 || 16 | 0 | ALT4 | GPIO.4 | 4 | 19 | | | | 3.3v | | | 17 || 18 | 0 | ALT4 | GPIO.5 | 5 | 18 | | 15 | 12 | MOSI | ALT3 | 0 | 19 || 20 | | | 0v | | | | 16 | 13 | MISO | ALT3 | 0 | 21 || 22 | 0 | ALT3 | RTS2 | 6 | 2 | | 14 | 14 | SCLK | ALT3 | 0 | 23 || 24 | 0 | ALT3 | CE0 | 10 | 13 | | | | 0v | | | 25 || 26 | 0 | ALT3 | GPIO.11 | 11 | 10 | +-----+-----+----------+------+---+---LEDs---+---+------+----------+-----+-----+ | 17 | 30 | STAT-LED | OUT | 0 | 27 || 28 | | | PWR-LED | | | +-----+-----+----------+------+---+-----+----+---+------+----------+-----+-----+ | H5 | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | H5 | +-----+-----+----------+------+-Orange Pi Zero 2-+---+------+---------+-----+--+ hk@orangepizeroplus:~$gpiod apparently cannot make use of the gpio group permission. WiringPi as usual.
I put it onto my "compiler engine" (Visual Studio 2022 CPP cross env w/ OPi0+ as target). I have a few long haul flights in Mai, so I don't want to risk messing things up. Therefore, I will stay w/ 5.10 on my production machine for the next 2 month. How will things move on from here? When and where will this become "regular" instead of nightly?
Thank-you very much to you and all the guys in the background (followed discussion on GitHub) for your swift action!!!!
Best Regards
hk
-
Dears,
I have recently posted several issues wrt. OPi0+. GPIO (sysfs), armbian-config (bug confirmed by Igor), WiFi AP, GPIO event handling. Except for GPIO, where high activity is going on, I cannot find anything in "GitHub-issues" about the other problems, I have raised. I therefore would like to know, what would be the right place to rise issues? Here in the forum, or in GitHub?
I mean "issues", not "how tos"
-
Cannot set internal pull-ups!
Moreover I don't want to go on "somebodies" git page to look for solutions, which may be abandoned, tomorrow. If the Debian Kernel makers decide to stop and remove a widely used i/f by surprise, they have the obligation to provide a widely working and well documented new solution for USERS !
I don't see anything like this. Forcing users to search git up&down, retro-engineer code and .h files is no documentation. And distributing a version of e.g. gpiod of 3-4 versions behind is no solution as well!
-
vor 4 Stunden schrieb schwar3kat:
Hans, you are missing a / in front of bin.
Holy cow! sorry for this!! Its working now. Thanks!
-
WRT dtb editing. May be I am old fashioned, but an APP for me is supposed to run on the designed HW "as is" i.e. it has to bring its own capability to configure the necessary i/f at user space, making eventually use of middleware. In my case, I achieve this by using sysfs and WiringPi. Apart from the fact that armbian-config has a bug and edits the wrong dtb, disasembling, editing & recompiling a dtb file is not for the average user and would my App put into the situation, where its not runnable on OPi0+ boards from the shelve, anymore. Or do you think that M$ Office would be so successful, if the users had to go into the BIOS of their MoBo to fiddle around w/ something??
-
vor 13 Stunden schrieb usual user:
gpio-event-mon -n gpiochip0 -o 4 -r -f -b 10000 ; shutdown
What & where is gpio-event-mon, and does it use the internal pull-up? And where is the documentation??
-
vor 13 Stunden schrieb going:
Did I understand correctly? Do you need the power off button on this board to work? Is that all?
@going
No! I use the OPi0+ on a PCB as MoBo as an EFIS w/ an Arduino Nano as analogue concentrator and GPIO extender w/ RS232, I2C, SPI, GPIO and a handful of sensors. Shutdown was just 1 function of it, I picked it as example, because its easy. The important issues for me to switch to the new i/f are the ability to use the internal pull-ups, because I don't want to make a new PCB revision w/ external pull-ups and a working event monitoring, which is not the case for gpiod on the OPi0+, as I stated before. The shutdown is initiated electronically w/ a MOSFET and an R/C combination & Optocoupler, where the MOSFET keeps the power 30 secs alive when the avionic switch is pulled off to enable a proper shutdown.
-
vor einer Stunde schrieb going:
please explain to me why the existence of the /sys/class/gpio interface is so important
Hi,
just go and write in your preferred method a shell script, for a GPIO Pin w/ pull-up and a button, to initiate shutdown, when the button is pressed.
In sysfs & WiringPi its about 10 lines of bash; hence I hope I'm asking you not too much.
RGDS
armbian-config does not show/set the real dtb settings
in Beginners
Posted
armbian-config has significantly changed in Bookworm/Kernel 6.6. It looks to me that its not reflecting the actual device settings. Please refer to the attached screenshot from /boot/armbianEnv.txt. Compared to Bullseye/Kernel 6.1.92 I see an additional line "fdt_overlays, where all the dtb settings from the new armbian-config appear,
fdt_overlays=sun50i-h5-analog-codec sun50i-h5-i2c1 sun50i-h5-tve sun50i-h5-uart2 sun50i-h5-usbhost0 sun50i-h5-usbhost1 sun50i-h5-usbhost2 sun50i-h5-usbhost3but they seem to not having any effect. In 6.1.92 this line does not exist. The real dtb settings are still in the line above
overlay_prefix=sun50i-h5 overlays=i2c1 uart1 usbhost0 usbhost1 usbhost2 usbhost3which is identical in 6.1.92 and 6.6.