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
<Tonymac32>
OPi header doesn't match the Tritium one
Elpaulo has quit [Read error: Connection reset by peer]
<lanefu>
hmm
<lanefu>
okay so here's the brainhurt
<lanefu>
compare your data for uart3 vs the opi image
<lanefu>
and then i'm going to tell you that uart3 is working
Elpaulo has joined #armbian
<Tonymac32>
:P I have sources listed for my info
<Tonymac32>
so then
<lanefu>
but assumoing uart1 and 3 are transposed
<lanefu>
my uart3 is where youe uart1 is and workign
<lanefu>
leaving the uart3 pins in fact being different then what i'm using for uart1
<Tonymac32>
yeah, your uart1 are living on the I2S pins
<lanefu>
thats why it sounds so good
<Tonymac32>
XD
<lanefu>
i mean i always knew the rpi compatible stuff was nonense
<lanefu>
but i guess it just means 5v, grnd adn 3.3v are in the same place when they say "rpi compatible header"
<Tonymac32>
haha well some try harder than others
<Tonymac32>
I'm assuming you can't use an I2S HAT on an OPi?
<lanefu>
dunno
<lanefu>
never had i2s hat
archetech has quit [Quit: Leaving]
<lanefu>
i have some newb questions
<Tonymac32>
if I2C, SPI, I2S and a UART are where they belong the rest of it is kind of free form
<lanefu>
H3 shows 2 SPI bus's? SPI0 SPI1
<Tonymac32>
ja
<lanefu>
does sdcard use spi? or is that its on thing
<lanefu>
SDIO i guess != SPI
<Tonymac32>
sdmmc is it's own peripheral
<Tonymac32>
SD cards can operate in a SPI mode though
<lanefu>
i'm still working out the end of world's scenerior where my expertise of automotive, basic carpentary, and IO bus's on Allwinner SoCs give me the edge over the others
<Tonymac32>
haha
<lanefu>
soooo do i move my hat to orangepi pc2, or do i rewire it for tritium lol
<Tonymac32>
This is your path, padawan
<Tonymac32>
XD
<lanefu>
it sounds cooler when i say i made a hat for the tritium
<Tonymac32>
:D
<[TheBug]>
LOL
archetech has joined #armbian
ChriChri_ has joined #armbian
ChriChri has quit [Ping timeout: 240 seconds]
ChriChri_ is now known as ChriChri
torv has quit [Ping timeout: 240 seconds]
<lanefu>
womp womp
<lanefu>
re-work fail
<lanefu>
maybe uart1 just isnt real
torv has joined #armbian
<Tonymac32>
...
<lanefu>
i'm like cross referencing all the .dtsi files now
<lanefu>
tomorrow i'll just put dupons directly on the t5 adn take my board out of fthe equation
<lanefu>
on that note you have a favorite cheap usb ttl?
<lanefu>
cuz just buying 10 of them sounds appealing
<Tonymac32>
I use CH340's on my boards, and friendlyARM has them on their adapters
<lanefu>
btw my 30"-ish TTL cable worked
<Tonymac32>
good
<lanefu>
so i've notcied a lot of stuff has the mounting hole spacing of the width of the RPI
<lanefu>
is there something special about that dimension
<Tonymac32>
58 mm center/center, I don't know
oida has quit [Ping timeout: 240 seconds]
oida has joined #armbian
stipa has quit [Ping timeout: 240 seconds]
stipa has joined #armbian
stipa_ has joined #armbian
stipa has quit [Ping timeout: 240 seconds]
comrade has quit [Ping timeout: 260 seconds]
comrade has joined #armbian
comrade is now known as Guest94644
Guest94644 has quit [Ping timeout: 256 seconds]
Guest94644 has joined #armbian
<ArmbianTwitter>
@silver0480 (haioh): @kobol_io #Helios64 default ramlog size setting (50MB) is too small, so causes random crash with armbian 20.11.4 :-( After disabling ramlog(ZRAM), no crash. but HEAVY reduce lifetime of microSD. (I already use 860EVO m.2 SSD for system,so no ploblem) https://tinyurl.com/y87pvadq (22s ago)
bzyx has quit [Read error: Connection reset by peer]
bzyx has joined #armbian
hackersCardgame_ has quit [Ping timeout: 240 seconds]
hackersCardgame_ has joined #armbian
emOne has quit [Read error: Connection reset by peer]
emOne has joined #armbian
emOne has quit [Changing host]
emOne has joined #armbian
<ArmbianTwitter>
@lanefu (Lane Jennison): @silver0480 @kobol_io There should be a configuration file in /etc/default/ to change the settings. Additionally the v21.02 Armbian release will offer even more granualar control https://tinyurl.com/yabz2wkr (27s ago)
emOne has quit [Read error: Connection reset by peer]
<lanefu>
Hi Werner!
<Werner>
Hey Lane
emOne has joined #armbian
emOne has joined #armbian
emOne has quit [Changing host]
emOne has quit [Ping timeout: 240 seconds]
raver has quit [Quit: Gateway shutdown]
raver has joined #armbian
emOne has joined #armbian
emOne has joined #armbian
emOne has quit [Ping timeout: 264 seconds]
<ArmbianTwitter>
@silver0480 (haioh): @lanefu @kobol_io Okay,waiting armbian 21.02. ( Workaround : Huge syslog by profile-sync-daemon, so I purge it. ) https://tinyurl.com/y9gmm865 (26s ago)
<lanefu>
Hmm i think he missed my point where i was telling him where to make it bigger
<Werner>
maybe
gediz0x539 has quit [Quit: Leaving]
<ArmbianTwitter>
@lanefu (Lane Jennison): @silver0480 @kobol_io cool.. but yeah you can make size bigger by editing /etc/default/armbian-zram-config https://tinyurl.com/y8pc2en4 (7s ago)
c0rnelius has quit [Quit: WeeChat 2.9]
c0rnelius has joined #armbian
<wooster>
thinking about trying to set up projectM music visualizer on a SBC. any recommendations for something with a decent CPU and integrated graphics? built in audio input ADC would be nice
<lanefu>
IgorPec: its not so much opi3 as it is the _other_ boards that use the same ethernet
<lanefu>
that need testing
<IgorPec>
yes, i do test others
<IgorPec>
almost done
<lanefu>
lol cool
<lanefu>
are you testing 5.9 and 5.10
<IgorPec>
only 5.10
<lanefu>
cool
<lanefu>
yeah IMHO when we cut current to 5.10... we shoudl _stay_ there for a while
<IgorPec>
exactly
<IgorPec>
we should do this prior to next major release
<IgorPec>
that one is to far away
<lanefu>
anyway maybe we can get to the meta package config intime for 21.02?
<lanefu>
or no
<IgorPec>
meta package for kernels?
<lanefu>
yeah
<IgorPec>
ah, not that crticial to risk troubles
emOne has joined #armbian
emOne has joined #armbian
<lanefu>
hmm i hope we can get to it by 21.05 then
<lanefu>
it will buy as a lot of stability.... and make it easier to offer optimized kernels for desktop, vs server etc (ex: enable virtualization on server)
<IgorPec>
1st it will bring troubles :) then
<lanefu>
i could argue we've already brought ourselves troubles
<lanefu>
opi3's updates prime example
<IgorPec>
by doing what we do ?:)
<lanefu>
yes
<lanefu>
lol
<IgorPec>
but meta packages will not fix troubles as such
<lanefu>
it lets us better assure the right sbc always gets the right kernel
<lanefu>
more stabilit for the user
<IgorPec>
but from the management perspective ... how to know?
<lanefu>
and lets us manage updates more safely
<IgorPec>
imaging that we would not have kernel families
<lanefu>
well i think that process would need to be designed
<lanefu>
but i mean we'd start with just defining the meta packages and then pointing them to our existing defaults
<IgorPec>
kernel family is already a meta package in one way
<lanefu>
we'd still have kernel families.. but the SBC would get a metapackage that would generally point to a family ec
<lanefu>
and ultimately it will let us really promise stability for our "supported" boards
<IgorPec>
this will not solve all problems
<lanefu>
lol i mean that's not a very strong agrument
<lanefu>
nothing will
<lanefu>
lol
<lanefu>
but i mean i think it positions us to solve problems and minimize mistakes
<lanefu>
and FIX mistakes
<lanefu>
i mean i know the dream is fewer kernels
<lanefu>
but honeslty i think our ability to manage kernels ofr all these stupid boards is our like biggest advantage to the masses
<lanefu>
and maybe that does mean fewer kernel builds on backend at some point
<IgorPec>
proper autotesting will contribute most
<lanefu>
honestly might bring us closer to that because of the granular control
<IgorPec>
so that we will be aware of the problems
<lanefu>
i'm certainly not disputing that need
<lanefu>
i think it pairs together
<IgorPec>
i am doing those tests manually now since automatic are so instable :)
<lanefu>
burn!!!!!
<lanefu>
lol
<lanefu>
so i guess really to improve on that testing
<lanefu>
we need PR messages to contain suggested test targets
<lanefu>
so that it doesnt have to guess everything
<lanefu>
and then the other is doing full test matrices where it makes sense
<IgorPec>
testing on devices is paralel so its 1 or 100
<lanefu>
so you're saying just testing all things always regardless of context of commit?
<IgorPec>
i would already hook that up, but currently tests are not good
<IgorPec>
yes
<lanefu>
hmm
<IgorPec>
apt update; upgrade, reboot
<lanefu>
ahh okay
<IgorPec>
just something minimal
<lanefu>
yeah i've been trying to think of ways to get a PXEboot config or something that would wipe and reprovision
<lanefu>
but know to sometimes.. not wipe
<IgorPec>
like to start with a clean build?
<lanefu>
yeah... fresh base image each test
<IgorPec>
that should by covered by our device in universal way
<IgorPec>
but yeah, that would be nice
<lanefu>
yeah well the sdmux thing makes it "easy"
<IgorPec>
that works everywhere
<lanefu>
but with or SPI flash boards n stuff we have some options
<lanefu>
i'e been trying to think through posibilties with that
<lanefu>
lvrpi's LOST tool is good inspiration
<IgorPec>
like donwloads from URL and flashes to emmc/USB?
<lanefu>
yep!
<lanefu>
it's fucking awesome
<lanefu>
i installed coreelec to my la frite the other night using it
<IgorPec>
can that works everywhere?
<lanefu>
just used the uboot menu and chose it
<lanefu>
i thin it coudl work in a lot of places, but we need to really understand uboot
<IgorPec>
so you need SPI and network support in uboot?
<lanefu>
yeah
<IgorPec>
if we cover rk3399 we cover half :)
<lanefu>
yeah rk and amlogic should be pretty doable
<lanefu>
ironically SPI flash has loweset priority on allwinner
<IgorPec>
yeah
<lanefu>
_also_ i read something interesting about rockchip
<lanefu>
because i guess it just has 1 SPI bus
<IgorPec>
you can hook more devices on it AFAIK
<lanefu>
anyway.. i think on some of the rockchip boards that don't haev onboard SPI, you coudl actually still use an wpi flash chip via correct GPIO pins
<lanefu>
lol "we" shoudl start requring SPI flash for LTS support for boards
<IgorPec>
that works everywhere i think
<IgorPec>
btw i think this Opi3 patch will be ok. just two devices fail
<IgorPec>
which could be for other reason. have to see console
<lanefu>
k whcih devices?
<IgorPec>
Orange Pi Zero2
<IgorPec>
which is anyway not relevant
<IgorPec>
and ZeroPi
<lanefu>
what's a zero pi
<IgorPec>
h3
<IgorPec>
with 1gb
<IgorPec>
gb nic
<lanefu>
lemme look in device tree for zero pi rela quick
<lanefu>
IgorPec: sorry i know i've asked this before.. what's the way to just have armbian check out soruces and apply patches and stop
<lanefu>
othe rthan ctrl-c
<lanefu>
lol
<IgorPec>
i use that :)
<IgorPec>
but there is some way ... like name of the function "prepare_patches"
<IgorPec>
or similar
<IgorPec>
just zeropi have troubles
<lanefu>
IgorPec: don't laugh but i've never used the CREATE_PATCHES flag before... that will make patches from my kernel source changes or no? usualy i just diff my way through it
<lanefu>
*git diff
<IgorPec>
it will create a nice looking patch which you can copy to the patches section
<IgorPec>
i can change directly in DT via armbian-config
<IgorPec>
i am on machine now
<lanefu>
oh yeah just change you're just chaning setting to phy-mode = "rgmii-id";
<IgorPec>
ok, lets see if it gets back
<IgorPec>
this device tree editor comes handy
<IgorPec>
yes, net is up
<IgorPec>
make a grep if any other board need change
<IgorPec>
and we support it
<lanefu>
k wrapping up patches
<IgorPec>
how is our tool for creating patches ? :)
archetech_ has joined #armbian
<kprasadvnsi[m]>
I have seen some tweets about WiFi SDcard. How they use to make testing easier?
drobo_00 has joined #armbian
archetech_ has quit [Client Quit]
archetech has quit [Ping timeout: 260 seconds]
<lanefu>
IgorPec: uhh its pretty nice... i used splitdiff -a to break the patches out to seperate files since different devices
drobo_01 has joined #armbian
<lanefu>
kprasadvnsi[m]: haha yeah i was digging into that but not worht the effort given we have a sdmux board in the works
<lanefu>
idea was be able to remimage the sdcards easily for testing
<lanefu>
IgorPec: just do patches for 5.10-dev?
<IgorPec>
yes
<stipa_>
!ping
<IgorPec>
5.9.y is going to be trashed
<kprasadvnsi[m]>
<lanefu "kprasadvnsi: haha yeah i was dig"> What is sdmux board?