<Tartarus>
marex: I guess Jagan took the discussion as changes requested on that patch, I've put it back to new so he sees it hopefully
<Tartarus>
marex: Follow-up and say you think the discussion was resolved such that your patch is correct as is and make sure he's cc'd?
littlebobeep has quit [Quit: leaving]
littlebobeep has joined #u-boot
mthall has joined #u-boot
mthall has quit [Client Quit]
<marex>
Tartarus: I also haven't heard from Jagan on other patches, so let's see
mthall has joined #u-boot
ide12 has joined #u-boot
<ide12>
Hey all, I am looking for someone with some experience with uboot, specifically USB handling.I am trying to switch USB devices by using the 'usb dev' commmand, I try 'usb dev 2' (dev 0 is curently active) But I get an error that usb device 2 cant be found. I see it in the usb device tree though...
Gravis has quit [Quit: No Ping reply in 180 seconds.]
Gravis has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
<Tartarus>
marex: Do you remember how to run pytest + sandbox?
Gravis has quit [Quit: No Ping reply in 180 seconds.]
Gravis has joined #u-boot
sobkas has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
<milkylainen>
Do you guys know any AMD/x86 arch maintainers for the kernel?
<milkylainen>
Alternatively, I could ask it here. It is an x86 question.
<milkylainen>
:)
mmu_man has joined #u-boot
<milkylainen>
I have an AMD Raven Ridge (Ryzen R1606G). Which does not present it's serial ports to Linux. The device does have them. But everything is rather inconclusive.
<milkylainen>
The UARTs sit on either an LPC bus or directly from the CPU afaiu. So either missing enumeration of LPC devices or something else. It does present AMDI0020 ACPI device (uart) but Linux does not care.
<milkylainen>
I can see others getting uarts from an AMDI0020 device.
littlebobeep has joined #u-boot
<Tartarus>
My first suggestion is to poke/decompile the ACPI tables in working and non-working cases and see if something is missing
<milkylainen>
I don't have a working case unfortunately. :\
<Tartarus>
I assume these UARTs aren't exposed on a DB9 or whatever on the board and may be for some internal thing?
<milkylainen>
RX/TX TTL.
<milkylainen>
Indeed.
<milkylainen>
PCB manufacturers decided they're for "debug" and probably scrapped the initialization in BIOS or something.
<Tartarus>
Intentional or unintentional hobbling of the ACPI data I would guess
<milkylainen>
I do see the BIOS printing debug codes to the serial lines.
<milkylainen>
So I can get data, but not enumerated from Linux.
<milkylainen>
It's annoying. :)
<Tartarus>
I'd start tossing debug statements in, or whatever the live debug trace stuff is these days, the linux side
<milkylainen>
Mmm.
<Tartarus>
Perhaps the driver is being too strict in terms of what's presented by ACPI or some other check is failing
<milkylainen>
Yeah.
littlebobeep has quit [Ping timeout: 240 seconds]
<milkylainen>
Tartarus: tnx. appreciate the help.
<Tartarus>
Welcome, good luck.
astroid has quit [Ping timeout: 248 seconds]
<marex>
Tartarus: no, it was always so problematic that I just decided to not bother
<marex>
Tartarus: is it about the LEDs ?
<Tartarus>
Yes, it's about the LED series
<Tartarus>
pip install -r test/py/requirements.txt ; make qcheck builds and runs things
astroid has joined #u-boot
astroid has joined #u-boot
astroid has quit [Changing host]
ide122 has joined #u-boot
ide12 has quit [Ping timeout: 246 seconds]
<marex>
Tartarus: I guess there is no trivial "compile sandbox, run it this way" to trigger the bug and make it easy to debug, right ?
<marex>
we need all this convoluted insane python machinery and pytest which totally obfuscates it all
<marex>
I have to admit, I loathe the CI pytest output, it is just useless gibberish, I never can make out what the problem is out of it
<marex>
binman_init failed:-2
<Tartarus>
marex: run sandbox, ut dm dm_test_led_label should fail
<Tartarus>
marex: Re the test, Yes, I thought it might be wrongly done since it was trying to do something that wasn't quite implemented I guess at the time?
<Tartarus>
marex: Re the pastebin, yes, what's unclear about expected vs got ?
<marex>
Tartarus: Re the test -- which test ?
<marex>
Tartarus: re pastebin -- I don't understand your question -- read the whole paste ?
ide12 has joined #u-boot
<Tartarus>
Yes?
<marex>
Tartarus: when I run the command from the test manually on command line, it works, when I run the test which does run_command(...), it fails
<marex>
it is as if the entire pin controller was reinited
<Tartarus>
marex: Yes, the tests probably do that?
<marex>
I cannot tell, the whole test stuff is so cryptic, I have no idea what it does and I gave up on it
<marex>
but then, the pinmux test should likely also reinit the LED if it expects the LED to set the pin state
<marex>
OK, two I could figure out, one of them is due to missing LED init in the test (assuming the test reinits the pin controller)
<sjg1>
rfs613: yes please
guillaume_g has quit [Quit: Konversation terminated!]
ide12 has quit [Remote host closed the connection]
ide12 has joined #u-boot
<Tartarus>
marex: thanks
<rfs613>
sjg1: it's caused by scripts/get_maintainer.pl line 1607, where it returns "0" for the number of commits, when "git log" shows no signatures on the commits.
<ide12>
The command for to set usb devices is 'usb dev dev' right?
<ide12>
any idea why I can't switch?
<ide12>
idk if this is the right room for the uboot I have
<Tartarus>
rfs613: Yes, still need a board header file
sobkas has quit [Quit: sobkas]
<Tartarus>
Note that some platforms require less than others, and for example all arm sunxi platforms use the same one
<rfs613>
I meant mostly about the directory layouts, like arch/<arch>/cpu/<cpu>/<soc> for example
<rfs613>
versus using arch/<arch>/mach-<something>
<Tartarus>
Ah
<Tartarus>
Well, there's both, depending on how things work out
<Tartarus>
Maybe should move more out of cpu/<cpu>/<soc> to just mach-<soc>
<cambrian_invader>
depends on the arch
<rfs613>
Tartarus: is there a preferred location for new soc being added? Or some other criteria to decide? Hoping to avoid reworking patches over these kinds of layout issues.
<cambrian_invader>
e.g. riscv does not want mach-
<rfs613>
this would be for arm (and armv7)
<Tartarus>
rfs613: Mirror the linux kernel
<rfs613>
Tartarus: it is not upstream there either (yet) but I'll go see if they have decided on a location
<Tartarus>
rfs613: OK, and get your DTS files submitted upstream too asap, that'll be something I ask when you post the patches anyhow :)
torez has quit [Quit: torez]
sbach has quit [Read error: Connection reset by peer]