<bamse>
z3ntu: yeah, you need to enable twice...to get that extra juice out of it
Daanct12 has joined #linux-msm
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
davidinux has joined #linux-msm
Daanct12 has quit [Quit: WeeChat 4.0.5]
Daanct12 has joined #linux-msm
pespin has joined #linux-msm
Daanct12 has quit [Ping timeout: 480 seconds]
mripard has joined #linux-msm
<lumag>
sboyd, BTW: I have a question regarding very old stuff, 9e775ad19f52 ("ARM: 7012/1: Set proper TEXT_OFFSET for newer MSMs"). The Makefile has evolved since that time, but the main idea is still there. Now I'm facing an issue if I try to build the kernel that works for both 8960 (well, apq8064) and msm8974 (ok, again apq8074). 8974 silently fails to boot with the modified TEXT_OFFSET. Do you have an idea if that's an issue on 8974 side? Or if we can
<lumag>
workaround the smem issue in some other way?
<sboyd>
lumag: smem has to be at that location
<lumag>
Yep, I know.
<sboyd>
what is the question?
<sboyd>
why does 8974 silently fail to boot?
<lumag>
Basically two questions at the same time: do you know if 8974 should be booting with modified TEXT_OFFSET (it doesn't here)? Is it possible to move this kind of detection to head.S / some other part (e.g. by checking atags or machine ID)?
<lumag>
and 3) the kernel with standard TEXT_OFFSET boots fine on apq8064. Is it just a coincidence, decompressor being smart enough or apq vs msm difference?
<sboyd>
lumag: I don't know as I don't work at qcom. Where is smem placed on 8974? The problem is that the kernel text has to be shifted away from the start of memory so that smem can be left untouched
<sboyd>
otherwise the decompressor will place the kernel at the start of memory, i.e. smem
<lumag>
sboyd, I hoped you might have memory of that old stuff
<sboyd>
lumag: for #2 I don't think it can be auto-detected as I recall the TEXT_OFFSET is encoded into the __va() macro?
<sboyd>
lumag: I think you're suggesting that the decompressor stub learn about memory reservations, which I think rmk was opposed to
<sboyd>
lumag: 8974 may have been the time that smem was moved somewhere else
<lumag>
sboyd, yes, on 8974 smem was moved to the middle / end of memory.
<sboyd>
we fought hard to get it moved out of the start
<sboyd>
lumag: ok so then it doesn't need the text offset thing
<sboyd>
the memory before the text should be usable
<sboyd>
for #3 where is smem?
<sboyd>
is the kernel text placed into smem region?
<sboyd>
lumag: I think 8974 used to boot with the modified text offset
<sboyd>
pretty sure it was working years ago
<lumag>
for #3 on apq8064 smem is at the start of the RAM, but the kernel somehow copes with that.
<lumag>
Well, currently I'm pretty sure that it is broken with 2MB+0x800 TEXT_OFFSET.
<sboyd>
I would think the kernel just occupies smem with the kernel text
<lumag>
I assume this happens before OF parsing? Is there a way to check occupied addresses?
<lumag>
(I've never looked at those parts, so I'm significantly puzzled)
<sboyd>
lumag: yes there's memblock debugfs
<sboyd>
look at /sys/kernel/debug/memblock/reserved
<lumag>
0: 0x80004000..0x80007fff 0 NONE
<lumag>
1: 0x80100000..0x81ad86ef 0 NONE
<lumag>
2: 0x81c76a60..0x81c7fe04 0 NONE
<lumag>
4: 0xaeecdcc0..0xaef8dfc3 0 NONE
<lumag>
3: 0x83000000..0x85a92fff 0 NONE
<lumag>
and then it goes.
<lumag>
Let me try with the TEXT_OFFSET
<sboyd>
and where is smem?
<sboyd>
0x80000000-0x80200000?
<lumag>
Yep.
<lumag>
So it is reserved in /proc/iomem, but not in memblock.
<sboyd>
that range should be reserved in memblock
<sboyd>
what about the memory file?
<sboyd>
the first reserved part looks like the vectors
<lumag>
Memory is correct both with and w/o TEXT_OFFSET:
<lumag>
0: 0x80200000..0x88dfffff 0 NONE
<lumag>
1: 0x8a000000..0x8d9fffff 0 NONE
<lumag>
2: 0x8ec00000..0x8effffff 0 NONE
<lumag>
4: 0x90000000..0xfffffffe 0 NONE
<lumag>
3: 0x8f700000..0x8fdfffff 0 NONE
<lumag>
But the first reserved block jumps:
<lumag>
0: 0x80204000..0x80207fff 0 NONE
<lumag>
sboyd, ok. I got msm8974 to work with the modified TEXT_OFFSET. It seems I was missing the proper clock source
<sboyd>
lumag: ok so problem solved?
<lumag>
Yep.
<lumag>
I'll doublecheck it, but it looks so
<lumag>
Please excuse me for taking your time.
<sboyd>
great! I'm pretty sure the first reservation is the vectors
<sboyd>
in which case you don't want the kernel's exception entry code to live in smem
<lumag>
Hmm, no, re-check failed :-(
<lumag>
And 8074 is stuck somewhere
<sboyd>
are you booting zImage or Image?
<lumag>
zImage
<lumag>
I can try Image
<lumag>
sboyd, lk @ 8074 can not boot Image (both with the appended and with the separate dtb).
<lumag>
[7260] DTB offset is incorrect, kernel image does not have appended DTB
<sboyd>
lumag: ah right, zImage is basically manadatory
<sboyd>
it's a multiplatform image? so AUTO_ZRELADDR is set?
<lumag>
yes
<sboyd>
I wonder if 0673cb389512 ("ARM: 9045/1: uncompress: Validate start of physical memory against passed DTB") broke it
pespin has quit [Remote host closed the connection]
<sboyd>
that's basically looking at reserved memory, so maybe rmk is open to the idea of calculating zreladdr automatically
<lumag>
commenting out that block doesn't reenable 8974, so it's not.
<sboyd>
can you enable the serial debugging in the decompressor?
<sboyd>
look at DEBUG_QCOM_UARTDM in arch/arm/Kconfig.debug
<lumag>
yep, building
<sboyd>
I'm wondering where the decompressor is placing the image
<lumag>
sboyd, Error: invalid dtb and unrecognized/unsupported machine ID
<lumag>
r1=0x00000000, r2=0x00000000
<lumag>
Let me test another idea..
<lumag>
Normal boot:
<lumag>
r1=0xffffffff, r2=0x01e00000
<lumag>
r2[]=d0 0d fe ed 00 00 ba 36 00 00 00 38 00 00 b0 38
<lumag>
Heh. Even TEXT_OFFSET = 0x1f8000 works. 0x208000 doesn't ;D
<lumag>
sboyd, ok, it seems I finally found what was the issue with the TEXT_OFFSET and 8974.
<lumag>
The kernel itself was too bit, so it was overriding DTB/atags.
<lumag>
And there was no indication about that :D
<lumag>
Thanks a lot for your help!
<lumag>
Now I have the kernel that boots on both platforms and doesn't touch smem
<lumag>
(and you were right, that it should work)
<sboyd>
lumag: nice to see debug ll still works
<lumag>
sboyd, now I wonder, maybe we should just change TEXT_OFFSET for all 32-bit qcom platforms and drop all the crazyness.
<lumag>
WDYT?
<sboyd>
I think maybe you're losing 2mb?
<sboyd>
I thought that memory was recovered but maybe not
<lumag>
I don't think so, it is not listed as reserved in memblock/reserved nor in /proc/iomem. Let me compare `free` output
rmsilva has quit [Ping timeout: 480 seconds]
<lumag>
sboyd, no, `free` returns the same amount of memory and nearly the same 'avail' memory.
<lumag>
And thanks for the DEBUG_LL. I don't think I touched that for ages, likely since I last touched PXA or something close.
Danct12 has quit [Ping timeout: 480 seconds]
Danct12 has joined #linux-msm
<sboyd>
lumag: is it listed as 'memory' in the debugfs output?
<lumag>
sboyd, yes, memblock/memory covers full memory area.
<sboyd>
lumag: ok cool. I can't recall if there are performance problems with shifting the text offset. Probably not if RANDOMIZE_BASE exists
<sboyd>
lumag: I guess we want to limit it to only the affected SoCs so that we can avoid shifting the text offset
<sboyd>
I had a one word reply! haha
<sboyd>
I thought ard was working on randomize base for arm32? I haven't kept up
<lumag>
Yes, ard posted it, but then it got rejected IIRC
<sboyd>
ok, maybe the answer to why we don't do it on all qcom platforms is because it isn't preferred to have kernel text start at a non-standard offset