Werner changed the topic of #armbian to: armbian - Linux for ARM development boards | Armbian 20.11 Tamandua released | 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
Hokedli has quit [Quit: Konversation terminated!]
archetech has quit [Quit: Leaving]
<lanefu>
Hush sounds like a uhhh interesting project
hackersCardgame_ has quit [Read error: Connection reset by peer]
hackersCardgame_ has joined #armbian
torv has quit [Ping timeout: 240 seconds]
torv has joined #armbian
oida has quit [Ping timeout: 240 seconds]
oida has joined #armbian
raver has quit [Ping timeout: 256 seconds]
raver has joined #armbian
ChriChri_ has joined #armbian
ChriChri has quit [Ping timeout: 260 seconds]
ChriChri_ is now known as ChriChri
hackersCardgame_ has quit [Read error: Connection reset by peer]
comrade has quit [Ping timeout: 258 seconds]
comrade has joined #armbian
comrade is now known as Guest81466
torv has quit [Remote host closed the connection]
torv has joined #armbian
stipa has quit [Quit: WeeChat 2.8]
hackersCardgame_ has joined #armbian
stipa has joined #armbian
sunshavi has quit [Ping timeout: 256 seconds]
hackersCardgame_ has quit [Read error: Connection reset by peer]
hackersCardgame_ has joined #armbian
hackersCardgame_ has quit [Read error: Connection reset by peer]
<bbt>
orangepi 3 latest kernel dosent work, i froze the version over a mnth ago, i just defroze it and did an update same poop. how do i downgrade kernel now, as i am stuck in sdcard chroot on another device with it?
<bbt>
or rather, how do i install previous firmware via apt?
<Werner>
#topic present tasks, bugs or project you are working on
ArmbianHelper changed the topic of #armbian to: present tasks, bugs or project you are working on (Meeting topic: Urubu Release Meeting)
<IgorPec>
allwinner people speak up
<IgorPec>
we fixed troubles with opi3 and kernel is ready for 5.10.y
<IgorPec>
also u-boot has been fixed. i think we don't have any major problems
<Werner>
would be neat to switch before release. also megi started working on 5.11 rc so we can push dev to this branch
<IgorPec>
its related to this major merge
<IgorPec>
safest way is to come out with 21.02 release on a current master branch
* lanefu
definietly thinks most stuff should goto 5.10.y.. IMHO treat it as LTS kernel
<IgorPec>
and just update kernels and uboots
<Werner>
it will be lts kernel
<lanefu>
yeah... i mean from us as well
<IgorPec>
5.10.y will stay for a while, but we have 5.9.y ATM
<IgorPec>
everywhere, not just with allwinner
<IgorPec>
the question is - when to release 21.02??
<IgorPec>
or do 21.01 in between?
<Werner>
nah, no need to force it imho
<IgorPec>
release 21.02 in january
<Heisath>
just release 21.02 in beginning of february
<martinayotte>
or in middle of Feb ...
<IgorPec>
opi3 is broken until then
<IgorPec>
that's the main concern. also i think we have some troubles with rockpi 4
<Werner>
opi3 is not fixed for 5.9?
<IgorPec>
nope
<martinayotte>
I will check OPi3 soon, I'm using WiFi, so maybe that is how glitches appears
<IgorPec>
also when we merge "desktop" branch, there will be many other problems we don't have right now
<IgorPec>
i suspect to have them. even codebase is relatively ok, it needs more people to find more troubles
<[TheBug]>
Morning
<lanefu>
so really we should just focus on kernel 5.10 and merging desktop branch for 21.02 release.... for OPI should we just publish an updated image with a frozen kernel?
<lanefu>
or let it the the first to use meta packages :P
<Werner>
or bump just sunxi to 5.10 and public bugfix release before
<IgorPec>
adding meta packages as a quick last moment hack? not happy:)
<Werner>
s/public/publish
<ArmbianHelper>
Werner meant to say: or bump just sunxi to 5.10 and publish bugfix release before
<lanefu>
IgorPec: yeah i was joking
<IgorPec>
ok, bugfix release
<lanefu>
actually yeah allwinner could goto 5.10 in advance and that'd be fine
<IgorPec>
for allwinner its must have, what about others?
<Werner>
#agreed bump sunxi to 5.10 and push bugfix release
<IgorPec>
meson64 and meson is also ok
<IgorPec>
rockchip not ready yet I think?
<jock>
rockchip32b should go fine with 5.10
<IgorPec>
aprayoga: helios64 and 5.10.y ?
<Heisath>
mvebu-dev is on 5.10 already, I have been testing it on clearfog could not find problems. I will test it on helios4 if @aprayoga hasn't.
<jock>
rk322x has dev already bumped to 5.10, not tested though
<aprayoga>
i haven't tested 5.10 on helios64
<IgorPec>
if we are unsure, we don't need to
<lanefu>
just to be clear.. we're talking about releasing a v20.11 bugfix for allwinner with 5.10.y...
<IgorPec>
yes
<lanefu>
k
<IgorPec>
bugfix release, where possible other kernels could be updated
<aprayoga>
i have tested 5.10 on helios4. i think we have to remove the dynamic freq scalling patch
<Heisath>
yeah that is removed in current. If we move 5.10 to current there will be no DFS
<lanefu>
do we have _known_ bugs
<lanefu>
where we need to rush out other kernels
<Werner>
only opi3 is urgend I think?
<lanefu>
IMHO 5.10.y sunxi bugfix.. for everything else plan on v21.02 release for 5.10.y and get teh testing done
<[TheBug]>
Running Linux rockstorage 5.10.0-rc7-rockchip64 #20.11.3 pretty mush stable on RockPI 4c - 09:16:45 up 9 days, 8:44
<IgorPec>
nothing recored. so let's do just sunxi then
<Heisath>
+
<[TheBug]>
has issues with #20.11.4 though
<IgorPec>
the rest goes on regular 21.02 path
<Werner>
#agreed bump other families to 5.10 regulary
archetech has joined #armbian
<Werner>
so pretty much done here?
<Werner>
*this topic
<IgorPec>
yes
<Werner>
#topic jira backlog
ArmbianHelper changed the topic of #armbian to: jira backlog (Meeting topic: Urubu Release Meeting)
<IgorPec>
so this also means we are merging "desktop" as planned?
<lanefu>
yeah
<Werner>
If rich is fine with sure why not
<lanefu>
i'd say 5.10.y and desktop branch merge should pretty much encompass the entire release
<IgorPec>
myy promised some better documentation prior to this
<lanefu>
myy has some time... there's good documentation in teh jira ticket
<lanefu>
just need ot extract it
<lanefu>
like covers architecture etc
<IgorPec>
well, we can leave it as is - we need to get known the system better
<IgorPec>
also code has to be cleaned the debug otherwise people will panic
<IgorPec>
that should be done ideally prior to merge
<lanefu>
okay so lets quickly describe the requirements to merge teh desktop branch in
<IgorPec>
in the following week and after
<lanefu>
* remove debug code * copy jira ticket documentation somewhere easier to find * confirm xfce works as expected
<IgorPec>
1. debug cleaning, redirecting to logs or removing if not needed
<IgorPec>
remember that CLI part also changed dramatically
<lanefu>
it has?
<Werner>
#todo desktop remove debug code, documentation, carefully test xfce
<lanefu>
oh because of package selection?
<IgorPec>
yes
<IgorPec>
packages are not anymore fixed in configuration.sh
<lanefu>
we should just make a default package setting that replicates our old set
<IgorPec>
how do you mean?
<lanefu>
well we have the app gruops right now
<IgorPec>
aha, you mean which is our default?
<lanefu>
just set some default choices.. and assumed them defined
<lanefu>
then for compile flag, and gui
<IgorPec>
like "browser, 3d, "
<lanefu>
CUSTOMIZE_APP_PACKAGES=yes
<lanefu>
to get prompted
<lanefu>
or USE_DEFAULT_APP_PACKAGES=no
<lanefu>
whatev
<lanefu>
then its backwards compatible
<lanefu>
which IMHO makes sense
<IgorPec>
ok, we have to do that ... add to the list
<lanefu>
from a like continuosu deliver perspective in enterprise apps... features are shipped in code, but activated seperately later
<lanefu>
you have desktop jira ticket handy? all add some subtasks
<IgorPec>
ok
<IgorPec>
anything else for the desktop ?
<IgorPec>
3d support enabling - when this will be realistic?
<IgorPec>
also new desktop branch comes with bleeding edge package base sid and hirsute ... so more experimenting is possible
<lanefu>
OH!
<lanefu>
need to switch to modesetting driver from fbdev wherever possible
<IgorPec>
ok
<lanefu>
rockchip is good to go with glamour
<lanefu>
amlogic.. needs to say NOGPU
<lanefu>
*stay
<IgorPec>
this has to be sorted out for the 21.02 i guess
<lanefu>
allwinner we need to wrap our head around.. i thikn it uses automagic defaults with X and that could be anything
<lanefu>
yep
<IgorPec>
any other major thing is going on and needs to be pushed to 21.02?
<IgorPec>
outside desktop and kernel upgrade?
<Werner>
discuss support/csc/wip state of boards but that is a different topic
<lanefu>
just assure apt-updates are super stable this round
<IgorPec>
we can do that if there is nothing specifically to sort out for lower levels
<lanefu>
nothing else important
<IgorPec>
apt updates - we find that bug for making mirrors out of sync
sunshavi has quit [Ping timeout: 272 seconds]
<IgorPec>
#topic infrastructure
<Werner>
#topic infrastructure
ArmbianHelper changed the topic of #armbian to: infrastructure (Meeting topic: Urubu Release Meeting)
<lanefu>
ahh yes.. "release strategy for mirrors"
<Werner>
#agreed make apt mirrors super stable and reliable :P
<IgorPec>
thebug perhaps you can sum up our mirrors ?
<[TheBug]>
well
<[TheBug]>
seems to be a bit more stable now
<[TheBug]>
been working on best sync methods and such over past month
<[TheBug]>
things seem to be keeping in sync as expected
<IgorPec>
any diff since we enabled geo location?
<[TheBug]>
also traffic looks to be smoothing out between them with Geoip implementation
<IgorPec>
or its too early
<lanefu>
"mirror validation"
<IgorPec>
that's planned to be developed, yeah
<IgorPec>
so we would have automatic add/remove of dead mirrors
Hose_Colonia has joined #armbian
<IgorPec>
this is now still manually ... and when we put out release, it takes some time to have things up everywhere
<lanefu>
well just gettin gvalidation i think we should have figured out
<lanefu>
automatic i care less about
<IgorPec>
yes
<lanefu>
just an easy way to validate mirror staging before publishing release
hackersCardgame_ has joined #armbian
<IgorPec>
regarding infrastructure - build server is in action. i don't trust him enough to send it to estonia yet. but its usable
<IgorPec>
it keeps beta repository and beta images up2date - if any change occour in code or up. that's the core point of CI lets say
<IgorPec>
also we have that arm server, which we try to put into CI action ... after native building is fully supported
<IgorPec>
currently its experimental (desktop branch feature only)
<Werner>
#todo further test the beast
<Werner>
#todo use arm server for ci
<IgorPec>
and hope for some bios update
<Heisath>
whats the problem with current bios?
<IgorPec>
its v1.0
<IgorPec>
there are some troubles, but not that critical
<IgorPec>
like nvme drives sometimes doesn't go into pci4.0 mode
<IgorPec>
ok. which boards to remove, CSC, WIP, ...
<Werner>
#topic discuss board support status
ArmbianHelper changed the topic of #armbian to: discuss board support status (Meeting topic: Urubu Release Meeting)
<Werner>
r4s to supported once piter gives green light
<IgorPec>
ok
<Werner>
#agreed support R4S (wait for Piter feedback)
<IgorPec>
what about those M1 and P1 ?
<IgorPec>
legacy kernel seems ... uff
<IgorPec>
what to do with pinebook pro?
<Werner>
without balbes fixes it is not very good
<IgorPec>
you mean legacy?
<Werner>
yeah
<lanefu>
Pinebook pro i think we shoud publish a lot of "preview" / unsupported images n stuff
<lanefu>
its gonna be a flagship desktop
<lanefu>
and having alll the desktop options will be very enticing
<Werner>
since this thing is meant to be a desktop box legacy is mandatory unless mainline becomes insanely better soon
<lanefu>
OH
<lanefu>
i think we need an official maintainer for PBP to move it past WIP
<IgorPec>
so we have to merge that dual kernel variant if we want to support it
<IgorPec>
kernel chaning nightmare
<IgorPec>
speaking on this - i hope the-going fixes this - armbian-config kernel changing
<Werner>
#info "i hope the-going fixes this - armbian-config kernel changing"
<IgorPec>
who can be official pinebook maintainer? and that its not you :)
<lanefu>
need to recruit
<lanefu>
i have 1.5 pinebooks being shipped to me
<IgorPec>
a recruiter to recrouit :)
<Werner>
they cut one in half?
<lanefu>
i'll keep the half one for testing
<lanefu>
its the motherboard only
<Werner>
ah
<lanefu>
so great for console etc
<IgorPec>
we need to you for more important things that tweaking pbpro
<lanefu>
yeah
<lanefu>
anyway teh whole pinebook pro i'm planning on sending to a very special guy in TN who's been working on desktop shit for months
<IgorPec>
ok
<Werner>
great
<lanefu>
so maybe he can keep up with the desktop experience
<lanefu>
and we can help with the hardware
<lanefu>
plus we'll have a "half a pinebook pro" in a test farm :P
<IgorPec>
se requirement for pbpro to be supported is by having a maintaner. at least one
<lanefu>
yeah
<Werner>
#help maintainer for pinebook pro needed
<IgorPec>
any board to remove support status?
<lanefu>
ebin
<lanefu>
to CSC
<IgorPec>
agree
<IgorPec>
also fire3/T3/t3+
<Werner>
#agreed espressobin to csc
<IgorPec>
imx6?
<lanefu>
what about SOPINE and other goofy stuff
<IgorPec>
that's also exotics
<IgorPec>
but apparently works fine
<Werner>
do they cause trouble yet?
<IgorPec>
prinebook a64
<lanefu>
just cuz they work doesn't mean they can't be CSC
<lanefu>
supported means we care about it
<ikmaak>
please keep A64 in!
<IgorPec>
pineboo64 was moved to 5.4.y kernel as its the only one where display works
<martinayotte>
Pinebook-A64 still has screen troubles with kernel > 5.7.y
<lanefu>
just to be clear.. we still publish CSC or WIP images right?
<IgorPec>
yes
<martinayotte>
I've never figured out why ...
<lanefu>
then yeah we should move a ton of shit to CSC
<martinayotte>
It is not a DT issue, but kernel
<IgorPec>
probably they messed up the driver
<IgorPec>
when dealing with Pinephone / TAB
<IgorPec>
i was looking into that direction, but didn't had time for deep dive yet
<martinayotte>
Maybe ...
<Werner>
hm maybe ask megi if he has clue? his branch is dedicated to pine stuff
<IgorPec>
but pine probably already forget about pinebook a64
<IgorPec>
i used it as a text terminal
<IgorPec>
ok, what else to remove the status that we agree upon?
<lanefu>
lol actually in their december news letter they said they tried to get teh PBP board to work inside it a they promised orignally.. but just no good for cooling in plastisc case etc
<lanefu>
R69?
<IgorPec>
what's r69?
<lanefu>
sunvell r69 tv box
<lanefu>
h2
<[TheBug]>
its just H3
<IgorPec>
is it supported?
<[TheBug]>
biggest change is dram asjustments in uboot
<lanefu>
hmm i sware it was
<[TheBug]>
adjustments* as they use poor quality ram in them
<[TheBug]>
otherwise generic uboot / kernel works on it
<lanefu>
apparently not
<[TheBug]>
?
<lanefu>
r69 is alreayd csc
<[TheBug]>
I mean really you can run OrangePi Plus 2e image on it with some dram adjustments
<lanefu>
we must have moved it
<IgorPec>
ok
<Werner>
its not even listed on the download section
<lanefu>
what abotu teres A64
<IgorPec>
also csc i would say
<IgorPec>
i think we clean this enough
<IgorPec>
for now
<lanefu>
cool
<lanefu>
"less is more" lol
<Werner>
So more or less A64 to csc in general?
<IgorPec>
after this meeting lets do some Jira cleaning adding info re-prioritise
<IgorPec>
A64 is good
<IgorPec>
but exotics
<Werner>
#agreed Teres A64 to csc
<IgorPec>
also pinebook would be nice to have fixed on 5.10->
<IgorPec>
but currently we have a working workaround and provide legacy 5.4.y images
<martinayotte>
I will check again for Pinebook-A64 using newer 5.11.y ...
<Werner>
#topic choosing upcoming release officer
ArmbianHelper changed the topic of #armbian to: choosing upcoming release officer (Meeting topic: Urubu Release Meeting)
<IgorPec>
werner?
<Werner>
declined
<lanefu>
but you're so german and organized
<Werner>
one of those is true... :D
<IgorPec>
we need someone to ask us questions so we come out with usable content
<IgorPec>
that is the major role. we have a script, so not much can go wrong
<Heisath>
This is release officer for 20.02 or 20.05?
<IgorPec>
20.05
<Heisath>
ok should have time there. Sign me up
<IgorPec>
great!
<Werner>
#agreed heisath
<lanefu>
Heisath: and remember you have the power to change / improve the process!
<lanefu>
emphasis on improve
<lanefu>
rather than change lol
<IgorPec>
its already perfect :)=
<Heisath>
We'll see
<lanefu>
hey on that note
<IgorPec>
before we close ..
<IgorPec>
#topic misc
<Werner>
#topic misc
ArmbianHelper changed the topic of #armbian to: misc (Meeting topic: Urubu Release Meeting)
<lanefu>
i think we've been doing this style release for over a year now :P
<Heisath>
Works better than the old style.
<lanefu>
anyway it's something to celebrate
<IgorPec>
we were talking about to make a video meeting. perhaps like a "normal" socical gathering
<IgorPec>
outside this formal thing
<Heisath>
Regarding misc, I am working on the firmware for sd mux board, the HW seems to work (might need one more rev to get bugs out). But as I have never done much with STM32 I might need some help here. If anyone knows STM32 and has some time message me ;)
<lanefu>
yeah
<lanefu>
maybe a quarterly pre-release party
<IgorPec>
STM32: tonymac32 perhaps?
<lanefu>
Heisath: i'm in desperate need of mux board given my recent schenangians
<martinayotte>
I've some knowledge about STM32
<martinayotte>
Mainly STM32F103 and STM32F407
<lanefu>
misc item: Create a "Brand Kit" which is a repo of our logos in raw formats, HEx values of armbian colors, fonts, etc
<Heisath>
F103 is whats on here aswell (I think). Mainly I need I2C comms between a SBC (with i2ctools) and the STM (stm as slave).
<Heisath>
Ideally I'd like to use the default HAL_I2C layer, maybe you can link/provide some example?
<lanefu>
probably worth a periodic reminder on twitter or something
<IgorPec>
alright.
<lanefu>
with a screenshot
<lanefu>
lol
<IgorPec>
we can say official part is done?
<lanefu>
+
<Werner>
I think so
<martinayotte>
So, Happy New Year 2021 to all !
<Werner>
likewise :)
<Werner>
#endmeeting
ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | Armbian 20.11 Tamandua released | 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
<[TheBug]>
:)
* lanefu
going to look in jira and see if we have a good structure for desktop and CI initiatives
<ikmaak>
sorry, i did not notice i was speaking though an official meeting
<Werner>
oh well...should have tested this once again before the actual meeting...
<Werner>
no proper meetbot output :(
<IgorPec>
ikmaak: now you are in the logs :)
<lanefu>
booo
<lanefu>
Werner: lol i guess restart supybot prior to meeting
<Heisath>
So much for german and organized ...
<IgorPec>
hehe
<IgorPec>
don't worry about. we still have logs
<Werner>
yeah but that sucks. you dont use somthing for three month and it stops working...
<IgorPec>
this is expected in OSS world :)
<ikmaak>
still, i hope for the longlevity of A64, almost half of my devices are part of that family :)
<lanefu>
ikmaak: theyr'e not going anywhere... just not allocating or primary dev resources to A64...
<lanefu>
just need community to do PRs and help maintain
<ikmaak>
good :)
<lanefu>
we're trying to clear up confusion between what is armbain "supported" vs community supported
<lanefu>
as we can really only commit to a few boards ourselves
<lanefu>
or can get them started, but can't add the needed polish
<ikmaak>
so how long do devices stay on supported on average?
<ikmaak>
if counted in that way, ppl can decide on them because of the expected armbian support
<lanefu>
depends on the ecosystem
<martinayotte>
no worries : I've Pine64/Olinuxino-A64/OrangepiWin/Pinebook-A64 ...
<ikmaak>
i think armbian support can steer a lot of ppls choices
<lanefu>
really supported boards need some participation with the vendors, and need dedicated maintainers
<ikmaak>
i got the pphone, tab, sopine clusterboard, lime64 (and lime2)
<lanefu>
yeah it steers people's choices, also picks up for a LOT of slack by SBC and SoC vendors
<lanefu>
also our primary focus is mainline kernel.. not like a desktop expereince
<lanefu>
so people get displeased about acceleration support etc
<lanefu>
but we dont use teh janky stuff
<lanefu>
anyway its a tough crowd
<ikmaak>
i do not care about any graphics for now :)
<ikmaak>
the phone/tab do not do very exiting things with the screen
aprayoga has quit [Quit: Konversation terminated!]
<ikmaak>
in my case
<lanefu>
ha really?
<lanefu>
what do you use them for
<ikmaak>
mostly for making a infrastructure as code setup, so only a few actual users
<lanefu>
lol what's on teh screen
<ikmaak>
so the desktop parts are mainly just statusscreens with buttons
<lanefu>
oh cool
<lanefu>
man that reminds me th ere's some python library that can turn any python app into a basic gui
<IgorPec>
pygame
<IgorPec>
:)
<lanefu>
pygame is cool, but no there's something crazier
ArmbianHelper has quit [Remote host closed the connection]
ArmbianHelper has joined #armbian
ArmbianHelper has quit [Remote host closed the connection]
SteeMan has quit [Quit: Leaving]
ArmbianHelper has joined #armbian
ArmbianHelper has quit [Remote host closed the connection]
<Werner>
great... lanefu?
<lanefu>
hi
ArmbianHelper has joined #armbian
<Werner>
you remember the systemd files for the bots?
<lanefu>
yeah
<lanefu>
did i fuck one up?
<Werner>
no, i dont think so, just a question
<lanefu>
i actually dont think i messed with it
<lanefu>
but yeah i had to restart teh bot a fe wtimes while you were away
<Werner>
is there a way to give the command a folder with before executing? like cd /wherever and then start the bot
<Werner>
bc I now know what was wrong
<Werner>
it tried to write to / instead of /home/helper/bot...
<lanefu>
ohh yeah should be
<Werner>
If i start the bot via shell everythign works as expected but if I start it via systemd it assumes its path is / which is obviously not a good iea
<lanefu>
and i just decided to standardize my 64bit worker bees on the PineH64 surprisingly
<lanefu>
i guess i'll be solving that emmc DTS overlay situation
horiatm has joined #armbian
Heisath has quit [Quit: Leaving]
bd1308 has joined #armbian
jock has quit [Quit: Leaving]
archetech has quit [Quit: Konversation terminated!]
<bd1308>
\
<bd1308>
\C
<lanefu>
lol
<bd1308>
my bad, sorry
tmaurice has joined #armbian
<tmaurice>
yo! Anyone here running Armbian on a Helios 64, is there any significant perf/whatever differences between the buster flavour and the focal one ?
<Werner>
all flavors sharing the very same kernel package so you wont have any advantages/disadvantages in belongs of hardware support
<Werner>
So it is up to you of you prefer slightly older bug rock-solid userspace or slightly newer but just a fraction of all packages officially supported by cannonical...
Elpaulo has joined #armbian
<tmaurice>
Perfect :)
Elpaulo has quit [Quit: Elpaulo]
bd1308 has quit [Ping timeout: 272 seconds]
Guest81466 has quit [Ping timeout: 240 seconds]
horiatm has quit [Remote host closed the connection]
<ArmbianTwitter>
@themactep (Paul Philippov): Cheap @orangepizero board (H2+ Quad-core Cortex-A7, 512MB) with @armbian is a perfect host for my #ADSB station. Way more stable than old Raspberry Pi 1 model B (BCM 2835, 256MB) and more compact, too. https://t.co/vNwIMvZUt2https://tinyurl.com/y8pmqvkx (32s ago)
<Xogium>
a board that can overheat just cecause you're hanging in the bootloader is far from stable imo but heh
<Xogium>
granted… it overheats because of the hardware design and because u-boot ignores the interrupts the SoC is sending to let it know it is too damn hot
<Xogium>
*because
<Xogium>
which sounds kind of dumb
kffiatek has joined #armbian
kffiatek has quit [Quit: Leaving]
MrFixIt has joined #armbian
<Tony_mac32>
that is possible with 100% of modern SoC's
<Tony_mac32>
unless you closk them all to 500 MHz
<Tony_mac32>
permanently
<Tony_mac32>
and even then
<Tony_mac32>
if you hang somewhere and interrupts are ignored, game over
<Tony_mac32>
lanefu good catch, my H64B has been running great, nice
<stipa>
lanefu: oh, wow that was fast
<Tony_mac32>
lol bench supplies are only under so much demand :D
<lanefu>
stipa: it came next day, just been sitting on my floor
archetech has joined #armbian
<lanefu>
Its big and gnarly and analog... i kinda want a newer smaller crappier one thi
<lanefu>
*tho
<Tony_mac32>
the world is analog, digital is an illusion
<Tony_mac32>
:D
<stipa>
digital is analog wannabe
<stipa>
lanefu: i don't know, i would maybe take a look below that potentiometers
<stipa>
to see the quality of solder joints
<stipa>
but if you're layz you can skip that part and come to it if it becomes a problem
<stipa>
like intermittent response to your input or stuff like that
<stipa>
because we can't see what's there
<lanefu>
I looked it over before power up
<stipa>
from the pic i guess i see that solder din't flew to the other side of the board :\
<Tony_mac32>
just turn it up to it's highest voltage and short it out, that'll warm it up and fix any crappy joints
<Tony_mac32>
;)
<stipa>
right
<lanefu>
Solder didnt flow?
<stipa>
like you have pads on the both sides of the board and via that connects them
<stipa>
pins of the potentiometer goes in them
<lanefu>
Oh
<stipa>
if you solder on one side solder should end on the other side as well
<Tony_mac32>
yep
<stipa>
but maybe i'm mistaken
<stipa>
i can't see right that part of the PSU
<Tony_mac32>
well look at the joints on Q12, left side of the image
<Tony_mac32>
not inspiring
<Tony_mac32>
the rectifier doesn't look particularly healthy either, but it's hard to see clearly
<lanefu>
Should i just get another atx supply and stick to my breakout board
<stipa>
they bake SMD stuff in the oven and they do through hole compononents with crappy soldering irons that don't have enough power
<Tony_mac32>
sometimes they wave solder THT
<Tony_mac32>
but if the board isn't preheated, meh
<Tony_mac32>
given the plugs in the unpopulated holes, I'm guessing that was done here
<lanefu>
Whats wave solder
<Tony_mac32>
oh it's cool, you literally have a solder fountain
<ArmbianTwitter>
@armbian (armbian): RT @themactep: Cheap @orangepizero board (H2+ Quad-core Cortex-A7, 512MB) with @armbian is a perfect host for my #ADSB station. Way more st… https://tinyurl.com/y99mlj6ehttps://tinyurl.com/yaedjer3 (1s ago)
<stipa>
yeah, maybe it's wave soldered
<stipa>
well, you can use the psu, you can fix that later when your soldering skills get better...
<Tony_mac32>
on this srot of thing I usually check verify the output after making sure line and ground haven't been hooked up wrong
<Tony_mac32>
if anything is blatantly bad I'll retouch it
<stipa>
yeah, there are videos all over the YT with stuff from china and people open them befor the use and ther'e almost alwys something wrong
f476 has quit [Quit: Lost terminal]
f476 has joined #armbian
<Tony_mac32>
ugh my build isn't pulling new changes down, did we do that on purpose?
<Tony_mac32>
ugh where do we set the boot flags that isn't in the board conf for rockchip64? -_-
<IgorPec>
it doesn't pool if permission is fu* up
<Tony_mac32>
hmmm, it's a new install with no alterations
<IgorPec>
does it pool manually?
<IgorPec>
.ignore_changes
<Tony_mac32>
I didn't do that either
<Tony_mac32>
brand new out of the box
<IgorPec>
strange
<Tony_mac32>
shrugs
<Tony_mac32>
I'll try it again later, it does pull manually
<IgorPec>
you are running under root or user with sudo?
<Tony_mac32>
sudo
<IgorPec>
dunno
<IgorPec>
i expect such glitches when we merge desktop
<IgorPec>
:)
<IgorPec>
not before
<Tony_mac32>
it'll be fun!
<Tony_mac32>
haha
<IgorPec>
yeah, i bet it will be some troubles
<Tony_mac32>
hmmm, we should move some of these flags we added to rockchip64 to the board conf instead of having massive if statements
<IgorPec>
yes
<IgorPec>
that's the plan, but we have to set some unique procedure
<Tony_mac32>
friggin Rockchips
<Tony_mac32>
sticking RK3328 and RK3399 into the same family was always going to be trouble, but then add the ddr3/ddr4 mess, uuugh
<IgorPec>
yeah. we have to be careful to not make a mess bigger now
<IgorPec>
which is pretty easy :)
<IgorPec>
and which is why we didn't touch those things prior
<Tony_mac32>
we have a list of exceptions to the rules in rockchip64, like the 1 gb version of rock pi not booting with newer blobs, etc
<Tony_mac32>
(wtf is that even a thing)
<IgorPec>
its a reflection of this world
<Tony_mac32>
haha
<Tony_mac32>
It looks like only the PBP is using mainline ATF
<IgorPec>
others are to unstable or not work at all?
<Tony_mac32>
no idea, I think I'll start testing though, the PBP isn't special
<Tony_mac32>
although I guess we have the expert around. ;-)
<IgorPec>
piter is well accuanted with this
<Tony_mac32>
right, he's the one who reorganized the madness into something usable, the DRAM stuff looks complete enough that it should work, that's the only difference board to board as far as that goes
<Tony_mac32>
but the proof is in the pudding, so to speak
<Tony_mac32>
Piter's patch was merged after ATF 2.2, we could probably experiment with 2.4
<Tony_mac32>
igorpec I may have gotten into a bottle last night and slept through the meeting today :'(
<IgorPec>
haha, no problem about. we made it with some tehnical issues
<IgorPec>
metting assistant had some issues
<Tony_mac32>
I was reading the logs :)
<IgorPec>
i also had two lazy days, yesterday i wasn't functining much
<Tony_mac32>
I do know some STM32, btw, but probably not as much as martinayotte
<IgorPec>
yeah, i hope we can move that hw on
<Tony_mac32>
muxing SD is not trivial is the problem
<IgorPec>
also we will move testing to ansible
<IgorPec>
this scripting is also giving some headache
<IgorPec>
so its not just hardware to blame :)
<Tony_mac32>
haha
<Tony_mac32>
I hope we see some new processors soon, the workhorses of the low-cost community are getting feeble in their old age XD
<IgorPec>
rockchip should be around soon
<IgorPec>
olimex is doing something on imx
<IgorPec>
allwinner didn't say last word
<Tony_mac32>
imx is always pricey, speaking of I need to get that i.MX8 board spun up
<IgorPec>
yeah, imx8 never find the way to community
<Tony_mac32>
there are 2-3 boards out there, I have a Maax Mini
<IgorPec>
also imx6 was not much present
<Tony_mac32>
I also have the seeed studio one made by NPi
<Tony_mac32>
i.mx6
<IgorPec>
there is actually plenty of hw, but its "industrial"
<Tony_mac32>
the NXP parts have better documentation, but are expensive I guess
<IgorPec>
but also not working very well accoriding to my experiences with solidrun
<IgorPec>
BSP kernel is also pretty terrible
<Tony_mac32>
If you want terrible I have a chameleon96 SoCFPGA board. XD
<Tony_mac32>
I have all 3 of these because they specifically fit things a hardware lab would want
<Tony_mac32>
for test/control
<IgorPec>
i know bigger shit do and can exists
<Tony_mac32>
haha that embedded cortex-M makes the imx's interesting
<Tony_mac32>
nothing else
<Tony_mac32>
XD
* Tony_mac32
looks over at opi-i96 and opi-4G
<Tony_mac32>
I honestly don't like the 96boards standards, they picked all the "almost standard but not quite" hardware
<IgorPec>
only among their client base?
<IgorPec>
opi4g. that would be nice to have FOSS stack
<Tony_mac32>
it's just the 1.8V I/O, 2 mm headers, using a socket instead of pins for the expansion, etc
<IgorPec>
if you are not making things different, who will know you are making a standard ?:)
<Tony_mac32>
hahahaha
<Tony_mac32>
I work for Germans. ;)
archetech has quit [Remote host closed the connection]
archetech has joined #armbian
hackersCardgame_ has quit [Ping timeout: 240 seconds]