00:12 <Danilo82> can somenone inform me if compiling mkimage fromt this source will make a modified mkimage or its just going to be the same?

00:12 <Danilo82> https://github.com/neuschaefer/mstar-mboot/

12:59 <marex> milkylainen_: you're now digging in u-boot x86-64, right ?

12:59 <milkylainen_> marex: yup.

13:02 <marex> milkylainen_: I noticed it is possible to easily overwrite stack on running u-boot x86-64, if I understand it correctly

13:03 <marex> as far as I can tell, the stack isn't sitting right under relocated u-boot , at least that is what reading out %rsp tells me

13:03 <marex> sjg1: ^

13:03 <milkylainen_> marex: Under what scenario?

13:04 <milkylainen_> Loading stuff or during init?

13:04 <marex> qemu x86-64 has stack at 0x10d638 per %rsp

13:04 <marex> and it has u-boot at 0x0000000006f58000

13:07 <milkylainen_> What does bdinfo say when you start into shell?

13:08 <marex> milkylainen_: bdinfo does not contain rsp value

13:08 <milkylainen_> That looks strange. I'd expect stack pointer to be above + a resonable bit of space.

13:08 <milkylainen_> Hmm. ARM?

13:09 <milkylainen_> I thought bdinfo gave stack pointer.

13:09 <milkylainen_> I switched to toying with barebox a night or so. Since u-boot does not have any means of accessing my eMMC right now.

13:11 <marex> yeah, I was somehow forced to use barebox in a project recently too, USB was completely unusable because it is a fork of decade old stack with all the bugs that were fixed since, I got so many other crashes and problems that it looks this barebox will go out of the window soon

13:12 <marex> so back to u-boot ... :)

13:19 <milkylainen_> https://github.com/u-boot/u-boot/commit/59b0d7d839f135bc44d3459784337a657149f8b3#diff-a1fc6f453984e4ecfb82d9fe8cf3090a92019e6da4864d4b4960c5a1f670f0a6

13:20 <milkylainen_> ARM did have an SP print. Moved to arch though.

13:20 <milkylainen_> Actually. Don't know why stuff like SP can't be abstracted enough on this level to be non arch stuff.

13:24 <milkylainen_> marex: Do you have any information on the current layout?

13:25 <marex> layout of what ?

13:25 <marex> rsp is somewhere in the lower end of the DRAM area

13:26 <milkylainen_> layout of memory.

13:31 <marex> well, yeah ... 0x8000000 of DRAM , u-boot is relocated in the top 3/4, except for that %rsp stack which is at 0x100000 or so (low)

13:31 <marex> sjg1: ^

13:46 <milkylainen_> Hrrm. And heap is sitting at?

14:02 <marex> milkylainen_: below u-boot, it is just the stack that's at the wrong place

14:04 <milkylainen_> marex: Not missing any bits of the %rsp 64-bit printouts?

14:05 <marex> milkylainen_: nope

14:12 <milkylainen_> marex: Is it some legacy UEFI existing stack that U-boot reuses?

14:15 <sjg1> milkylainen_: marex For 64-bit U-Boot on x86 some work remains, particularly in memory setup. See PAGETABLE_BASE which is in low memory

14:16 <sjg1> milkylainen_: marex Also start64.S is where U-Boot starts after SPL has switched to 64-bit. It uses the existing stack rather than setting up a new one

14:16 <milkylainen_> that would explain it.

14:17 <milkylainen_> So you always have an SPL in x86_64?

15:29 <sjg1> milkylainen_: Yes SPL is 32-bit since you cannot boot in 64-bit on an x86 machine. Also I'm not sure how you run things like the video bios in 64-bit

15:31 <sjg1> Tartarus: Thanks for the pointers. I found that Fedora 34 uses a .efi and 31 uses extlinux.conf so everything is working well. I have some improvements to the PXE code to send out at some point and have added some tests