Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2021.10 is OUT / Merge Window is OPEN until 25 October 2021 / Release v2022.01 is scheduled for 10 January 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
Greenlight has quit [Quit: Leaving]
qastokes has joined #u-boot
<Tartarus> sjg1: Was there a "dump the current dm tree" debug function I can drop in places?
qastokes has quit [Quit: qastokes]
qastokes has joined #u-boot
alpernebbi has quit [Remote host closed the connection]
<sjg1> Tartarus: dm_dump_all()
alpernebbi has joined #u-boot
<Tartarus> sjg1: OK
<Tartarus> sjg1: and to start with, I changed all of the log_warning/debug in device-remove.c to printf, and here's what I see
<Tartarus> which I think at least helps to start to show whats up, but does it give you an ah-ha where to look?
<Tartarus> and afk dinner
<Tartarus> the usb stuff being removed in the booti but not bootefi case is the symptom, lots more kept on tho in that efi case
samekh_ has quit [Ping timeout: 265 seconds]
samekh has joined #u-boot
mmu_man has quit [Ping timeout: 250 seconds]
mckoan|away has quit [Ping timeout: 265 seconds]
<sjg1> Tartarus: well this is probably an inconsistency between EFI and bootm. It looks like bootefi does not use the bootm code at all
<sjg1> Tartarus: no surprise there I suppose :-(
<sjg1> The flags value is the one passed into dm_remove_devices_flags()
<sjg1> In this case 4600 is bits 9, 10, 14 set, i.e. DM_FLAG_ACTIVE_DMA | DM_FLAG_OS_PREPARE | DM_FLAG_VITAL
<sjg1> The efi one is missing DM_FLAG_VITAL
<Tartarus> sjg1: the efi code calls the same prepare for linux function as bootm
zibolo has quit [Ping timeout: 265 seconds]
zibolo has joined #u-boot
<sjg1> Tartarus: It looks like the EFI code does not call announce_and_cleanup(), but does its own thing
<Tartarus> Now, I do see:
<Tartarus> drivers/usb/cdns3/cdns3-ti.c: .flags = DM_FLAG_OS_PREPARE,
<sjg1> Tartarus: See efi_exit_boot_services()
<Tartarus> ok, also, ok, sec..
<sjg1> Tartarus: I don't actually see any devices that set the DM_FLAG_VITAL flag
<sjg1> So perhaps the problem is that EFI removes these ones:
<Tartarus> Those are the ones that booti removes and efi doesn't remove I believe
<Tartarus> and leads to the crash I'm trying to debug
vagrantc has quit [Quit: leaving]
<sjg1> Tartarus: Which one is correct?
<Tartarus> booti works bootefi causes a crash
<Tartarus> and OPTEE takes the exception
<sjg1> Do you know which driver usb_hub is?
<Tartarus> nop 4 [ ] cdns-ti | |-- cdns-usb@4104000
<Tartarus> nop 5 [ + ] cdns-ti | |-- cdns-usb@4114000
<Tartarus> usb 0 [ ] cdns-usb3-peripheral | | `-- usb@6000000
<Tartarus> usb 0 [ + ] cdns-usb3-host | | `-- usb@6400000
<Tartarus> usb_hub 0 [ + ] usb_hub | | `-- usb_hub
<Tartarus> from dm tree
<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
<Tartarus> ERROR: exception reason=0 syndrome=0xbf000000
<Tartarus> Unhandled Exception from EL2
<Tartarus> So maybe that ti cadance glue is missing a DM flag somewhere?
<Tartarus> I gotta step away for the night, but I think there's something screwy in drivers/usb/cdns3/cdns3-ti.c
<Tartarus> Rather than just the EFI code
<Tartarus> Maybe the efi code is different enough that it's exposing a problem, but it works for everything else
mckoan|away has joined #u-boot
<sjg1> OK, I',m not sure. But if you add the debugging I suggested you should see the drv->flags value in the bootm case, which might shed light
mckoan|away has quit [Ping timeout: 240 seconds]
mckoan|away has joined #u-boot
mripard has quit [Ping timeout: 260 seconds]
mripard has joined #u-boot
qastokes has quit [Quit: qastokes]
mckoan|away has quit [Ping timeout: 268 seconds]
qastokes has joined #u-boot
mckoan|away has joined #u-boot
FredO2 has quit [Quit: Leaving]
qastokes has quit [Quit: qastokes]
qastokes has joined #u-boot
qastokes has quit [Read error: Connection reset by peer]
qastokes has joined #u-boot
qastokes_ has joined #u-boot
qastokes has quit [Ping timeout: 260 seconds]
qastokes_ has quit [Quit: qastokes_]
qastokes has joined #u-boot
qastokes has quit [Read error: Connection reset by peer]
qastokes has joined #u-boot
qastokes has quit [Quit: qastokes]
qastokes has joined #u-boot
qastokes has quit [Client Quit]
qastokes has joined #u-boot
qastokes has quit [Ping timeout: 264 seconds]
qastokes has joined #u-boot
stefanro has quit [Remote host closed the connection]
fdanis_away is now known as fdanis
stefanro has joined #u-boot
qastokes has quit [Quit: qastokes]
mckoan|away is now known as mckoan
tre has joined #u-boot
<milkylainen_> sjg1, Tartarus, xypron: https://sourceware.org/bugzilla/show_bug.cgi?id=28597 regarding 64-bit uefi app not linking.
tambarus has joined #u-boot
stefanro has quit [Quit: Leaving.]
<xypron> millylainen: what are the steps to reproduce the issue?
sszy has joined #u-boot
stefanro has joined #u-boot
<milkylainen_> xypron: Bulding efi-working: https://source.denx.de/u-boot/custodians/u-boot-dm/-/tree/efi-working with 64-bit app and removing the --whole-archive workaround sjg1 added to the Makefile.
<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?
<xypron> no
<milkylainen_> that's what I see in my delta.
<xypron> ok now it segfaults
<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...
michalkotyla has joined #u-boot
<milkylainen_> sjg1: My delta to efi-working: https://paste.debian.net/1220039/
<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
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
torez has quit [Ping timeout: 240 seconds]
tre has quit [Remote host closed the connection]
tnovotny has quit [Quit: Leaving]
matthias_bgg has quit [Ping timeout: 268 seconds]
<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: Offending commit 529441ca89b efi_loader: Disable devices before handing over control
<sjg1> maybe?
<sjg1> Tartarus: But it would be much nicer if this code could be unified. Do we really want two copies of everything with the EFI copy being broken?
<Tartarus> sjg1: I'm not convinced the EFI one is broken
<sjg1> Tartarus: Since it duplicates existing code, it is broken by definition. We should not be copying code about the place
<Tartarus> In that it's doing something similar to the do_bootm_states stuff, yes, there's duplication
<Tartarus> But that code path too is less than clear and easy to use at times.
<Tartarus> Lemme figure out what's at fault here, period, and then we can see what needs changing where
<as2334> loaderimage.c is missing in this zip though https://github.com/rockchip-linux/u-boot/archive/master.zip
<as2334> is that a github.com bug?
<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]
agust has quit [Quit: Leaving.]