<eloi1>
Hi marex it is quite easy to reproduce with a random file of 10Mb (dd if=/dev/random of=test_file.img count=10 bs=1M)
<eloi1>
I also manage to upload over DFU to ram instead of ext4 without restrictions on the file. It is WA as it is more convenient to me to deal with ext4 directly.
qastokes has quit [Remote host closed the connection]
qastokes has joined #u-boot
fdanis_away is now known as fdanis
guillaume_g has joined #u-boot
agust has joined #u-boot
<Xogium>
michalkotyla: owww this is down right mean. U-boot makes the cpu hard fault
<Xogium>
it then jumps to the midle of disable_mpu finction for… whatever reason
<Xogium>
trying to find how to ask the cpu what fault it was
monstr has joined #u-boot
lucaceresoli has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
sszy has joined #u-boot
mckoan|away is now known as mckoan
sstiller has joined #u-boot
<Xogium>
soooooo… it looks like u-boot.bin is, built wrong
<Xogium>
as it, completely wrong
<Xogium>
I'm very confused
<Xogium>
maybe there is some logic for this I have not thought about, and I've got it wrong, but so far…
<Xogium>
gdb says I'm in the reset function but I'm not. The ELF shows correct in objdump, addresses are all good
<Xogium>
however .bin is different and it points to some other part of the code
mmu_man has joined #u-boot
<Xogium>
the gdb symbols are all offset wrong
<Xogium>
the elf sounds sane but the .bin seems busted
<Xogium>
how does u-boot generate the .bin file ? Objcopy ?
<apalos>
dont you need u-boot.stm32 for that board?
<apalos>
or u-boot.stm dont remember the exact naming
<Xogium>
apalos: I'm not aware of it ? Also u-boot has a defconfig for stm32f769-disco so…
<Xogium>
apalos: do you mean in complement to u-boot ? Hmm. Maybe you mix up with afboot-stm32
redbrain has joined #u-boot
<apalos>
maybe that's for the _trusted defocnfigs only
<Xogium>
apalos: possibly… that one isn't trusted. I don't think TF-A is even a thing on cortex m7
<apalos>
no theyu got tf-m for that
<Xogium>
ahah I should have known
<Xogium>
but yeah its frankly weird, can we agree that at least the ELF and .bin shouldn't have completely different offset/memory adresses ?
<Xogium>
gdb believes I'm in the reset function while hexdump on .bin shows that this address is… not at all reset
<apalos>
u-boot relocates it self,
<Xogium>
hmm
<apalos>
so there's should be a different of the offset in there, but that's just about it
<Xogium>
this seems to happen before relocation can even occure
<apalos>
oh I misread that,
<apalos>
it depends on how .bin gets generated
<Xogium>
I've connected openocd to my board, gdb, and loaded the u-boot ELF, and its completely different from the hexdump of the .bin
<Xogium>
so whatever gdb says is like not in sync with what the board has
<Xogium>
it doesn't even get to run any u-boot code
<Xogium>
but gdb makes me think it did
matthias_bgg has joined #u-boot
<Xogium>
I think… objcopy is moving 08008000 to 0
<Xogium>
since it only copy .txt
<Xogium>
and that blows up
<Xogium>
that's text_base
qastokes has quit [Quit: qastokes]
gsz has joined #u-boot
mckoan has quit [Ping timeout: 265 seconds]
mckoan has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
smartin has joined #u-boot
<Xogium>
finally got it to output stuff ! Which I call progress
mmu_man has joined #u-boot
bradfa has joined #u-boot
camus has quit [Ping timeout: 265 seconds]
camus has joined #u-boot
<Xogium>
ok so… confusion was brought on by the fact that somehow buildroot uses only u-boot.bin… Not the spl. I wonder how that even worked in the very first place
<Xogium>
ugh
<Xogium>
spent days on this
torez has joined #u-boot
<dvergatal>
Forty-Bot: ah with [BUG] in a subject ok because i have send a message yesterday without it
<dvergatal>
Forty-Bot: i'll resend it again
<dvergatal>
Forty-Bot: done
<Forty-Bot>
well, it's not 100% necessary to have it in the subject
macromorgan has quit [Quit: Leaving]
<dvergatal>
Forty-Bot: aahh ok
<dvergatal>
i thought it is
lucaceresoli has quit [Remote host closed the connection]
monstr has quit [Remote host closed the connection]
michalkotyla has quit [Quit: michalkotyla]
smartin has quit [Ping timeout: 256 seconds]
sstiller has quit [Ping timeout: 250 seconds]
<sjg1>
milkylainen_: Re the .lds file, if you build with V=1 you will see it
tambarus has quit [Quit: Connection closed for inactivity]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<Tartarus>
sjg1, xypron, interesting. I finally bootefi'd my amlogic board (arm64 and XHCI usb) and it also shuts down USB correctly, so there's something funny with the TI J7 specific glue
cpackham[m] has joined #u-boot
mvaittin has joined #u-boot
kallisti5[m] has joined #u-boot
samueldr has joined #u-boot
LinuxHackerman has joined #u-boot
<xypron>
Tartarus: could you give my u-boot-test-hooks patch for swtpm some love. Than we can finally enable CI testing of measured boot.
guillaume_g has quit [Quit: Konversation terminated!]
gsz has quit [Quit: leaving]
mthall has quit [Ping timeout: 256 seconds]
smartin has quit [Remote host closed the connection]
smartin has joined #u-boot
___nick___ has quit [Ping timeout: 264 seconds]
mthall has joined #u-boot
<sjg1>
Tartarus: I have a Odroid-C4 now...which one do you have?
<Tartarus>
sjg1: Well, the failure seems to be j721e specific at least, I need to try another TI platform next, it's not XHCI generic
<Tartarus>
but it might be TI DWC3 glue specific
<sjg1>
Tartarus: OK
<EdSwarthout>
I'm getting "Could not memalign 0x800000 bytes" error with "dfu tftp mmc 0" for a raw image because both dfu_fill_entity_mmc and dfu_get_buf are malloc'ing 8MB buffers
sbach has quit [Read error: Connection reset by peer]
<ndesaulniers>
sjg1: I was able to get LLD-linked aarch64 u-boot to boot. Will have some changes to post upstream. Different issue affecting 32b ARM that I'm working through now. I hope to get all 3 of aarch64,arm,x86_64 booting when linked with LLD, then will likely submit them as a series upstream.
<sjg1>
Tartarus: OK
<EdSwarthout>
But for a raw image, dfu_file_buf is not used
sbach has joined #u-boot
<sjg1>
ndesaulniers: So use llvm just for the linking step?
<ndesaulniers>
sjg1: yes; for Android we're already compiling with Clang, and using LLVM's binutils substitutes except for the linker
smartin has quit [Quit: smartin]
<sjg1>
ndesaulniers: OK sounds good
<Tartarus>
Welp, :head-desk:, J721E is cadence not DWC3 for USB stuff
<Tartarus>
So amlogic test isn't relevant, whoops
<Tartarus>
assumed and forgot to check first, oops
<Tartarus>
still good to have amlogic in the lab now
<sjg1>
Tartarus: Ah....
<Tartarus>
sjg1: Is there anything in paricular I can enable to see what / where DM is shutting stuff down as we prepare to boot the OS?
<Tartarus>
There's something different in the booti vs bootefi cases on this board
<sjg1>
Tartarus: Nothing already there. You could add debug() to device_remove()
<sjg1>
Tartarus: after flags_remove() returns 0 (indicating that the device should be removed)
<sjg1>
debug(... dev->name, flags) or something
<Tartarus>
Lemme drop in log and see if that shows anything to start with