<apalos>
sjg1: a60f7a3e35bc6da231046a8931072027575c6939 break virtio devices for me
<apalos>
The console just hangs there
<apalos>
00fc8cade89e36855fe8143c4ee66e951a41734e is working
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #u-boot
ladis has joined #u-boot
hanetzer has quit [Quit: WeeChat 3.8]
mmu_man has joined #u-boot
hanetzer has joined #u-boot
haritz has joined #u-boot
haritz has joined #u-boot
haritz has quit [Changing host]
torez has joined #u-boot
<Tartarus>
sylensky: sure
<sylensky[m]>
thanks, i tested that already which works. however it cant read from block devices prior running udev/sytemd. is there something i can take advantage of to overcome this?
stefanro has quit [Remote host closed the connection]
stefanro has joined #u-boot
<Tartarus>
Well, do you need it that early, or do you just want the ordering right?
<Tartarus>
For the latter you can tell the unit to wait for the device
<Tartarus>
For the former, uh, it's a bit harder to say and depends on the use case
<Tartarus>
but often the kernel cmdline will be leveraged for this
matthias_bgg has joined #u-boot
<sylensky[m]>
<Tartarus> "Well, do you need it that early,..." <- lets assume its a universal userspace which decides what to start based on the u-boot environment. preferrably i would like to have as early as possible to decide which services to start and which not.
ikarso has quit [Quit: Connection closed for inactivity]
<sjg1>
apalos: You can call tpm_init() directly, right?
<apalos>
3Cfrom c code yea
<apalos>
but that's really unusable,
<sjg1>
Re the breakage, what board is this?
<apalos>
qemu
<apalos>
if I disable bootstd, evereything is fine, so my guess is that, this is soemthing on the auto scan code for devices
<apalos>
on the tpm, I've sent a simple patch that makes the tpmv2 startup sequence proper
<apalos>
and I use that on th efi subsystem. I'll think of a way not having that call on the tpm subsystem
<apalos>
efi subsystem*
<sjg1>
apalos: Is this a qemu we don't have in CI? Can I repeat it? Is it the call to ret = uclass_probe_all(UCLASS_VIRTIO); ?
<apalos>
you can repeat it,
<apalos>
make qemu_arm64_defconfig
<sjg1>
apalos: Can you call tpm_init() from the EFI subsystem?
<apalos>
yea we already do taht
<apalos>
well not the init, the startup sequence those devices need
<apalos>
but you might have a point there. Noone calls the init in that case
<apalos>
But my whole point is that the *init* function is kind of useless
<apalos>
It only does request a locallity
<apalos>
on the crash, I guess we dont test virtio on the CI properly
<apalos>
no it would not render the commands useless
<apalos>
some of them are redundant,
<apalos>
But I would argue they were useless when they got merged
<apalos>
I don't know why that was done the way it was,
<apalos>
But having a bootloader expecting user command to initialize hardware sounds complicated
<apalos>
and for the tpm specifically not very useful. For example, the tpm_startup command on the TPM
<apalos>
You either says TPM2_SU_CLEAR which means initialize a reseted hardware
<apalos>
or TPM2_SU_STATE which tells the TPM "restore your saved state if you have any"
<apalos>
But the latter is used on suspend/resume
<apalos>
So unless you have a very special case for a very special hardware, for which i'd argue again we dont care,
<apalos>
Why can't we autostart it ?
<sjg1>
Because then we cannot have the TPM in its initial state at all. It is a rule of DM that probe() probes the device, but does not set it up in any particular way. It makes it impossible for people to do something different, such as run TPM tests
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
<apalos>
and that leads to spaghetti code, like the one I am trying to fix in EFI
<apalos>
where you have random coammands call subsystem init sequences
<apalos>
with no reasonable way of controlling dependencies
<apalos>
It would be much saner for the tpm to either have
<apalos>
1. a driver flag
<apalos>
or 2. a Kconfi option
<apalos>
Saying "dont run the startupup sequence which *is needed* for the device to work, because i have a special snowflake hardware/usecase"
<apalos>
But anyway, it's controllable for now,
<apalos>
So instead of just calling the tpm_startup sequence from EFI, we'll also call tpm_startup
<apalos>
At least it's only in one place now and we can look at it when it actually becomes a problem
<apalos>
How about adding a Kconfig option with the subsystem you *want* to init
<apalos>
So we could add a callback to DM and initialize that hardware on boot, instead of relying on preboot commands
<sjg1>
apalos: The TPM init is irreversible once you have done it. I honestly thing that approach would lead to a lot more complexity than one function call. Is this the sort of thing that is done in Tianocore?
<sjg1>
apalos: What if there are multiple TPMs available? We only want to p[robe and use the one that is in use. Remember the lazy-init stuff
<apalos>
I have no idea what they do in that thing :>
<apalos>
I think they enable it unconditionally on the DXE phase
mmu_man has quit [Ping timeout: 268 seconds]
<apalos>
sjg1: I know it's irreversible as I said noone calls the .close callback
<apalos>
but in the current case the tpm_init() doesnt do anything useful. IOW you can completely skip it and the tpm will work just fine, if you perform the startup sequence
<sjg1>
apalos: Will try to come back on later. close() does not reverse it, only a TPM hardware reset does (by design)
<apalos>
no close does reverse it
<apalos>
Dont mix the internals of u-boot with how the tpm works
<apalos>
You can send as many TPM startup commands as you want
<apalos>
the tpm will just respond " I already did that"
<apalos>
the .open callback now sets an internal value to 1,
<apalos>
and the next time .open is called we return -EBUSY
<apalos>
but you can do useful things on .close. e.g release locality
<apalos>
which the tis core has, but we never call that
<apalos>
but anyway, that's not that important atm, the device works fine. I'll keep the startup call on the efi subsystem, since we need to extend PCRs etc and see what we can do better
<apalos>
For example Eddie's patches on measured boot without EFI, will also need to initialize that device
mckoan is now known as mckoan|away
<apalos>
anyway kids time, I'll check back later
mmu_man has joined #u-boot
hanetzer has quit [Ping timeout: 246 seconds]
hanetzer has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
<bryanb>
was hoping you may have some ideas on how I could fix it before I deep dive into kconfig
<bryanb>
i'll try to focus on the ti parts right now :)
Leopold has joined #u-boot
Leopold has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #u-boot
ldevulder has quit [Read error: Connection reset by peer]
ldevulder has joined #u-boot
ldevulder has quit [Quit: Leaving]
vagrantc has joined #u-boot
<khilman>
Q on USB gadget eth behavior. I'm getting `The remote end did not respond in time` when doing TFTP transfers. If I watch the host side with `udevadm monitor` I notice that for every tftp command, the host does an add/bind for the xfer and then an unbind/remove after. That makes sense, but when doing multiple TFTP commands in a row, it seems that the time to unbind/remove and then add/bind again is too slow for u-boot.
<khilman>
is there any way to configure u-boot to wait a bit longer for the unbind/remove + add/bind to happen?