<polprog>
What is the function of global_data.reloc_off?
<polprog>
Or rather, why is u-boot second stage relocating after being loaded to ram by SPL?
rvalue has quit [Remote host closed the connection]
rvalue has joined #u-boot
mmu_man has joined #u-boot
GNUtoo has quit [Ping timeout: 252 seconds]
stefanro has joined #u-boot
GNUtoo has joined #u-boot
sakman has joined #u-boot
mmu_man has quit [Ping timeout: 255 seconds]
rockosov has quit [Ping timeout: 260 seconds]
rockosov has joined #u-boot
persmule has quit [Remote host closed the connection]
mmu_man has joined #u-boot
gsz has joined #u-boot
f_ has joined #u-boot
ikarso has joined #u-boot
goliath has joined #u-boot
stefanro has quit [Quit: Leaving.]
mmu_man has quit [Ping timeout: 255 seconds]
mmu_man has joined #u-boot
dsimic has quit [Ping timeout: 260 seconds]
dsimic has joined #u-boot
pgreco has joined #u-boot
pgreco_ has quit [Ping timeout: 248 seconds]
prabhakarlad has joined #u-boot
mmu_man has quit [Ping timeout: 264 seconds]
mmu_man has joined #u-boot
<Tartarus>
Because we know where the start of memory is, but don't really want to be running there ourselves and relocate to the end of memory (more or less) to work from
<Tartarus>
Kinda-sorta historically since people tend to think "let me start loading my OS and other stufff at the start of memory and work towards the end", so if we're there too then we get overwritten and the world hangs
<marex>
Tartarus: we clearly need virtual memory
qqq has quit [Read error: Connection reset by peer]
qqq has joined #u-boot
persmule has joined #u-boot
prabhakarlad has quit [Ping timeout: 245 seconds]
<Forty-Bot>
tbh, it wouldn't be too hard to do... we already do map_sysmem for sandbox
<marex>
Forty-Bot: and since we already have cyclic framework ...
<Forty-Bot>
and an abi (standalone)
mmu_man has quit [Ping timeout: 258 seconds]
mmu_man has joined #u-boot
<Forty-Bot>
speaking of, should map_sysmem be paired with unmap_sysmem?
mmu_man has quit [Ping timeout: 255 seconds]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
<marex>
Forty-Bot: I would think so
<Forty-Bot>
yeah, but what if we are going to jump to the image
<Forty-Bot>
e.g. spl_load_fit_image never unmaps anything
<marex>
Forty-Bot: we probably need to unmap everything before the jump ?
<marex>
Forty-Bot: carefully unmap everything
<Forty-Bot>
yeah, but when we do the jump it has to be mapped
<Forty-Bot>
otherwise we jump to TEXT_ENTRY and segfault
swiftgeek has quit [Ping timeout: 240 seconds]
swiftgeek has joined #u-boot
zear has quit [Quit: bye]
zear has joined #u-boot
f_ has quit [Ping timeout: 240 seconds]
<marex>
Forty-Bot: maybe we'd need some special case 1:1 preboot mapping then
<Forty-Bot>
I'm more inclined to do e.g. map(fit); map(load_addr); unmap(fit)
<Forty-Bot>
*with a memcpy() as the third step
<Forty-Bot>
or ->read etc.
niska has quit [Quit: Leaving]
niska has joined #u-boot
GNUtoo has quit [Ping timeout: 252 seconds]
GNUtoo has joined #u-boot
f_ has joined #u-boot
f_ has quit [Ping timeout: 260 seconds]
qqq has quit [Quit: leaving]
deathmist has quit [Remote host closed the connection]
deathmist has joined #u-boot
<marex>
Forty-Bot: well why not :)
<Forty-Bot>
well, even easier than that is to just skip the unmap
<Forty-Bot>
since afaik they aren't refcounted
<Forty-Bot>
and if they overlap there is a problem
<marex>
Forty-Bot: I think I should get back to reviewing patches :)
<marex>
Forty-Bot: maybe we should have u-boot hackaton around fosdem, heh
* Forty-Bot
is just trying to get the spl_load stuff out the door
deathmist has quit [Ping timeout: 260 seconds]
deathmist has joined #u-boot
mmu_man has joined #u-boot
vagrantc has joined #u-boot
thopiekar has quit [Ping timeout: 245 seconds]
thopiekar has joined #u-boot
<marex>
Forty-Bot: I wish you success
<vagrantc>
i was a little surprised to see that ... i've been maintaining the u-boot packages in debian for about 10 years now ... :)