qschulz_ has quit [Read error: Connection reset by peer]
zibolo has quit [Ping timeout: 244 seconds]
qschulz has joined #u-boot
zibolo has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
<sjg1>
milkylainen: Gosh you really dig into it! Did you ask on any of the toolchain mailing lists, etc? What is special about U-Boot that it has this problem?
guillaume_g has joined #u-boot
agust has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 260 seconds]
camus1 is now known as camus
sszy has joined #u-boot
matthias_bgg has joined #u-boot
kaji has quit [Quit: Client limit exceeded: 20000]
gsz has joined #u-boot
mckoan|away is now known as mckoan
tre has joined #u-boot
lucaceresoli has joined #u-boot
<milkylainen_>
sjg1: I've bumped a question to the binutils channel + mailing list. See if I can get some pointers from there. I patched my toolchain, but it doesn't seem to help. So I'm back to square 0 unfortunately.
<rfried>
Tartarus: ping, do you want the PXE series on next or master ? do you prefer to merge it yourself or do you want it through my tree ?
<Tartarus>
rfried: master, and were you going to rework the previous PR, with the 8211e PHY fix or just drop the patch?
<rfried>
Tartarus: drop the patch.
<Tartarus>
ok
<rfried>
if it's going to master (the PXE) maybe you should merge it.
<rfried>
I don't have any other content for master.
<Tartarus>
OK, I can pick up the PXE stuff then. And you'll rework/resend the rest of the stuff?
tnovotny has quit [Quit: Leaving]
<rfried>
Yes, I forced pushed the patches without the PHY, once CI will pass I'll sent you a new pull-request
redbrain has joined #u-boot
as2334 has joined #u-boot
vagrantc has joined #u-boot
lucaceresoli has quit [Remote host closed the connection]
torez has quit [Ping timeout: 245 seconds]
torez has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
mckoan is now known as mckoan|away
mmu_man has quit [Ping timeout: 250 seconds]
indy has quit [Read error: Connection reset by peer]
indy has joined #u-boot
<Tartarus>
xypron: So, trying some bootefi stuff. Is it expected that bootefi doesn't end up calling usb_stop() ? And if so, uh, how is that supposed to work?
<Tartarus>
To be clear, what I mean is this, after usb start and bootefi of a kernel (or via grub):
<xypron>
Tartarus: in efi_exit_boot_services() we call bootm_disable_interrupts() which only calls usb_stop() if CONFIG_CMD_USB=y. Why should it depend on CMD_USB and not on USB?
torez has quit [Ping timeout: 264 seconds]
torez has joined #u-boot
camus1 has joined #u-boot
<Tartarus>
xypron: CMD_USB=y already on this platform
<Tartarus>
And the user visible difference is usb start, or not, before bootefi
<xypron>
But still is the constraint correct?
<Tartarus>
lemme toss in a usb stop...
<xypron>
But it is already called.
<xypron>
Better put a printf into usb_stop()
camus has quit [Ping timeout: 240 seconds]
camus1 is now known as camus
<Tartarus>
OK
<xypron>
Tartarus: On my OrangePi PC is always get a warning "EHCI failed to shut down host controller." So ehci_shutdown() is invoked.
<Tartarus>
Not called here.
<Tartarus>
j721e_evm_a72_defconfig is anything pops out at you
<Tartarus>
Adding debug print to efi_exit_boot_services
<Tartarus>
That is called
<xypron>
is usb_stop called?
<xypron>
Tartarus ^
<apalos>
xypron sjg1 will any preference on the TPM cleanup thingy? Will some of you pick it up or Tartarus ?
___nick___ has joined #u-boot
<xypron>
apalos: mmio driver?
<apalos>
yea
<apalos>
xypron ^^
<xypron>
apalos: as that is needed for EFI testing I could add it to my next pull request
<apalos>
I am fine with that
torez has quit [Ping timeout: 240 seconds]
<Tartarus>
xypron: As best I can tell (but I'm trying for a 4th time and then seeing what booti says too), it's dying immediately in usb_stop and producing that fault?
torez has joined #u-boot
<Tartarus>
... there's 2 usb_stop()s, cool, ok
<Tartarus>
So, debugging a bit more where it fails down in I hope the right usb_stop
josem has quit [Quit: Client closed]
<xypron>
Tartarus: one for DM_USB one for non DM
<sjg1>
apalos: It's OK for xypron to do it
<sjg1>
milkylainen_: I believe it should use the EFI .lds script for the app
mmu_man has joined #u-boot
<milkylainen>
I'm just confused.. I don't think the app uses the EFI .lds scripts. In 32-bit or not. It looks like it builds the lds from the regular generic lds. Payload uses the EFI .lds though.
<milkylainen>
sjg1^
<Tartarus>
xypron: Right so, OK, the code just behaves widly different in bootefi vs booti
<Tartarus>
xypron: Can you add a few debug prints like this:
<xypron>
Tartarus: the unmached boots fine with U-Boot
<xypron>
and bootefi
<xypron>
Tartarus: it is already late. I have a look tomorrow
<Tartarus>
Thanks
___nick___ has quit [Ping timeout: 256 seconds]
<Tartarus>
sjg1: Any idea how the DM version of usb_stop could get different paths on booti vs bootefi?
redbrain has quit [Ping timeout: 240 seconds]
gsz has quit [Quit: leaving]
<xypron>
sjg1: Tartarus: initializing the UEFI subsystem scans all block devices
<xypron>
Tartarus: execute 'efidebug memmap' before booti. Does the error occur?
<Tartarus>
Note that in this case I don't have anything actually plugged in via USB (I did when I first stumbled on this problem, but removed that variable)