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
jwerner has quit [Remote host closed the connection]
prabhakalad has quit [Read error: Connection reset by peer]
iivanov has quit [Read error: Connection reset by peer]
amitk has joined #armlinux
siak has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141 has joined #armlinux
monstr has joined #armlinux
gclement has joined #armlinux
frieder has joined #armlinux
<Xogium>
I've got a probably dumb question ^^ first time I plan on actively using 2 uarts at a time on my hardware. I was wondering, is there a way that the tty remain in order ? I.e: uart4 is always ttySTM0, for example. Is that the purpose of aliases in the dt ?
prabhakalad has quit [Quit: Konversation terminated!]
prabhakalad has joined #armlinux
<ukleinek>
Xogium: The official suggestion is to check in sysfs which is the intended UART. But yes, you can make a tad easier with dt aliases.
<Xogium>
ukleinek: I'd like to have stable tty names, mainly
<Xogium>
so that ttySTM0 = uart4 all the time, ttySTM1 = uart3 and such
<ukleinek>
(udevadm info /sys/class/tty/$yourtty) might help
<ukleinek>
getting fixed numbers is something that you can achieve using aliases. But depending on who you ask you shouldn't do that.
<Xogium>
why ?
headless has joined #armlinux
<Xogium>
mmmh maybe I should rely on udev rule
<Xogium>
but udev is userspace and so ttySTM1 passed as console argument might not be working with this in mind ?
<phh>
(just asked llama 3.1 70b, they agree that you can add aliases { serial0 = &uart4; } to stablize the ids, it uses of_alias_get_id. Now the weird thing is that drivers/tty/serial/stm32-usart.c doesn't seem to probe WITHOUT aliases? msm-serial.c have a fallback when of_alias_get_id returns a negative value, but stm32-uart.c doesn't)
<Xogium>
phh: huh interesting and the fact the dtsi for the dk from st all appear to have aliases defined for the uarts in use would point to that being right ?
<Xogium>
stm32mp15xx-dkx.dtsi has serial0 set to uart4, and then mp157c-dk2 and mp157f-dk2 have an additional serial3 set to usart2 for bluetooth purpose
<Xogium>
dkx also handles the other uart. I totally missed that
cbeznea_ has joined #armlinux
Xogium has quit [Read error: Connection reset by peer]
Xogium has joined #armlinux
headless has quit [Quit: Konversation terminated!]
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
Livio has joined #armlinux
lain6141 has quit [Read error: Connection reset by peer]
lain6141_ has joined #armlinux
headless has quit [Quit: Konversation terminated!]
<geertu>
Xogium: Multiple console= parameters used to work
<Xogium>
huh huh
<Xogium>
so why is it not working out for me now ?
<Xogium>
maybe dmesg prints something about it
<Xogium>
let me check
<Xogium>
I don't see anything suspicious regarding that
<Xogium>
only the lines that detect the tty peripheral, the kernel command line... But also, no message linke
<Xogium>
printk: console ttySTM1 enabled
<Xogium>
only ttySTM0 has that
<Xogium>
*like
<geertu>
Perhaps someone broke it
<Xogium>
hmm
<Xogium>
then again I also get this
<Xogium>
printk: console tty1 enabled
<Xogium>
so tty1 ans ttySTM0 both get working but ttySTM1 ? Nop
<Xogium>
*and
<Xogium>
I don't reckon tty1 or ttySTM0 should make an impact on console= should it ?
<Xogium>
as in, no matter if it's a serial console or not, that console= parameter should behave the same ?
<Xogium>
I'm doing something a bit weird I admit
<Xogium>
but useful
<Xogium>
using an esp-01 module connected to the second uart of my board available as pins to send and receive serial data over wifi, in order to remotely debug my board
<geertu>
Kernel output should go to all consoles. /dev/console maps to the last one only.
<geertu>
Xogium: If it's just meant to capture debug kernel output, you can add code that registers an additional console object, cfr. what debug=ser does in arch/m68k/amiga/config.c:amiga_debug_setup()
<Xogium>
geertu: it's meant to act like a physical access to uart would so like bootloader, kernel and then getty
<ajb-linaro>
hmm should neoverse-v1 have SME or is graviton3 not quite a neoverse-v1?
<rfs613>
seems there also a tool called setconsole
<Xogium>
so I could kind of redirect one console output to another with that ?
<Xogium>
that seems very slow given it is 2 serial lines interacting together
<Xogium>
but it's an idea
<rfs613>
Xogium: it would be more of a switch, to toggle which of the serial ports gets used
<Xogium>
hmm do you mean setconsole(8) ? Doesn't seem it does that, more like it redirects the output from a specific terminal into another
<Xogium>
from a brief look at the manpage
<rfs613>
setconsole /dev/tty<xy> < /dev/console
<rfs613>
"setconsole sets the underlying tty of the system console /dev/console"
* rfs613
has not tried it, this is just google results ;-)
<maz>
ajb-linaro: if I remember well, G3 is V1. but G3 doesn't have SME, only SVE.
<Xogium>
huh. I can't find that command anywhere, weirdly enough
Amit_T has quit [Ping timeout: 276 seconds]
<rfs613>
Xogium: seems to be available in busybox
<Xogium>
maybe it's a busybox exclusive ?
<Xogium>
:D
<Xogium>
but, I think I can be clever here
<Xogium>
barebox supports gpio-key driver. So in theory I could influence the consile= parameter passed by barebox to linux this way. If I press the button on my board and hold it when booting, barebox should pick up on the gpio state
<Xogium>
so if I pass ttySTM0 when button is pressed and pass ttySTM1 otherwise
<Xogium>
*console
<rfs613>
that sounds like it could work
<Xogium>
smart idea
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #armlinux
headless has joined #armlinux
<arnd>
ajb-linaro: there is graviton4 now using neoverse-v2, so that one is finally armv9.0 with sve2 but still no SME. As far as I know the Apple M4 is the only thing you can buy at the moment that has SME (but doesn't run Linux yet).
<arnd>
graviton3/neoverse-v1 is armv8.4+sve1, but no v9 or sve2
rgallaispou has joined #armlinux
heidaren_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
heat_ has joined #armlinux
heat_ has quit [Client Quit]
heidaren has joined #armlinux
lain6141 has joined #armlinux
lain6141 has quit [Changing host]
lain6141 has joined #armlinux
lain6141_ has quit [Ping timeout: 260 seconds]
nsaenz has joined #armlinux
nsaenz has quit [Ping timeout: 244 seconds]
frieder has quit [Remote host closed the connection]
krzk has quit [Remote host closed the connection]
gclement has quit [Ping timeout: 264 seconds]
headless has quit [Remote host closed the connection]
headless has joined #armlinux
monstr has quit [Remote host closed the connection]
headless has quit [Ping timeout: 260 seconds]
dmart has quit [Quit: leaving]
luispm has quit [Quit: Leaving]
Livio has quit [Ping timeout: 272 seconds]
heat_ has joined #armlinux
heat has quit [Read error: Connection reset by peer]
<ajb-linaro>
arnd so it looks like graviton3 adds bf16 to the baseline neoverse-v1 but otherwise the cpu feature flags match
<broonie>
Yes, Arm haven't released a SME implementation currently.
<arnd>
ajb-linaro: in don't think they get to customize it much, V1 and N2 both come with bf16 already. The older N1 (Graviton2) ist a v8.2 without bf16 or SVE though.
amitk has quit [Ping timeout: 252 seconds]
rgallaispou has quit [Quit: WeeChat 4.3.5]
<CounterPillow>
Where do people even get socs with newer arm cores from? I usually only see them in phones with locked bootloaders
balrog has quit [Quit: Bye]
<phh>
CounterPillow: hum like Cortex-X4? which is ARMv9.2? Galaxy S24 has it and is unlockable
<macromorgan>
anyone have any experience with the fcs,fusb302? Mine keeps attempting to negotiate PD over and over again blinking from online to offline, even when it's hooked to a power only 5V USB 2.0 line.
<ajb-linaro>
arnd hmm maybe out neoverse-v1 model is missing a bit then
<maz>
macromorgan: a mis-wiring of the CC lines would do that.
<macromorgan>
any way for me to tell if the lines are miswired or not (without busting out an oscilliscope or microscope)?
<maz>
schematics could help. looking at the programming mode of the FUSB302 can also be interesting. I found that the automatic orientation detection was pretty flaky in some contexts, and that doing it "manually" was significantly more reliable.
<maz>
also, revision B is a lot more tolerant to timing variations (the original version is a bit temperamental).
<macromorgan>
do you know if self-powered refers to the device having a battery (like a phone) or if it refers to something internal to the hardware of the port (like a special regulator or something)?
headless has quit [Quit: Konversation terminated!]
lain6141 has quit [Read error: Connection reset by peer]
<maz>
macromorgan: where do you see this? I can't see this in the spec (but I'm away from home and I don't have the latest at hand).
<macromorgan>
it's in the tcpm.c file. I found my own question in the comments of the file that says "port belongs to a self powered device" which is what I have.
lain6141 has joined #armlinux
lain6141 has quit [Changing host]
lain6141 has joined #armlinux
<maz>
ah, no idea. my only use of that thing is on a device that is not handled by Linux, and is mostly used for communication (and not PD itself).
<ardb>
for usb devices in general, self-powered means that it does not need power from the bus to operate
<ardb>
could be a battery or could be a dedicated PSU
<ardb>
maz: i take it this is the scrutinizer gadget?
<maz>
ardb: yup
zkrx has quit [Ping timeout: 245 seconds]
zkrx has joined #armlinux
<macromorgan>
apparently it was a cheap crappy PD device that wasn't working. Tried a different one and now I'm pulling 9V no problem.
Livio has quit [Ping timeout: 244 seconds]
Livio has joined #armlinux
<macromorgan>
when using any non-pd charger though I'm getting a crazy amount of interrupts