Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Type 'help' for help | Logs: -> irc.armbian.com
BCMM has quit [Quit: Konversation terminated!]
TheCoffeMaker has quit [Ping timeout: 244 seconds]
TheCoffeMaker has joined #armbian
Tenkawa has joined #armbian
Tenkawa has quit [Quit: Leaving.]
cheakoirccloud has quit [Quit: Connection closed for inactivity]
flyback is now known as canucks
canucks is now known as flyback
<ArmbianTwitter> @cnxsoft (CNX Software): .@AllwinnerTech A64 based #3Dprinter control board that runs #Linux (OctoPrint / Klipper) on the Cortex-A53 cores, while handling real-time control on the AR100 OpenRISC core inside the SoC. #3dprinting #armbian #debian #realtime https://t.co/S52FYlojAZ https://tinyurl.com/y4v7wrsr (27s ago)
Maalth has joined #armbian
<Maalth> ,searchissue rdp
<ArmbianHelper> Nothing found.
<Maalth> ,searchissue remote
<ArmbianHelper> Nothing found.
Maalth has quit [Quit: Leaving]
sams has quit [Read error: Connection reset by peer]
jschwart has quit [Ping timeout: 272 seconds]
jschwart has joined #armbian
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #armbian
maknho____ has joined #armbian
maknho___ has quit [Ping timeout: 265 seconds]
flyback has quit [Ping timeout: 252 seconds]
flyback has joined #armbian
bashrc has joined #armbian
tiggilyboo has joined #armbian
maknho____ has quit [Ping timeout: 244 seconds]
tiggilyboo has quit [Ping timeout: 265 seconds]
maknho has joined #armbian
maknho_ has joined #armbian
maknho has quit [Ping timeout: 268 seconds]
Fat-Zer has quit [Ping timeout: 245 seconds]
maknho__ has joined #armbian
Fat-Zer has joined #armbian
maknho_ has quit [Ping timeout: 245 seconds]
<e3ef13f4ff44> hello
<e3ef13f4ff44> how is the work going on the orange pi zero 2?
psydroid has quit [Changing host]
psydroid has joined #armbian
shoragan has quit [Ping timeout: 272 seconds]
shoragan has joined #armbian
tiggilyboo has joined #armbian
BCMM has joined #armbian
tiggilyboo has quit [Ping timeout: 244 seconds]
maknho___ has joined #armbian
maknho__ has quit [Ping timeout: 245 seconds]
<nekomancer[m]> how to force `./compile` script not to clean-up after ctrl+c or error in compilation? I'd like to look to working set of files, env vars, and to try to change some with hands
<lanefu> Look for the "trap" statements in the scripts
<nekomancer[m]> error `E: [mergetrust] filter_elf ./build/rk322xh/debug/bl31/bl31.elf file failed
<nekomancer[m]> merge failed!` if build on `aarch64` platform.
<nekomancer[m]> mergetrust program itself runs with qemu
<nekomancer[m]> what can be wrong?
<nekomancer[m]> then result image boots and runs on SBC.
Tenkawa has joined #armbian
<lanefu> A lot of the arm trusted firmware stuff doesn't build well under arm and we need helo fixing it
<lanefu> s/helo/help
<ArmbianHelper> lanefu meant to say: A lot of the arm trusted firmware stuff doesn't build well under arm and we need help fixing it
<Tenkawa> lanefu: what kind of changes are you guys making to it thats making it not build well?
<Tenkawa> I just ran it this morning on my generic arm64 machine
<Tenkawa> -rw-r--r-- 1 root root 18312 Jun 5 09:25 arm-trusted-firmware-dbgsym_2.4+dfsg-2_arm64.deb
<Tenkawa> -rw-r--r-- 1 root root 58420 Jun 5 09:25 arm-trusted-firmware-tools-dbgsym_2.4+dfsg-2_arm64.deb
<Tenkawa> -rw-r--r-- 1 root root 26204 Jun 5 09:25 arm-trusted-firmware-tools_2.4+dfsg-2_arm64.deb
<Tenkawa> -rw-r--r-- 1 root root 122844 Jun 5 09:25 arm-trusted-firmware_2.4+dfsg-2_arm64.deb
<Tenkawa> but i run debian though
<nekomancer[m]> do you use armbian build script? can you provide full commnd-line to try on my sbc?
<Tenkawa> nekomancer[m]: as I said. I run generic debian64
* nekomancer[m] uses ubuntu
<Tenkawa> just sudo apt-get build-dep arm-trusted-firmware arm-trusted-firmware-tools then sudo apt-get -b source arm-trusted-firmware arm-trusted-firmware-tools
<nekomancer[m]> nice. you are expert. I am not. I just run armbian build csript and see a warning in process.
<Tenkawa> I build full images for debian/ubuntu/devuan with this soc so it has all 3 repos deb-src in it
<Tenkawa> ahh
<Tenkawa> nekomancer[m]: I did this for a living
<nekomancer[m]> I don't know what this warning means.
<Tenkawa> whats it say (feel free to msg if its a lot of output)
<lanefu> Tenkawa: lol i honestly don't even know. The armbian build scripts were a build from x86 design and build from arm is functionality thats been adddd the past year. Some of the amlogic stuff has the most trouble i believe
<lanefu> nekomancer[m]: https://armbian.lane-fu.com/linx/ is a sweet pastebin
<Fat-Zer> Tenkawa: hi, about my wifi question from yesterday... sorry I fell asleep a bit early...
<Fat-Zer> as for now the situation is the same...
<nekomancer[m]> Tenkawa: I start private chat with you. do you see it, or, possible, it lost between irc and matrix?
<Tenkawa> ooops soryr
<Tenkawa> er soory
<Tenkawa> let me look
<Tenkawa> no.. i didnt see it
<Tenkawa> its not here
<nekomancer[m]> it lost
<Tenkawa> just a sec
<nekomancer[m]> Tenkawa: all I see aout that error on screen: https://armbian.lane-fu.com/linx/meb94lgv.txt
<Tenkawa> ok I'll look there
<Fat-Zer> I've tryid set up correct value in /etc/default/crda: it didn't worked at first, but after updating crda I've got correct values in `iw reg get` and can change those with `set`
<Tenkawa> Fat-Zer: cool :)
<Tenkawa> glad that worked
<Tenkawa> I was partially on to something
<Fat-Zer> also tried the brcmfmac43456-sdio.clm_blob from RPi's github but had no luck with it either...
<Tenkawa> had the "area" right at least
<Fat-Zer> Tenkawa: that didn't... =(
<Tenkawa> I thought you said after updating crda you can set
<Fat-Zer> I can set but it seems the adapter just ignores the values...
<Tenkawa> nekomancer[m]: that message looks familiar
<Fat-Zer> although iw reg shows only global values and no adapter-specific one...
<Tenkawa> Fat-Zer: unfortunately I know nothing about that specific unit. a person I know does is away on holiday right now
<Tenkawa> nekomancer[m]: looking it up
<Tenkawa> nekomancer[m]: what version of ubuntu you on?
<c0rnelius> Is Armbian not using mainline u-boot for Rockchip?
<Tenkawa> c0rnelius: I was wondering.. it looks modified
<nekomancer[m]> <Tenkawa "nekomancer: what version of ubun"> this run was on focal
<Fat-Zer> Tenkawa: ok... thanks for your input anyway... it was quite helpful... I'll probably try to post on the forum regard the issue...
<c0rnelius> Because there is no reason for trust if they were. Simply cp/mv the elf into the uboot dir and compile.
<nekomancer[m]> but on hirsute near the same
<Tenkawa> nekomancer[m]: I agree with c0rnelius... you shouldn't need it at all
<nekomancer[m]> Tenkawa: generaly I have to add liprary path to qemu call to get this result.
<nekomancer[m]> it's not trunk of armbian
<nekomancer[m]> hope, yet.
<Tenkawa> I did notice though in x86 all you can compile natively is the tools.. I use arm boxes as my workstations so I can compile both natively
<Tenkawa> the tools and the signed code i tself
<Tenkawa> (without qemu)
<nekomancer[m]> then that tools can be just taken from ubuntu repos?
<stipa> Fat-Zer: set channel on Acces Point on 6 and try
<Fat-Zer> stipa: channel 1—11 seems to work fine... 12—13 are the problem...
<nekomancer[m]> in script it is `$SRC/cache/sources/rkbin-tools//tools/trust_merger --replace bl31.elf $RKBIN_DIR/$BL31_BLOB trust.ini`
<stipa> Fat-Zer: probably chip doesn't support those channels
<stipa> or driver for it
<Fat-Zer> stipa: shouldn't be the chip (physical) problem... might be the driver or the frimware one though...
<Fat-Zer> also `iw phy` says it supports all the channels upto 14: http://paste.debian.net/1200101/
<stipa> right, that crap info says alot of things
<stipa> i guess noone even edits that file while writing a wifi driver for linux
<Fat-Zer> =)
<stipa> it's the only info you can rely on and it's total crap
<Fat-Zer> by the word, do you know, if it comes from the generic wifi subsystem or from the driver?
<nekomancer[m]> <Tenkawa "just sudo apt-get build-dep arm-"> lookking inside https://packages.debian.org/bullseye/arm64/arm-trusted-firmware-tools/filelist and see no executable looks like `loaderimage` or `trust_merger` used in armbian builder. Maybe it something other?
<stipa> Fat-Zer: by guess i think there's no silicon on the chip that could support those channels
<Tenkawa> nekomancer[m]: run loaderimage -h
<Tenkawa> does it start with "The certificate generation tool"
<Fat-Zer> stipa: IMHO it's very unlikely...
<Tenkawa> nekomancer[m]: nevermind.. different binary
<Tenkawa> nekomancer[m]: the reaon that binary is missing is thats a rockchip repo specific git toolset
<Tenkawa> even Armbian is missing Rockchip u-boot patches
<Tenkawa> ie for the NanoPC-T4
tiggilyboo has joined #armbian
tiggilyboo has quit [Quit: tiggilyboo]
<stipa> Fat-Zer: you have to cut corners somewhere for such affordable chips
<stipa> driver designers wouldn't just leave that function out
<stipa> c0rnelius: can you connect to channel 13 with your rpi and braodcom wifi AC chip?
<stipa> with 2.4Ghz wifi
<Tenkawa> 2.4ghz ismt ac
<Tenkawa> er isnt
<Tenkawa> thats n
cheakoirccloud has joined #armbian
<stipa> ac chip supports both
<Tenkawa> not here
<stipa> i haven't come across a ac chip that doesn't support n,g... as well
<Tenkawa> north america:
<Tenkawa> 12 2467 2456–2478 NoB except CAN Yes Yes 13 2472 2461–2483 NoB Yes Yes 14 2484 2473–2495 No 11b onlyC No
<Tenkawa> no
<c0rnelius> when scanning I don't see that channel as an option on my network.
<Tenkawa> for chan 12 13 14
<Tenkawa> its illegal here
<stipa> Fat-Zer: c0rnelius | when scanning I don't see that channel as an option on my network.
<stipa> hmm
<Tenkawa> non-us.. japan.. yes
<Tenkawa> whats your region?
<stipa> haha
<Tenkawa> (if you dont mind me asking)
<stipa> whatever works
<stipa> on 2.4 it's country_code=GB
<Tenkawa> yeah you are not regulated to use that
<[TheBug]> I would say you probably need a specific firmware for it to allow that channel if it does since it falls outside what is usually certified for, past that I would check the specs on the chipset and see if it actually does support signaling on that channel before you tear your hair out. It may be more worth your time to invest in a 8$ dongle instead.
<Fat-Zer> russia... channels 12—13 are legal here as well as all over Europe..
<[TheBug]> right, but where the boards are mostly sold isn't russia
<[TheBug]> it's China, US, EU
<[TheBug]> so its certified for there
<[TheBug]> there is probably a different firmware for your locale
<[TheBug]> I thought maybe the one RPi post provided would be the one based on what it said
<[TheBug]> but I guess that didn't work out?
<Tenkawa> [TheBug]: no,, it is "NOT" certified for the US
<[TheBug]> CE*
<Tenkawa> that channel is illegal by the FCC
<[TheBug]> you are correct, but they manufacture under assumption a lot will import there
<[TheBug]> sorry to not be specific
<[TheBug]> it is usually CE certified if they are too cheap and generally that is pretty close to US requirements
<[TheBug]> lets see
<c0rnelius> Which model Pi? If I recall correctly the 2.4ghz firmware the foundation provides is a bit busted. Best to grab it from cypress.
<[TheBug]> Fat-Zer: sorry to be redundant, but if you will tell me the board and chipset again maybe I can help you dig some?
<Tenkawa> np.. just want to make syre everyone is on same page... hw certification and legalities can be a touchy area if someone gets caught
<Tenkawa> er sure
<c0rnelius> or just try my collection - https://github.com/pyavitz/firmware
<Tenkawa> yeah his work well
<[TheBug]> hmmm ^
<[TheBug]> well would you look at that
<Tenkawa> afk.. going to the market..
<Fat-Zer> TheBug: OrangePi3 / Allwinner H6 / brcmfmac43456
<Fat-Zer> you are probably right about the firmware — that was my first thought as well...
<Fat-Zer> *not the first one but sone of the initial...
<Fat-Zer> also I've tried to create a hotspot on those channels: and it fails as well...
<[TheBug]> Ohh yes, the blacksheep of the Allwinner family... ye ol' broken H6
<[TheBug]> Fat-Zer: check out c0rnelius's links and go through the one ins that github..
<[TheBug]> he seems to have a nice collection there
<c0rnelius> if you don't wanna over write whats installed sudo mkdir -p /lib/firmware/updates/brcm and place the firmware in the brcm dir.
<c0rnelius> By default it should be checked first, but you can also tell it too by placing this in ur cmdline - firmware_class.path=/lib/firmware/updates/brcm
<Fat-Zer> c0rnelius: TheBug: it seems the brcmfmac43456-sdio.* are the same as in https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm — already tried those... does it make any sense to try other files?
<Fat-Zer> I've looked through the driver code for creating an AP and it seems all it does is passes values to the firmware...
<Fat-Zer> I believe the problem is the firmware over zealous about enforcing national standards, so it's either:
<Fat-Zer> 1) might be locked to a certain region
<stipa> that chip should work out of the box since it's a clone with original broadcom driver but it soesn't wich signals that silicon is not so same as in the origianl broadcom chip
<Fat-Zer> 2) might be not told/improperly told by the driver about the region
<c0rnelius> the 2 broken bits I found were these - brcmfmac43430-sdio.bin brcmfmac43430-sdio.clm_blob which were related to 2.4ghz on some boards.
<c0rnelius> pi3b and zerow I believe?
sams has joined #armbian
<stipa> opi lite 2
<stipa> has the same chip
<stipa> it doesn't work as AP, in AC mode it's crushing network bridge in N mode the speed of connection drops with time for a client
<stipa> over time*
<stipa> so pretty much useless, don't know how it behaves in client mode
<stipa> all i know is that it doesnt support channels over 11 :D
<stipa> maybe someone will fix it
<stipa> till then i'll ditch it and use usb dongle instead
<stipa> but having opi3 and nonfunctional wifi and mpcie, that's bummer
<stipa> tbh i haven't pushed usb3 yet, who knows hw stable it is
<Fat-Zer> c0rnelius: tried fw from your collection anyway — no effect...
<Fat-Zer> a generic question: where the firmware is comming from, like in generfl?
<stipa> cypress
<c0rnelius> it should be cypress
<Fat-Zer> Is there any offitial source for it?
<stipa> cypress forum
<c0rnelius> is ur country code in both the wpa_supplicant file and crda?
<Fat-Zer> nope, in crda only...
<c0rnelius> I can't speak for other boards using this chip, but the foundation makes edits to the broadcom driver in the kernel in order for things to work correctly.
<Fat-Zer> "the foundation"?
<Fat-Zer> fsf?
<c0rnelius> the rpi kernel boys.
<Fat-Zer> oh...
<Fat-Zer> c0rnelius: and what wpa_supplicant file you were talking about?
<c0rnelius> Well if ur using NetworkManager its not needed.
<c0rnelius> But if you are a ifupdown fella like my else it would be located in /etc/wpa_supplicant
<c0rnelius> else/self*
<Fat-Zer> It's a bit shameful but I've never successfully managed to create an AP using wpa_supplicant >_<
<stipa> you do it with hostapd
<stipa> wpa_supplicant is for connecting to AP
<Fat-Zer> may be that was the main reason =))
<stipa> it's fucky
<stipa> you get more control over stuff, it's worth the hassle
<Fat-Zer> stipa: like what?
<Fat-Zer> I mean more control
<stipa> you get to se what's going under the NetworkManager service
<stipa> you can debug network faster
tiggilyboo has joined #armbian
<stipa> it's oke if you have DE and connect as a client
<stipa> but if your network is running linux then it's better to have more control over it
<stipa> my AP is actually running Armbian
<stipa> core of my network
<stipa> i have wifi repeater and it runs Manjaro
<stipa> it's not like some fuck AP with channel 13 you can't take a peek into
<stipa> fucky AP*
<stipa> more control*
<nekomancer[m]> stipa: maybe, you know how-to setup a wifi cellular network with roaming for home?
<stipa> it's called "WDS"
<stipa> Atheros chips can do it
<stipa> maybe Mediatek too, i'm not sure still
<nekomancer[m]> I mean infrastructure part.
<nekomancer[m]> you tell it shoul do a chip? not AC OS?
<stipa> yeah, chip
<stipa> it has to have that silicon
<stipa> it's hardware thing
<stipa> not like clients, they dont need to have that tech but APs do
<stipa> Ap's communicate
<stipa> and measure signals of clients and send that data to each other
<stipa> they work like one big AP
<nekomancer[m]> sad.
<stipa> i guess it could be done in software
<nekomancer[m]> mean routers >$70 with openwrt will not do it.
<stipa> i guess the card had to be able to work in both MOnitor & Client or AP mode at the same time and it could be done in software
<stipa> with python
<stipa> but agian, not all chips can work in monitor and ap or client mode at the same time
<cheakoirccloud> Is there a way to get the getty on serial console to spawn even if systemd-networkd-wait-online hangs? It's annoying to have to wait 2min every time.
<stipa> nekomancer[m]: it could be done cheaper with old pc and USB chip
<stipa> that supports WDS
<stipa> or an SBC
<stipa> for 50$ for sure
<stipa> but i haven't designed such a network so i can't tell if it all actually works
<stipa> it's in plan
<stipa> two chips could do it, that's two WDS APs
tiggilyboo has quit [Quit: tiggilyboo]
<stipa> cheakoirccloud: i guess that could have something to do with uboot
<stipa> maybe an option if it exist
<stipa> oh systemd-networkd-wait-online that's a service
<stipa> i had problems with that on Ubuntu before
lanefu has left #armbian [puting on human suit]
<cheakoirccloud> I'd like that service to block what it's blocking... but not block the serial console getty. This is actually what everybody wants, because network isn't needed for serial console.
<stipa> it's waiting for interface to connect somewhere
<stipa> you're telling one of your nics to connect somewhere and it hangs beacuse it can't connect
<stipa> either ethernet cable is unplugged or wifi it wants to connect doesn't exist
<stipa> so it's trying for 2 minutes and then gives up
<cheakoirccloud> Yes, and I'd like to login and bring up the interface... Instead of bringing up all the network stuff that can't work until the interface is up.
<cheakoirccloud> So systemd-networkd-wait-online is doing it's job, but getty shouldn't be waiting for that.
<cheakoirccloud> on any system.
<stipa> then disable systemd-networkd-wait-online
<stipa> start it manually when you login
<stipa> 'systemctl disable systemd-networkd-wait-online.service'
<stipa> it won't be in boot process then
<stipa> but you can start it manually whn you log in
<stipa> 'systemctl start systemd-networkd-wait-online.service'
<stipa> maybe you could set time to wait from 2 minutes to less somewhere in config files
<cheakoirccloud> I don't want to have to start systemd-networkd-wait-online every boot. I think getty is badly configured, there is no reason for it to depend on network.
<stipa> it doesn't
<stipa> it just spits what's on the screen
<stipa> if you were to connect real screen it would hang at the same place
<cheakoirccloud> That's bad too.
<stipa> yeah, i would maybe found an option to wait less than 2 mins and change it
<stipa> to 20 secs maybe
<cheakoirccloud> ohh, ic.
<cheakoirccloud> that would be perfect.
<e3ef13f4ff44> is anyone from russia?
<stipa> nekomancer[m]: Fat-Zer
<Fat-Zer> m?
<stipa> e3ef13f4ff44: is looking for someone from Rusiia
* nekomancer[m] not from Russia
<e3ef13f4ff44> Fat-Zer: https://www.youtube.com/watch?v=hrU65z0wOkI could you make a short summary what is he talking about this inverter?
<stipa> nekomancer[m]: my bad
<e3ef13f4ff44> i understand a little that he's complaining
<stipa> you can translate
<stipa> in options
<stipa> video options
<stipa> auto generated translation, not the best but it'll bring you to the ball park
<e3ef13f4ff44> there are no subtitles
<stipa> there aren't, my bad
<stipa> looks good to me
<stipa> there's some buzz
<Fat-Zer> e3ef13f4ff44: first he tries to plug in different load via a dimmer
<Fat-Zer> 100w bulb — works
<Fat-Zer> 2kw boiler dimed 10% — doesn't
<Fat-Zer> sry... a door bell...
<Fat-Zer> 400w grinder on slow — doesn't (as he claim it worked with another invertor marked for lesser wattage)... if started fast — works and triggers protection (as it should
<Fat-Zer> )
<Fat-Zer> then pretty much the same with 2 drills...
<Fat-Zer> when he checks if it charges another battery via charger plugged into an invertor — charger doesn't work
<e3ef13f4ff44> :)
<e3ef13f4ff44> thanks
<Fat-Zer> based on that all he claims that the invertor is weak and has some incorrect schematic...
<Fat-Zer> then he notices that the cooler fan blows outside...
<Fat-Zer> also the invertor stops working on 15.8v input instead of 16v as advertised...
<Fat-Zer> after all that he tries to plug in an AM receiver... when tuned onto a MW station — no additional noise, but got some additional noise when tuned to some SW static...
<Fat-Zer> that's pretty much it
<ArmbianTwitter> @armbian (armbian): RT @cnxsoft: .@AllwinnerTech A64 based #3Dprinter control board that runs #Linux (OctoPrint / Klipper) on the Cortex-A53 cores, while handl… https://tinyurl.com/y4vjc7zy https://tinyurl.com/y3gztv3o (13s ago)
Fat-Zer has quit [Ping timeout: 245 seconds]
Fat-Zer has joined #armbian
tiggilyboo has joined #armbian
bashrc has left #armbian [#armbian]
tiggilyboo has quit [Quit: tiggilyboo]
maknho____ has joined #armbian
maknho___ has quit [Ping timeout: 245 seconds]
stipa_ has joined #armbian
stipa has quit [Ping timeout: 245 seconds]
stipa_ is now known as stipa
marco44 has quit [Quit: ZNC 1.8.2+deb2~bpo10+1 - https://znc.in]
marco44 has joined #armbian
bd1308_ has quit [Ping timeout: 272 seconds]