qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
prabhakarlad has quit [Ping timeout: 260 seconds]
naoki has joined #u-boot
camus has quit [Quit: camus]
camus has joined #u-boot
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 255 seconds]
stipa_ is now known as stipa
mmu_man has quit [Ping timeout: 264 seconds]
thopiekar has quit [Ping timeout: 264 seconds]
thopiekar has joined #u-boot
swiftgeek has quit [Ping timeout: 268 seconds]
swiftgeek has joined #u-boot
stipa_ has joined #u-boot
stipa has quit [Ping timeout: 268 seconds]
stipa_ is now known as stipa
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
doppo has quit [Ping timeout: 248 seconds]
doppo has joined #u-boot
ikarso has joined #u-boot
<hays>
anyone know for amlogic odroid n2 and n2-plus is it more correct to flash uboot.bin to sector 512 onward, or to flash uboot.bin.sd.bin with a 440:512 hole?
<hays>
i am aware of the documentation
<hays>
which links to an example showing method 2
stefanro has joined #u-boot
stefanro has quit [Remote host closed the connection]
stefanro has joined #u-boot
clarity has quit [Ping timeout: 265 seconds]
clarity has joined #u-boot
clarity has quit [Ping timeout: 255 seconds]
clarity has joined #u-boot
stipa has quit [Read error: Connection reset by peer]
<Tartarus>
marex: OK, if you rebase your m68k stuff on top of current next, or just cherry-pick e3059db90b699c6ab595bbb54dec95b9d2dc7a6b you should get pytest to run now
prabhakarlad has joined #u-boot
bryanb has quit [Remote host closed the connection]
ddevault has quit [Remote host closed the connection]
ikarso has quit [Quit: Connection closed for inactivity]
bryanb has quit [Remote host closed the connection]
ddevault has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
<Tartarus>
marex: Hum, hit the retry button and see if it fails again?
ddevault has joined #u-boot
bryanb has joined #u-boot
<Tartarus>
The spawn timeout thing sounds like what happens sometimes, annoyingly
<Tartarus>
And tangent, I think I want to see about adding a pip download stage to the dockerfile, that should at least make some parts quicker, and it's just a cache, too
mmu_man has joined #u-boot
thopiekar has quit [Ping timeout: 268 seconds]
thopiekar has joined #u-boot
monstr has quit [Remote host closed the connection]
stefanro has quit [Quit: Leaving.]
<marex>
Tartarus: just a sec
vagrantc has joined #u-boot
prabhakarlad has joined #u-boot
Net147_ has quit [Ping timeout: 256 seconds]
<marex>
Tartarus: seems better, one of the bdinfo tests failed, but otherwise OK
<Tartarus>
OK
<Tartarus>
I'll wait until you tell me for sure the patch for the hooks repo is right before applying
<Tartarus>
Just in case that ends up needing some tweak or another
<Tartarus>
Something is "up" with the console itself, or what we're expecting, see how we get ('/builds/u-boot/custodians/u-boot-sh/test/py/tests/test_env.py', 142, 'Skipped: Space in variable value on non-Hush shell') on m68k too?
<Tartarus>
Just above the find_ram_base one
mmu_man has joined #u-boot
<Tartarus>
marex: Oh!
<Tartarus>
I bet having the prompt be "-> " is messing things up
<Tartarus>
Since we look for "->" in places
<Tartarus>
Change CONFIG_SYS_PROMPT to something else and I bet it works, and we run more tests too
guillaume_g has quit [Quit: Konversation terminated!]
<vagrantc>
sjg1_: trying to apply v3 of to fix boot failures on rk3399 and related ... but the first patch fails to apply ... what commit was it generated from?
<vagrantc>
the updating all the defconfig parts is what is making it hard to test the rest...
prabhakarlad has joined #u-boot
konradybcio[m] has joined #u-boot
<konradybcio[m]>
hello, I'm trying to consolidate Qualcomm reset and clock support (Qualcomm's clock controllers are also reset controllers), is it possible to register sort of two different drivers with different UCLASS-es in u-boot?
<konradybcio[m]>
ugh english is hard :), this should have been "it possible to register sort of two different drivers with different UCLASS-es in u-boot that are bound to the same DT node"
matthias_bgg has quit [Read error: Connection reset by peer]
<slobodan>
anyone from China here ?
zibolo has quit [Ping timeout: 248 seconds]
zibolo has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
matthias_bgg has joined #u-boot
slobodan has quit [Remote host closed the connection]
slobodan has joined #u-boot
<sjg1_>
vagrantc: It is at u-boot-dm / fix-rk-working. But you might be able to drop the resync patch. It was just to save generating a confusing delta in a later patch. Tom normally does the resyncs himself every now and then
<vagrantc>
sjg1_: thanks, will take a look
<konradybcio[m]>
how ABI-like are DTs stored in arch/arm/dts? do I have to keep backwards compatibility in mind? if not, I'll happily clean up the Qualcomm drivers to be compatible with the upstream Linux DTs!
ikarso has quit [Quit: Connection closed for inactivity]
<konradybcio[m]>
FWIW these DTs - as far as Qualcomm support goes - have things that are entirely u-boot-specific, they will not boot any other OS
<vagrantc>
there is a mechanism to split the u-boot specific stuff into a separate include
<vagrantc>
see arch/arm/dts/*u-boot*.dtsi for how it is used
<vagrantc>
konradybcio[m]: ^^
<kettenis>
the goal of at least some of us here is to have u-boot always provide a dt that can properly boot an OS
<kettenis>
the best way to achieve this is to use the dst files from mainline linux and use the *-u-boot.dtsi mechanism that vagrantc describes to add a few u-boot specific things to it
<Tartarus>
sjg1_: In general, resyncing the defconfigs in a series is a bad idea, it makes applying harder, fwiw
<Tartarus>
marex: nice! hush is really not enabled there?
<sjg1_>
Tartarus: Yes, I did not mean to send that patch... probably my config-changing patch would have applied anywayq
<sjg1_>
Tartarus: Re the clang crash, it seems to be dropping U_BOOT_PCI_DEVICE() records. Sign
<sjg1_>
Tartarus: If you print out 'id' in the loop in pci_find_and_bind_driver() you can see that none is present
<sjg1_>
Tartarus: Clang is so desperate to remove important code...
<konradybcio[m]>
kettenis: after some code fixes, the upstream dts need would no additional changes
matthias_bgg has quit [Read error: Connection reset by peer]
<konradybcio[m]>
So my question is, can i change the code without caring about people using old uboot DTs (which would have never booted Linux anyway) with newer uboot binaries?
matthias_bgg has joined #u-boot
<kettenis>
I'd say so, yes
<konradybcio[m]>
frankly, that's fantastic to hear!
<Tartarus>
sjg1_: So we aren't marking stuff as needed enough then :)
<Tartarus>
I'll grab that attribute one tho
<Tartarus>
Wait, no, that patch needs a v2 at least