* wens
was a sysadmin back in the day, then moved to kernel development
Jmabsd has quit [Quit: Leaving]
* macc24
opens a box
<macc24>
:O pinephone pro
<CounterPillow>
\o/
* macc24
:D
<CounterPillow>
What graphical UI are you planning on going with on that?
<macc24>
i'll probably make a custom one
<CounterPillow>
Neat
<CounterPillow>
also, good luck. :D
<mps>
wens: my 'journey' was opposite, from hardware design, kernel/os programming, system administration to financial apps programming nowadays
Tenkawa has joined #linux-rockchip
psydroid4 has joined #linux-rockchip
iyzsong has quit [Ping timeout: 276 seconds]
iyzsong has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
stikonas has quit [Remote host closed the connection]
stikonas has joined #linux-rockchip
lurchi_ is now known as lurchi__
<montjoie>
kernel dev is just continuation of sysadmin by other ways (clausewitz)
<mps>
montjoie: :)
<wens>
lol
matthias_bgg has quit [Quit: Leaving]
<montjoie>
whole history started just because I want temperature monitoring
<macc24>
i started with some gui app programming
<macc24>
nowadays i just hack everywhere i want
<macc24>
some firmware, some kernel, some application programming, some packaging and sometimes i whip out my soldering iron and hack on hardware itself
<Tenkawa>
wens: why do you laugh?
<wens>
Tenkawa: montjoie's comment was funny
<Tenkawa>
I didn't find it funny... it was very true
<Tenkawa>
Its exactly how I spent about 15 years in I.T.
<wens>
funny in a sad way?
<Tenkawa>
why sad?
<Tenkawa>
It is a great way to learn
<wens>
I don't know, depends on what you went through?
<Tenkawa>
I learned more about Linux and its internals (and Unix/Posix for that matter) using that method
<Tenkawa>
I also started originally in the 70's though so I had more background than some
<Tenkawa>
been a fun time :)
<CounterPillow>
I think my first programming experience was Visual Basic in Microsoft Excel at the age of 12, with which I made a little quiz because Excel's scripting had a fun way to draw GUIs which I liked a lot. And after that, Blitz3D.
<CounterPillow>
I think my first Linux was Ubuntu 7 livebooted on the family Windows Vista computer. It was very slow. :D
psydroid4 has quit [Ping timeout: 256 seconds]
<mps>
CounterPillow: yes, ubuntu is slow :D
Tenkawa has quit [Quit: ... ... ... ... ...]
psydroid2 has joined #linux-rockchip
Tenkawa has joined #linux-rockchip
psydroid2 has quit [Ping timeout: 240 seconds]
<Tenkawa>
Any thoughts... RK3568 on a Odroid-M1... ever seen this one?
<Tenkawa>
trying to isolate messages I should be fixing vs benign ones updating the kernel/dts moving this forward up the tree
<Tenkawa>
ahh appears to be kexec related... testing removing support since I won't need that
<CounterPillow>
Might be a problem with the firmware for which we still don't have the sources
<Tenkawa>
CounterPillow: I looked at the code more and LPI looks directly related to kexec and as far as I'm aware that's not supported anyway is it?
<Tenkawa>
(in the architecture)
<CounterPillow>
I don't know about this stuff at all unfortunately :(
<Tenkawa>
its the restarting a new kernel live in a running system
<Tenkawa>
without reboot... not many systems support it.. even in the x86 world well
<Tenkawa>
too many pieces and parts really
hexa- is now known as hexa
hexa is now known as h
vagrantc has joined #linux-rockchip
indy has quit [Ping timeout: 240 seconds]
indy has joined #linux-rockchip
lurchi__ is now known as lurchi_
<robmur01>
the problem with LPIs is twofold: once they're enabled there's not necessarily any way to disable them, and they work via in-memory state, thus once they *are* enabled, the interrupt controller may be writing to memory whenever it feels like
<robmur01>
it's most obviously an issue for kexec, because Linux does enable LPIs, therefore whatever you kexec into *after* Linux is liable to run into issues if it thinks it can use whatever memory the GIC is already using for LPI tables
<robmur01>
presumably in this case firmware is enabling LPIs before Linux even gets there
<Tenkawa>
robmur01: does arm socs even have the ability currently with current implementations to "safely" use kexec?
<robmur01>
other than the potential LPI issue, yes, kexec has been supported for years
<Tenkawa>
interesting... I haven't explored the implications of the interactions of kexec in a long time so I am definitely not versed in its interaction with the architecture..
<Tenkawa>
ok.. it didn't help "only" pulling kexec
<Tenkawa>
[ 0.000000] CPU0: Failed to disable LPIs
<Tenkawa>
so now I need to run kgdb and dig a little deeper
<robmur01>
well, unless you actually are kexec'ing there's nothing you can do
<robmur01>
if firmware is entering Linux with LPIs already enabled, that's what you get
<Tenkawa>
I just want to ensure the memory "truly" isn't corrupting and thats a false message
<Tenkawa>
this is a clean boot
lurchi_ is now known as lurchi__
<robmur01>
fair enough, in that case I'd check whether any interrupts are actually configured and capable of being asserted at that point
<robmur01>
booting with the kernel's "memtest" option while connected to a busy network with plenty of broadcast traffic is a good way of finding "firmware left the interface running" DMA bugs in general :)
<Tenkawa>
indeed
<Tenkawa>
mostly trying to update this ancient kernel
Bitweasil has joined #linux-rockchip
<Bitweasil>
Tenkawa, thanks, didn't know this existed.
<Bitweasil>
<3 my PBP.
<Tenkawa>
pinephone pro?
<Tenkawa>
er no.
<Tenkawa>
you said b not p
<Tenkawa>
pinebook?
<Tenkawa>
Bitweasil: yeah this is a very good informative channel
<Bitweasil>
PineBook Pro, yeah. RK3399.
lurchi__ is now known as lurchi_
<vagrantc>
also pretty happy with the pinebookpro
<vagrantc>
haven't been able to find source for the keyboard/trackpad firmware though
lurchi_ is now known as lurchi__
stikonas has quit [Remote host closed the connection]