ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
apritzel_ has quit [Ping timeout: 264 seconds]
tlwoerner has joined #armlinux
milkylainen has quit [Ping timeout: 256 seconds]
milkylainen has joined #armlinux
jclsn has quit [Ping timeout: 268 seconds]
jclsn has joined #armlinux
CrashTestDummy2 has joined #armlinux
CrashTestDummy has quit [Ping timeout: 252 seconds]
siak has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
lain6141 has quit [Changing host]
lain6141 has joined #armlinux
cbeznea has joined #armlinux
rfs613 has quit [Ping timeout: 260 seconds]
iivanov has joined #armlinux
iivanov has quit [Client Quit]
iivanov has joined #armlinux
rfs613 has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
<Xogium>
how does one debug something like this ? I'm unsuere... I've double checked and all the drivers are present
<Xogium>
cat /sys/kernel/debug/devices_deferred
<Xogium>
0-0039
<Xogium>
sound asoc-audio-graph-card: parse error
<Xogium>
5a001000.display-controller
<Xogium>
for reference I think the 039 thing belong to the hdmi-transmitter which is on i2c1, which might be stuck because of the parse error of the audio-graph-card
iivanov has quit []
frieder has joined #armlinux
<ukleinek>
Xogium: 0-0039 suggests the busno is 0 (and the device's address is 0x39)
<Xogium>
right
<Xogium>
but I mean i2c1 in the device tree, not in linux itself. Sorry, I should have been more specific
* ukleinek
nods
<Xogium>
but yeah parse error is very little to go on
<ukleinek>
the easiest action is probably the asoc-audio thing
* ukleinek
suggests to improve the error reporting of audio_graph_parse_of()
<Xogium>
that could be a good idea
<Xogium>
whatever it is, I don't think that's my fault. I have not touched the device tree, or at least nothing related to sound, and neither did I touch the driver itself
<ukleinek>
and it worked with an older kernel version?
<Xogium>
aye
<militantorc>
Another phone this time
<Xogium>
this is a vendor kernel, granted. But it was 6.1.28 before and now is 6.1.82
<militantorc>
This project is going to be fun
<Xogium>
so something was either backported that blew up this, or they did something that doesn't work quite as they were hoping it to
<militantorc>
what does this mean wrt gcc architecutre string:
headless_ has quit [Quit: Konversation terminated!]
iivanov_ has quit [Remote host closed the connection]
iivanov has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
prabhakalad has quit [Ping timeout: 268 seconds]
prabhakalad has joined #armlinux
prabhakalad has quit [Ping timeout: 264 seconds]
prabhakalad has joined #armlinux
dmart has joined #armlinux
System_Error has quit [Remote host closed the connection]
System_Error has joined #armlinux
CrashTestDummy3 has joined #armlinux
CrashTestDummy2 has quit [Ping timeout: 268 seconds]
<biju>
Does any one knows, once we issue CMD11 for SD voltage switch, How to restore previous state without power cycling??
<militantorc>
what exactly is a device tree
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
<Xogium>
militantorc: a device tree is there to describe the hardware, in a sense. So linux knows the kind of cpu it has, the memory available to it, but also all the SoC peripheral connected to that for example the usb ports, the eMMC storage, the micro sd / mmc slot if there is one
System_Error has quit [Remote host closed the connection]
<Xogium>
since arm has no acpi (darn good thing it doesn't), you need some way to be able to tell it the hardware and all of its configuration
<Xogium>
it's a very very broad idea I gave though
<Xogium>
iirc bootlin has some stuff on dt... Device tree 101 I think it is called ?
<militantorc>
Xogium, i have no idea about low lelve
<militantorc>
this is a legit question, not an attack
atorgue has joined #armlinux
<Xogium>
acpi is an abomination and it cannot easily be interpreted by humans when things do go wrong, whereas deveice tree things are basically plain text (dts/dtsi, not the final dtb mind)
<Xogium>
acpi is basically the machine probing the hardware on its own and is kind of hackish imo
<Xogium>
*device tree, rather
<militantorc>
Xogium, is device tree static or dynamic
<Xogium>
what do you mean exactly ?
<militantorc>
as an pure end user, not developer, acpi events have been helpful for me to debug some ports of my laptop
<militantorc>
Xogium, as in
<militantorc>
is device tree specified at boot time or flash time
<militantorc>
or can it accomodate change of hardware
<militantorc>
such as you plugging in a new keyboard or monitor etc
<Xogium>
that depends. The bootloader's device tree is generally built-in for multiple reasons, the main one is that it needs immediate access to hardware and if it had to find the device tree from a disk partition it had no idea about... You can see why that would fail
<Xogium>
the kernel's device tree on the other hand is specified at boot time and passed by the bootloader, loaded from the storage medium itself
<militantorc>
so does this mean we will have a combinatorial explosion
<militantorc>
if we want to have a general purpose ARM Linux distro
<militantorc>
to support all possible combinations and permutations of hardware/peripherals
<militantorc>
what is the solution to that?
<Xogium>
that's definitely tricky. In my experience, it is literally impossible to make something be truely general purpose, as each board/platform might require its own specific bootloader
<Xogium>
the kernel can be made generic enough for a lot of devices to use it
<Xogium>
but the bootloader... That's another problem entirely
<militantorc>
so we are helpless unless ARM manufacturers agrees to standardize on the basis of somthing like UEFI that amd64 have done?
<militantorc>
i am feelin this might be used as an excuse by manufacturers to lock down laptops too like they did phones
<militantorc>
once arm makes inroads in laptop
<militantorc>
i hope someone can force a standardization on them
<Xogium>
well, it can be made... But that would still mean you need a specific image for each supported platform afaik. I could of course be entirely wrong in this, but that's what I've generally seen so far
<Xogium>
there's some sort of efi implementation for aarch64 iirc, but not for aarch32, if I'm not mistaken
punit has quit [Read error: Connection reset by peer]
punit has joined #armlinux
<militantorc>
idk how to feel about it
<militantorc>
arm as a technology is interesting
<militantorc>
but
<militantorc>
we live in a time without the lucky accident of the IBM pc to help us through
<militantorc>
and governments are much mroe smart and evil regarding computer technology now
<militantorc>
and even worse
<militantorc>
the technology no longer solely exists in the hands of western, liberal, democractic countries as it was during the dawn of personal computing
<militantorc>
sorry for the political rant
psydroid2 has joined #armlinux
<militantorc>
but its just
<militantorc>
some things are worrying me for some time
atorgue1 has joined #armlinux
atorgue has quit [Read error: Connection reset by peer]
<militantorc>
Xogium, anyways so yes I was wondering what all those 'arm device tree' entries meant in the output of binwalk to android images
<militantorc>
thanks for clarifying its meaning
<Xogium>
no worries
<militantorc>
Xogium, anyways so yes I was wondering what all those 'device tree' entries meant in the output of binwalk to android images
ellyq has joined #armlinux
_rgallaispou has joined #armlinux
_rgallaispou is now known as rgallaispou
headless has joined #armlinux
System_Error has joined #armlinux
pg12 has quit [Ping timeout: 268 seconds]
Livio has quit [Ping timeout: 264 seconds]
pg12 has joined #armlinux
pg12 has quit [Ping timeout: 268 seconds]
pg12 has joined #armlinux
gclement has quit [Ping timeout: 256 seconds]
<militantorc>
so
<militantorc>
I have somehow managed to find a way to make changes to the fs as root
<militantorc>
while in a fastboot image environment
<militantorc>
how does one next cross-compile an 'su' binary for the phone
<militantorc>
and or perform necessary steps to disable selinux blockades
<militantorc>
so i can just get up to root as a normal mode while booted to the phone normally
frieder has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]