<sjg1>
So EFI is not removing the USB for some reason
<sjg1>
Can you make EFI call announce_and_cleanup() ?
<Tartarus>
and also doing a quick/stupid dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL | DM_REMOVE_NON_VITAL); in efi_exit_boot_services after the current dm_remove_devices_flags doesn't fix it
<Tartarus>
but..
<Tartarus>
does get the hub
<Tartarus>
and hm maybe
<sjg1>
-129 is -EKEYREJECTED
<Tartarus>
So, EFI can't call announce_and_cleanup since you have to let EFI deal with cache/interrupts I want to say for some reason?
<Tartarus>
Is why that part of the logic isn't mirrored
<sjg1>
Tartarus: Maybe he just decided to write the same code again? It calls bootm_disable_interrupts() later
<Tartarus>
No, there's reasons for this
<sjg1>
If you dm_dump_all() at this point do you get the same dump for EFI and non-EFI?
<Tartarus>
Just put in dm_dump_all right after bootm_disable_interrupts
<Tartarus>
checking
<Tartarus>
Yeah, there's something special funny going on here
<Tartarus>
Related to the TI platform and/or it's glue
<Tartarus>
efi case crashes before bootm_disable_interrupts completes
<Tartarus>
adding debugs
<sjg1>
You could put a print before uclass_pre_remove_device() in device_remove() to be sure, but it looks like the USB thing is removed in the bootm case
<Tartarus>
... I hope I didn't title the logs wrong
<Tartarus>
bootm_disable_interrupts is crashing in efi
<sjg1>
The weird thing is that in EFI it see the flags value 20 in the log for the USB device
<sjg1>
That is DM_FLAG_ALLOC_PRIV_DMA
<sjg1>
So DM_FLAG_OS_PREPARE is not set
<sjg1>
But when I look at the ti,j721e-usb driver, it *is* set
<Tartarus>
The bad case is usb_stop is trying to do a device_remove
<Tartarus>
but instead leads to
<Tartarus>
ERROR: Unhandled External Abort received on 0x80000000 from EL2
<milkylainen_>
Then it'll probably segfault. Atleast my and sjg1s toolchains did.
matthias_bgg has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<xypron>
milkylainen_: how do you remove --whole-archive workaround? Is there a patch doing removing it?
<milkylainen_>
xypron: In commit fa89e29c4392dd526274f073067cd3268f22552a there is a delta to Makefile. That has to be reverted.
<milkylainen_>
top level Makefile even
<xypron>
milkylaine: that still build. But the output is not any EFI binary.
<xypron>
Seems totally broken.
matthias_bgg has joined #u-boot
<milkylainen_>
If the --whole-archive workaround is still there you'll get an almost empty file.
<milkylainen_>
But it will link.
<milkylainen_>
If I remove that then my toolchain segfaults.
<milkylainen_>
So I can see several things here.
<milkylainen_>
1. ld is broken. Now fixed.
<milkylainen_>
2. u-boot lds is broken. still in progress.
<xypron>
milkylainen: I remove the two lines at Makefile 1763
<milkylainen_>
3. does even the app use the proper lds?
<milkylainen_>
xypron: Remove? There is a delta?
<xypron>
milkylaine_: You said I should revert the changes in Makefile which added $(if $(CONFIG_EFI_APP_64BIT),,--whole-archive), $(if $(CONFIG_EFI_APP_64BIT),,--no-whole-archive)
<milkylainen_>
yes, revert, not remove. :)
<xypron>
The patch adds those lines
<xypron>
Reverting means removing
<milkylainen_>
You still have to keep --whole-archive?
<milkylainen_>
sjg1: Well H.J Lu is right. The 32-bit app has completely different lds to the 64-bit app.
<milkylainen_>
There seems to be a major malfunction in what produces what somewhere.
<milkylainen_>
One thing I never understood is why u-boot has two switches for EFI-things.
<milkylainen_>
under mainboard model: CONFIG_TARGET_EFI_APP32 and under library: EFI_APP_32BIT
smartin has joined #u-boot
<xypron>
milkylainen_: that is only for the APP. For UEFI API: CONFIG_EFI_LOADER.
<xypron>
milkylainen: git grep -n '/DISCARD/' | grep plt points to many places that discard plt sections. So if this a problem to ld, this needs to be fixed in all those places.
<milkylainen_>
xypron: Well. That's sort of also an issue. I don't understand why you can't discard .plt in something like u-boot. It doesn't make a whole lot of sense either. I guess you can, but they your builds must probably account for not going through the .plt.
<milkylainen_>
Maybe some sort of glibc infection where even static binaries have a plt/got.
<apalos>
find -name *.lds
<milkylainen_>
Even though u-boot probably is nostdlib?
<apalos>
err wrong window!
<milkylainen_>
:)
<milkylainen_>
well. In 64-bit app mode it doesn't use ./arch/x86/lib/elf_x86_64_efi.lds but rather ./arch/x86/cpu/u-boot-64.ld
<milkylainen_>
s/ld/lds even
_whitelogger has quit [Ping timeout: 264 seconds]
_whitelogger has joined #u-boot
<milkylainen_>
It's because it relies on the payload efi stub config to select lds?
<milkylainen_>
which isn't selected in app mode?
<milkylainen_>
hmm. no.
<milkylainen_>
ifeq ($(CONFIG_EFI_STUB_64BIT),)
<milkylainen_>
they seem wrong in app mode?
mmu_man has joined #u-boot
<milkylainen_>
Yeah. Think I found it.
<milkylainen_>
sjg1: arch/x86/cpu/config.mk overrides LDSCRIPT in x86_64 mode...
<milkylainen_>
sjg1: I'll leave it up to you to decide the correctness of using EFI_APP like that. :)
smartin1 has joined #u-boot
smartin has quit [Read error: Connection reset by peer]
smartin1 is now known as smartin
GNUtoo has quit [Remote host closed the connection]
torez has joined #u-boot
tnovotny has joined #u-boot
tnovotny has quit [Client Quit]
tnovotny has joined #u-boot
<EdSwarthout>
0
<EdSwarthout>
, +
<EdSwarthout>
I'm new to "dfu", is there a reason "skip" is only available for MMC and not SF? Seems useful for SF too
torez has quit [Ping timeout: 268 seconds]
torez has joined #u-boot
<sjg1>
milkylainen_: Nice work on that binutils bug!
<milkylainen_>
sjg1: tnx. Still won't start on a 64-bit UEFI instance. Might be something local to me though.
<sjg1>
milkylainen_: I may be able to look this morning, else will be tonight
<Tartarus>
sjg1, xypron, OK, so my first morning test (and now I need to run an errand) is that yes, whacking in announce_and_cleanup() instead of the variant of that efi_exit_services codes does work
<Tartarus>
I'll compare/contrast more soon
<sjg1>
Tartarus: Well as I keep saying, EFI has too much of its own code (90KB and counting) and needs to integrate with U-Boot better
<Tartarus>
Well, announce_and_cleanup() isn't exported/standardized either
<Tartarus>
x86 has bootm_announce_and_cleanup which might be about the same (only git grep'd) and riscv did copy arm
<Tartarus>
Which is all the platforms EFI cares about
torez has joined #u-boot
fdanis is now known as fdanis_away
milkylainen has joined #u-boot
<milkylainen>
hi.
torez has quit [Ping timeout: 264 seconds]
matthias_bgg has joined #u-boot
<Tartarus>
sjg1: Like, OK, I've narrowed it down to announce_and_cleanup relies on something else having already shutdown USB. So taking the existing code and NOT calling bootm_disable_interrupts() also "fixes" this problem.
as2334 has joined #u-boot
torez has joined #u-boot
<as2334>
any hints as to why loaderimage.c(a rockchip utility) is missing from tools?
<Tartarus>
as2334: they didn't upstream it yet?
mckoan is now known as mckoan|away
<as2334>
Tartarus I don't know. It used to be there I think but it's been removed apparently. I got a copy from an older fork.
<sjg1>
Tartarus: So long as we avoid duplicating the code I am happy
<Tartarus>
sjg1: Note that 529441ca89b isn't quite the problem I'm seeing
<Tartarus>
It's the bootm_disable_interrupts() call that's been there since code inception
eloi1 has joined #u-boot
<sjg1>
Tartarus: Really I mean that that code should be been the point where someone wondered whether copying the code was a good idea
eloi1 has quit [Ping timeout: 264 seconds]
<Tartarus>
sjg1: Yeah, ok, but it's not like do_bootm_states() is easy to call in to and I'm not sure there is an easy mapping over
<Tartarus>
Could we maybe have a more generic function? Maybe. Depends on why do_bootm_states is doing bootm_disable_interrupts() in a very much different spot
<Tartarus>
OR if EFI could be calling cleanup_for_linux() just like a stripped down announce_and_cleanup() would
<sjg1>
Tartarus: This is really my point. The EFI stuff has always been about the path of least resistance, the quickest way to hack it in. Can't these guys take a proper look at it and sort it out?
<sjg1>
Tartarus: If people just hack around it just creates chaos
vagrantc has joined #u-boot
redbrain has quit [Ping timeout: 256 seconds]
matthias_bgg has quit [Quit: Leaving]
smartin has quit [Ping timeout: 260 seconds]
smartin has joined #u-boot
___nick___ has joined #u-boot
GNUtoo has joined #u-boot
GNUtoo_ has joined #u-boot
GNUtoo_ has quit [Remote host closed the connection]
<sjg1>
Tartarus: little problem I noticed...the env-to-text stuff requires a POSIX-compliant gawk, so mawk does not work
<sjg1>
Tartarus: I'm not sure if it is possible to make mawk work...but perhaps we should make it run gawk explicitly?
mmu_man has quit [Ping timeout: 240 seconds]
<Tartarus>
Oh goodness...
<Tartarus>
POSIX and not some GNU extension?
___nick___ has quit [Ping timeout: 256 seconds]
torez has quit [Quit: torez]
<milkylainen>
umm. gawk is not posix? you can run gawk in compatible mode though?
<milkylainen>
There you should only have posix features?
GNUtoo has quit [Ping timeout: 276 seconds]
<sjg1>
Tartarus: milkylainen_ Well actually the 3-arg match() is a GNU extension
camus has quit [Ping timeout: 260 seconds]
camus has joined #u-boot
<milkylainen>
Bedtime here. Have a nice evening.
<Tartarus>
sjg1: Ah, well there's the problem then.
<Tartarus>
No, we can't say GNU tools only.
<sjg1>
Tartarus: yes...I only noticed it when running on an old machine
<sjg1>
I will take a look later
mmu_man has joined #u-boot
smartin has quit [Quit: smartin]
GNUtoo has joined #u-boot
tambarus has quit [Quit: Connection closed for inactivity]