<kettenis>
for the others I'd need to do some work
<kettenis>
(those aren't really relevant for the EL2 Host mode issue though)
indy has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
indy_ has joined #u-boot
indy has quit [Ping timeout: 240 seconds]
sicelo has quit [Quit: Bye!]
littlebobeep has joined #u-boot
sicelo has joined #u-boot
sicelo has joined #u-boot
sicelo has quit [Client Quit]
sicelo has joined #u-boot
sicelo has joined #u-boot
sicelo has quit [Quit: Bye!]
littlebobeep has quit [Ping timeout: 240 seconds]
sicelo has joined #u-boot
indy_ is now known as indy
littlebobeep has joined #u-boot
<Tartarus>
marex: Seems fine for next
<milkylainen>
Tartarus: Can an u-boot build tell the external world what final images it has generated in a build?
<Tartarus>
milkylainen: I don't quite follow you, sorry, can you give an example of what you mean?
<milkylainen>
Tartarus: So. For a lot of targets there are a lot of different image formats, suffixes, and whatnots. In an build environment (buildroot etc), copying variable target names is a pita, because they vary wildly (bin, srec, elf, efi, imx, stm32 etc etc etc). It would be nice if the build could place the generated files in a "generated-images" file
<milkylainen>
and path. So then the external environment could just read this file, without knowing what to search for. Since the build specifies what files are there.
<apritzel>
kettenis: I was just curious which TCR bits exactly would trigger the issue you've seen, and many higher bits depend on later arch features
<milkylainen>
Right now, the external env has to preemptively know file format to do the copy.
<kettenis>
apritzel: pretty sure it is just the ips bits that were wrong
<kettenis>
M1 Pro/Max/Ultra have memory starting at 0x1000000000 so they need the larger physical address spaces enabled
<apritzel>
kettenis: I see, makes sense
apritzel_ has joined #u-boot
<apritzel>
the usage of get_tcr() looks fishy, two callers pass "0" for the "el", which we treat as EL3, but everyone else wants "current EL", so I am tempted to remove that parameters and query the current EL internally
<kettenis>
I think that would be fine
<apritzel>
I think the 0-callers just want the VA size bits, they ignore the return value
<kettenis>
they do
<apritzel>
kettenis: thanks, I will just reply to the email
<kettenis>
as maz pointed out on #asahi-dev, it probably makes sense to introduce a function that indicates that we're in EL2 Host mode
<kettenis>
but as I pointed out in my mail, I'm not sure about growing the size of this code
apritzel_ has quit [Ping timeout: 244 seconds]
<apritzel>
but that's just a few instructions, so I wouldn't worry about that
camus has quit [Quit: camus]
littlebobeep has quit [Ping timeout: 240 seconds]
umbramalison has joined #u-boot
tre has quit [Remote host closed the connection]
<umbramalison>
trying to use pxe to boot a ti board. is it supposed to load pxelinux.0? seems like it's not looking for it's own config file
zandar has joined #u-boot
<zandar>
Hi, please can someone confirm that subscription to the U-Boot mailing list works OK? I tried to subscribe last week and once again yesterday but got no response.
zandar has quit [Quit: Leaving.]
zandar has joined #u-boot
<Tartarus>
zandar: Yes, it should be working fine
<Tartarus>
apritzel, kettenis for v2022.07 should I just revert that change?
<apritzel>
Tartarus: I don't know, I see that's tempting, but it fixes an actual boot problem with the fastmodel (implementing ARMv8.4 features)
<Tartarus>
OK. I can wait a bit for everyone to figure out whats best
<apritzel>
I'll send the patch in a minute
littlebobeep has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
<marex>
Tartarus: it was posted way before rc1, so it should be fine even for this release
Ntemis has joined #u-boot
vagrantc has joined #u-boot
<kettenis>
Tartarus: I'll test the diff when I get home in a few hours
Ntemis has quit [Read error: Connection reset by peer]
<cambrian_invader>
milkylainen: wouldn't you still have to specify the final image?
<cambrian_invader>
e.g. on some targets you have multiple images generated, and the one to use depends on the use-case
<LetoThe2nd>
is there a (non-crazy) way to load the environment from usb on a raspi (e.g., booting from sd card)?
<Tartarus>
Having ENV_IN_FAT or ENV_IN_EXT4 ?
<LetoThe2nd>
Tartarus: re-poked coworker, and its abouting all from USB. well, I'll.
<Tartarus>
Right, but ENV_IN_FAT should be fine with USB
<Tartarus>
(same with ENV_IN_EXT4)
<LetoThe2nd>
Tartarus: kay, thanks!
<Tartarus>
ENV_FAT_INTERFACE="usb" and so on
NonaSuomy has quit [Ping timeout: 246 seconds]
gsz has quit [Quit: leaving]
<zandar>
Tartarus: Thanks, I can confirm the subscription works with my private (gmail) address. But it does not work with my company address. I already discussed with our IT dpt. and they confirmed no messages were received by the Microsoft servers from u-boot-request@lists.denx.de recently.
<Tartarus>
zandar: Ugh. Well, given what I'm talking about here, and over in the OpenEmbedded channels too, I would encourage you to setup lei instead if possible.
<Tartarus>
I'll poke the denx folks all the same.
<umbramalison>
how to print a u-boot variable such that it wraps the output? `env print` on a very long variable definition. Using minicom incase that's the constraint?
<umbramalison>
(I can't see the end of the definition as it's beyond the length of the terminal)
<Tartarus>
umbramalison: Yes, it sounds like minicom isn't wrapping when it should
<cambrian_invader>
(picocom is a very nice terminal emulator and doesn't have all of minicom's "features"
* vagrantc
is partial to screen :)
<urja>
minicom -w
<mps>
yes, I always use screen
<umbramalison>
so i dusted off my original rpi, but sadly as of this year or late last year, support for it has finally ceased and the repo mirrors are down. So without starting another procrastination opportunity i'm stuck with minicom.
<umbramalison>
CTRL-A Z O R ;-) working
<umbramalison>
and thanks for pointing me in the right direction.
frieder has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 258 seconds]
zandar has quit [Ping timeout: 258 seconds]
ldevulder_ has joined #u-boot
NonaSuomy has joined #u-boot
ldevulder has quit [Ping timeout: 260 seconds]
<Tartarus>
marex: re USB251xB yes, I should have picked it up earlier in the cycle, sorry. Is it a problem if it waits for the next release? If so, yes, I'll put it in my queue for -rc5, if it can wait I'll grab it for -next shortly.
sobkas has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
NonaSuomy has quit [Ping timeout: 260 seconds]
NonaSuomy has joined #u-boot
<marex>
Tartarus: I have a board patch which removes a wall of ad-hoc env hackage due to that driver, so I'll pick it via usb shortly