<marex>
Tartarus: shall we enable DTO support by default ?
<marex>
I mean, for anything which has libfdt enabled, enable DTO by default and let boards disable it ?
<sjg1>
marex: I'm not sure, I have not seen it before that I remember
<marex>
sjg1: its fixed now, the /chosen contained bootargs= which I didnt run into with ut_fdt
<marex>
sjg1: one can trigger it with 'setenv bootargs foo ; ut fdt'
<marex>
sjg1: its just the output from the CI is basically beyond useless ...
<sjg1>
marex: Yes CI output is bad...it is a Python thing to, to suppress a lot of output. I think it is fixable but I have not dug into it. I tend to run tests locally
<marex>
sjg1: can anything be done about it ?
<marex>
sjg1: remember, I can barely get by in python
<marex>
and CI also did not fail if task had TEST_PY_TEST_SPEC: "ut_fdt" set
<marex>
it only failed in CI if the whole bulk of test.py tests was executed
<marex>
so yeah, some previous test set 'bootargs' and that carried over to the FDT test ?
<sjg1>
Well U-Boot is not restarted between tests, so yes the environment does carry over, in general
<marex>
sjg1: shall each test then run some 'env default -a' first ?
<sjg1>
You could add something to test_pre_run(), perhaps add a UT_TESTF_ENV to indicate that it uses the environment?
<marex>
sjg1: why not do it in the core ?
<sjg1>
core?
<marex>
whatever the test.py core code is
<sjg1>
Oh test.py is just making use of sandbox. We don't do any init things there really
<marex>
sjg1: so it just runs ut all ?
<marex>
so I guess we have two items -- reset env between ut tests AND improve CI output ?
<sjg1>
sort of...basically it scans the elf to find the tests, then runs them one at a time on the same U-Boot without restarting (mostly). So the effect is similar to 'ut all' except that it can collect the logs individually
<sjg1>
Yes, two items. Particularly CI output on failure is bad. Actually perhaps adding uploading of artifacts would be enough. See coreboot_test.py which does not
<sjg1>
It involved extra effort...I wish CI could show the results like you get locally. But then I suppose we should be running 'make qcheck' or pcheck locally
<marex>
sjg1: I think gitlab is capable of some gitlab pages injection, where you can display generated html content, no ?
ikarso has quit [Quit: Connection closed for inactivity]
mmu_man has quit [Ping timeout: 265 seconds]
d-s-e has quit [Ping timeout: 246 seconds]
mmu_man has joined #u-boot
d-s-e has joined #u-boot
Leopold has joined #u-boot
goliath has quit [Quit: SIGSEGV]
mmu_man has quit [Ping timeout: 268 seconds]
Leopold has quit [Remote host closed the connection]
Leopold has joined #u-boot
ldevulder has quit [Remote host closed the connection]
vagrantc has joined #u-boot
d-s-e has quit [Quit: Konversation terminated!]
mmu_man has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
mmu_man has quit [Ping timeout: 246 seconds]
monstr has quit [Remote host closed the connection]
prabhakarlad has quit [Quit: Client closed]
mmu_man has joined #u-boot
mckoan is now known as mckoan|away
goliath has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixM2ge has joined #u-boot
naoki has quit [Quit: naoki]
prabhakarlad has joined #u-boot
apritzel has quit [Ping timeout: 246 seconds]
GNUtoo has quit [Ping timeout: 255 seconds]
GNUtoo has joined #u-boot
hanetzer has joined #u-boot
apritzel_ has joined #u-boot
naoki has joined #u-boot
apritzel_ has quit [Ping timeout: 255 seconds]
naoki has quit [Quit: naoki]
<LordKalma>
Hello, I'm going to ask a question without debugging information, yes, because I'm still trying to gather information. There's this Sunxi SBC (R16 iirc)
<LordKalma>
it's part of a device that me and a community is "hacking"
<LordKalma>
we built mainline uboot and it works just fine on *almost* all boards
<LordKalma>
but there have been reports of some people (and confirmed) that some devices don't boot
<LordKalma>
the stock uboot is a 2017 version of all things
<LordKalma>
we were using 2022.whatever just fine
<LordKalma>
2017 with a slight modification for an lcd panel init, but we delayed that to the linux kernel
<LordKalma>
any leads on what could have happened?
pwdr has joined #u-boot
<LordKalma>
maybe something the vendor did to the boards? some protection?
<LordKalma>
Apparently in the "broken" models, the uboot spits only two lines and breaks
<LordKalma>
our defconfig uses the same ram speed as the original loader, but we'll check, thanks
<marex>
LordKalma: it could be the DRAM bus drive strength, or MRx register programming, or other such detail
<LordKalma>
thanks, we'll try and check all of that
<marex>
note that I never really worked with any of the allwinner stuff
<marex>
one more thing, check pinmux configuration of the SoC, maybe there is some way to configure the DRAM bus on the SoC side too
<LordKalma>
hum, that's interesting
<LordKalma>
thing is that when we dd the original uboot into our images they boot on both devices
<LordKalma>
both as in all
<LordKalma>
it was all working from source to everybody until we started getting reports of some people not being able to boot
<marex>
the best kind of issues
<marex>
LordKalma: you might want to compare which registers are written by the downstream u-boot and which by upstream, and see if there is difference in the DRAM controller side
prabhakarlad has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
FlanderoFinder has quit [Quit: Client closed]
<LordKalma>
Thank you for the pointers
<LordKalma>
In the meanwhile, I was told the two-liner log I sent before was with SPL debugging enabled
<LordKalma>
so it breaks *very* soon in the process