vfazio has quit [Read error: Connection reset by peer]
vfazio has joined #u-boot
<Tartarus>
Yes, before rc2 is fine
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #u-boot
___nick___ has joined #u-boot
Leopold has quit [Ping timeout: 260 seconds]
<apalos>
Tartarus: something is horribly broken, for every virtio device you define in qemu u-boot scans 2 devices now
<apalos>
2023.01 is fine, I'll try bisecting it and see what's going on
<Tartarus>
apalos: Ugh, ok
<apalos>
as far as the wd thread is concerned, we have the same opinion
<apalos>
that's why I said i prefer the latter
<apalos>
but keeping the wd alive, still has risks
<apalos>
But at least the device *will* reboot
<Tartarus>
Yes, if your wd triggers before the OS can take over, that's an engineering problem to solve, to which the answer is not disable the watchdog
<Tartarus>
I'll snark over here anyhow, that such behavior might be OK in the datacenter where everyone is used to just popping in to the management console, but the management console in turn runs U-Boot and doesn't ever turn off the HW watchdog :)
<Tartarus>
Update failed, OS took too long to start due to bad luck is better than update failed, satellite is bricked because it'll never restart now
<apalos>
yea we are on the same page on this
<Tartarus>
I'll assume the UEFI spec just forgot to say "software" watchdog in a place or two
<Tartarus>
which yes, makes sense to stop
<sjg1>
Tartarus: I am sending out the splc series now...so you can see how it works, etc.
<apalos>
so, what people are missing is the efi-stub
<Tartarus>
OK, good. Please feel free to convey up any management chains that I'm gonna be a pain in the ass about this one, the spec needs fixing, not breaking the software
<apalos>
the stub has no drivers, so if the device somehow gets stuck in there, you are in limbo
<apalos>
forever
<sjg1>
Tartarus: Just an RFC for now
<apalos>
So, yes, we are on the same page, I want the hardware wd running
<Tartarus>
Hell, you update to a new kernel that crashes before the watchdog is re-started
goliath has quit [Quit: SIGSEGV]
<mwalle>
ahh that old watchdog topic again :) I'd say you have to differentiate between embedded use cases and the "we just want to boot a standard distro". for the first one, you want to keep the (hardware) wd enabled, for the latter.. not so much. and there are hardware watchdogs that can be stopped
<mwalle>
we even have a lock bit which can be set if you want to make sure it cannot be stopped
monstr has quit [Remote host closed the connection]
<mwalle>
but my last take away was to just disable the watchdog in u-boot. as it is broken if you want to use it with efi
<apalos>
broken how ?
<mwalle>
you cannot assume the booted os has a watchdog driver
<mwalle>
i mean the whole thing about that efi boot is to be able to boot any standard distro, right?
<apalos>
and why is that an EFI problem and not a bootloader problem overall?
<Tartarus>
I mean, it's a bit moot as it's not hard to get a watchdog driver done for the OS
<Tartarus>
Just part of the always has been bring up fun
<mwalle>
Tartarus: well, how long would it take to have a driver in debian?
<apalos>
Tartarus: the only case I can think of, that this wont work is some ancient WD devices, with dumb refresh timers
<apalos>
iow, I've seend hardware which needs refreshing every 5 seconds, max
<mwalle>
what are ancient wd devices?
___nick___ has joined #u-boot
<frieder>
mwalle: Enabling the WDT driver for our i.MX board (and for all other i.MX boards) in Debian wasn't too hard...
<mwalle>
Tartarus: i needed like 1 year of getting our watchdog (mfd) driver accepted in linux. but that board was just running fine with stock kernel
<apalos>
really old cpu's with watchdogs that needs a frequent update
<apalos>
mwalle: ^^
<mwalle>
frieder: thats not the point, you had a watchdog wich was already supported
<mwalle>
apalos: so why is a watchdog in a SoC? thats a wrong assumptioj
<frieder>
mwalle: Indeed, of course it's different if there's now mainline driver enabled.
<frieder>
*no
vagrantc has joined #u-boot
<mwalle>
but if a watchdog can be configured to have a larger timeout or not, isn't my point. My point is that you will *force* the user /kernel to have a watchdog driver
<apalos>
mwalle: not really
___nick___ has quit [Client Quit]
<apalos>
you can disable the wd in the u-boot config, no ?
<mwalle>
apalos: well, thats what i said above. i disable the watchdog in u-boot.
<mwalle>
IIRC there was also a patch by me to configure that the wd behavior
___nick___ has joined #u-boot
<mwalle>
apalos: but that doesn't make the wd handling with u-boot together with efi any better
<apalos>
mwalle: i get the point, i just dont think it's important
<apalos>
it's a decision you have to make when designing the device and the distro that runs on top
<apalos>
sure disabling the wd on exit allows more freedom in the os
<apalos>
but from a desing pov, it's the wrong design :>
<mwalle>
as I said, you have two different use cases here
<mwalle>
and I've always though that whole efi stuff was about to run off the shelf distros
<mwalle>
it should be the other way around. if some users really want that hardware watchdog, there should be a boot protocol around it. not forcing any user to have a driver for it
<mwalle>
and unless someone clearifies if the efi spec is wrong on that. it seems that the spec also mandates the watchdog to be disabled
ggardet has joined #u-boot
<frieder>
mwalle: Or maybe the OS should be able to request the expected watchdog status from the bootloader. I'm thinking of VBE boot which should be able to such things in theory, IIUC.
sstiller has quit [Remote host closed the connection]
guillaume_g has quit [Ping timeout: 252 seconds]
guillaume_g has joined #u-boot
<apalos>
Tartarus: sjg1 a60f7a3e35bc that's the commit that makes virtio devices appear 2x
mmu_man has quit [Ping timeout: 248 seconds]
<apalos>
it's easy to reproduce, build, launch with qemu + 1 virtio block device and on the console do virtio info
<frieder>
mwalle: I don't know much about it. Just came to my mind because I recently watched sjg1's talk.
<mwalle>
frieder: yeah the one from sjg1. but that's a counter proposal to efi, so I don't know how that would help with efi and watchdogs? ;)
<frieder>
mwalle: It wouldn't
<frieder>
mwalle: Just came to my mind as we were "kind of" talking about EFI restrictions.
<mwalle>
frieder: ah ok
guillaume_g has quit [Quit: Konversation terminated!]
<sjg1>
frieder: mwallel Actually I think VBE can solve this. The OS publishes a request for the watchdog so that U-Boot knows whether to enable it or not
vfazio has quit [Remote host closed the connection]
<mwalle>
sjg1: objection 6: no distro supports it? Do I miss something?
mmu_man has joined #u-boot
<Tartarus>
sjg1: how many platforms did you test the split config branch on? I assume you didn't do a CI build since am335x_evm SPL now size overflows
<Tartarus>
I'll comment that out of my CI loop and move on to the next platform for the moment
<Tartarus>
(this is from your dm tree branch)
<Tartarus>
Pi seems to be going fine, so that's good
frieder has quit [Remote host closed the connection]
stefanro has quit [Ping timeout: 264 seconds]
<Tartarus>
dra7xx_evm is failing to boot now, just gonna quick confirm it's fine on master (the platform is a little finicky due to where the SD card cage is)
<Tartarus>
yeah, dra7xx_evm failure is new, same amount of SPL output as normal, then silent lockup
<Tartarus>
sjg1: So I guess my first bit of feedback / concern on this is, it should just be a matter of building everything we used to build and at the end of the day there shouldn't be any size changes, or if there are ones, it'll be something we understand why happened, I would assume due to a latent bug
<Tartarus>
But that isn't yet the case
<apalos>
sjg1: not yet, i'll try those
mckoan is now known as mckoan|away
<Tartarus>
... my own mismerge of the amlogic PR I'll be pushing out shortly caused that failure to build, I'm sure
<sjg1>
mwalle: It depends what you mean by 'it'. For example, VBE can boot any distro. If they have fwupd then they can support firmware update (which would be independent of the distro anyway)
<Tartarus>
poking at pine64_lts, there's a whole lot of function changes/additions, before/after
<Tartarus>
Yeah, another TI platform failed, so I suspect whatever that problem is, is common to many/all of the TI ones at least
<mwalle>
sjg1: ultimatly, I want to be able to just download the debian aarch64 image, put it on an usb thumb drive, plug it in and I expect to see the installer booting
<mwalle>
if that doesn't work. I'm back to the "embedded" workflow. like having some kind of instructions where to put what
<Tartarus>
sjg1: And, I suspect you want some more general feedback but, I find it hard to judge incomplete solutions. I agree that we need to improve our build system, but I can't say if how this is implemented is right until what might be some challenging issues are dealt with. Or maybe it's just the earlier series having some migration issues, which increases size and leads to some silent failure to boots, it's hard to say until it's
<Tartarus>
diagnosed
<Tartarus>
I am doing a every commit build for pine64_lts atm
<Tartarus>
Another 15min left on that maybe
vfazio has joined #u-boot
ldevulder has quit [Quit: Leaving]
<Tartarus>
Ugh, I hope the SPL_MMC_QUIRKS fix isn't breaking those platforms, gotta test that...
PhoenixMage has quit [Ping timeout: 256 seconds]
PhoenixMage has joined #u-boot
<Tartarus>
Phew, passed with that commit in
apritzel has quit [Ping timeout: 256 seconds]
<Tartarus>
Yeah, the "good" news is it's one of the final commits that seems to be breaking the platform
<sjg1>
Tartarus: Yes I understand that. But nothing will change about the implementation. It is just going to be more commits to tidy up Kconfig use, etc. So hopefully you can look at the solution in that light. I would hope to figure it all out by Monday, but it depends on what I find
<Tartarus>
kconfig: Update CONFIG_IS_ENABLED() for split files is the one that breaks pine64_plus and likely the other platforms too
<Tartarus>
Lemme re-start the size test run now that I saw the results got funny due to merge commits and rebased everything
<sjg1>
mwalle: Well you can already do that with standard boot. VBE would not kick in unless you are doing firmware update, or using a FIT kernel with OS requests. Are you interested in helping with it?
<sjg1>
Tartarus: OK thanks. That's where it fails, because it is when broken Kconfigs come to light...I've been added commits before that one, as you can see
PhoenixMage has quit [Ping timeout: 248 seconds]
ldevulder has joined #u-boot
<Tartarus>
sjg1: By that you mean commits like "cros_ec: Add SPL Kconfigs for cros_ec features" ?
PhoenixMage has joined #u-boot
PhoenixMage has quit [Ping timeout: 260 seconds]
<rfs613>
I'm planning to revive some RFC patches I worked on several months ago. Rebase to current master, address previous comments, etc.
PhoenixMage has joined #u-boot
<sjg1>
Tartarus: Yes that's right
<rfs613>
Presumably I just post it as v3 (the next version) as opposed to starting anew?
<rfs613>
Or will that confuse patchwork / reviewers?
<xypron>
Tartarus there is nothing like a software watchpoint in the UEFI specification. What we have done in software is not fully compliant. But many boards don't allow to set up a 5min hardware watchpoint. So I had to work around that limitation.
<Tartarus>
sjg1: OK, then it'll be partly judging how many of those there are
<Tartarus>
xypron: Push back at the spec please, given the hope to put this in to embedded situations, the spec needs to come up with a workable solution here to the real life constraints that exist
<sjg1>
Tartarus: I hope < 100 but it does depend on how many boards do strange things
<Tartarus>
Yeah, it'll be a good question to solve, but I think that also means that once you've got the pre-req series in, testing will be easy
<Tartarus>
zero size change and they're all fixed
<Tartarus>
looking at pine64_plus size change for all 291 commits, and it's that commit, basically, aside from the quirks fix, and a minor reduction in dropping dead usb code
ikarso has quit [Quit: Connection closed for inactivity]
<sjg1>
Tartarus: Yes the pre-reqs series are the key. The run finished and I need to check it all. Hopefully will get time early tomorrow