<montjoie>
hello I have a nanopineoplus2 with 512M RAM, I got some problem (Failed to allocate) with big kernel+ramdisk I have added a lmb_dump_all and memory is memory[0][0x40000000-0x49ffffff] so only a partial part of RAM. does it this normal ?
tre has quit [Ping timeout: 252 seconds]
<marex>
montjoie: so DRAM is recognized as 256 MiB ?
<marex>
montjoie: does it boot if you do this before booti ?
<marex>
=
<marex>
=> setenv initrd_high 0xffffffffffffffff
<marex>
and probably also
<marex>
=> setenv fdt_high 0xffffffffffffffff
<montjoie>
LAVA CI already issue setenv initrd_high 0xffffffff
<marex>
this will skip the ramdisk and fdt relocation step, but then you have to assure they are properly aligned
<montjoie>
same for setenv fdt_high 0xffffffff
<marex>
not 0xffffffff, it has to be -1 representation in the bit-ness of the platform
<marex>
so on arm64, 16 Fs
<marex>
on arm32, 8 Fs
<montjoie>
I will try
gsz has quit [Ping timeout: 240 seconds]
gsz has joined #u-boot
littlebo1eep has quit [Ping timeout: 240 seconds]
<montjoie>
marex: setting xxx_high did the trick
<montjoie>
thanks for your help
<montjoie>
unfortunatly, kernel oom just after booting:)
littlebobeep has joined #u-boot
<marex>
montjoie: does it also work if you drop the xxx_high and instead do:
<marex>
setenv bootm_size 0x10000000
<marex>
?
<marex>
maybe load the kernel/dt/ramdisk initialy above 0x50000000
jwillikers has joined #u-boot
mckoan is now known as mckoan|away
jybz has quit [Excess Flood]
jybz has joined #u-boot
jwillikers has quit [Remote host closed the connection]
<hanetzer>
question. is it appropriate to include soc-specific tools for flashing in the u-boot tree? soc in question has the ability to load spl to sram and u-boot to dram over serial, has a specific protocol for it.
<hanetzer>
you can then (usually) tftp the actual flash image and use the u-boot you initially sent over serial to write it with the usual tools.
mmu_man has quit [Ping timeout: 276 seconds]
<marex>
imx-usb is not included, so probably no
<marex>
separate repo ?
<hanetzer>
marex: k, just checking. I suppose that makes sense, rkflashtool is also not in there
<montjoie>
marex: will try
mmu_man has joined #u-boot
tre has quit [Remote host closed the connection]
<hanetzer>
another question. the concept of 'back to bootrom' on this family of soc is to read a pc/sp value from a general purpose mmiospace register and mov them into the current pc/sp registers, if another general purpose mmio register contains a flag. think you can do that in c cleanly?
<hanetzer>
or am I just gonna have to __asm__ volatile() it?
<Forty-Bot>
probably that
<Forty-Bot>
generally anything involving specific registers has to be done with asm
<hanetzer>
figured.
<hanetzer>
whelp, I wonder how much of this code is going to be 'we do this because the vendor code does it' for lack of documentation :P
sukbeom has quit [Quit: WeeChat 3.3]
sukbeom has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
torez has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
<hanetzer>
is there any particular overhead of making uboot/spl/tpl relocatable? as in, code size?
<marex>
hanetzer: CONFIG_POSITION_INDEPENDENT and TEXT_BASE=0 , there is overhead of PIE
littlebobeep has joined #u-boot
zibolo has quit [Ping timeout: 248 seconds]
monstr has quit [Remote host closed the connection]
<hanetzer>
noted.
frieder has quit [Remote host closed the connection]
<hanetzer>
not much, nice.
littlebobeep has quit [Ping timeout: 240 seconds]
<hanetzer>
or is the overhead perf related as opposed to size?
<hanetzer>
tbqh I *think* the soc has some kind of xip going on. during the bootrom->flash transition it just loads 0x1400_0000 (the sfc memory address space) into a register and moves that into the program counter.
guillaume_g has quit [Quit: Konversation terminated!]
<dormito>
for an aarch64 system, does TF-A provide the linux kernel with cpu frequency scaling? If so, is there a place I'd look for how to load TFA during/before u-boot? I know some chips embed it in a FIT image with u-boot that the SPL/TPL loads.
<hanetzer>
dormito: oh hey, it u.
<hanetzer>
iirc the rk3399 boards may do that?
<dormito>
hanetzer: I was thinking of exactly the rk3399
<hanetzer>
heh. the rk3288 tree is my 'pattern' for the soc I'm working on :)
<dormito>
however I'n now working with an ls1046a. And while I got a u-boot build to work & run. linux seems to lack any clocking info :/
<hanetzer>
dormito: I'm not at all familiar with wtf atf and friends do tbh, but I do see some chips encode the cpu operating table in the dts (freq & voltage), maybe look into that?
<xypron>
fALSO: are your build problems fixed with v2022.07-rc2?
<dormito>
I'm using upstream linux (with an upstream dts). A quick glance suggests upsteram doesn't include any cpu freq info in the dts.
<fALSO>
xypron, nice
<fALSO>
xypron, i recreated my cross compiler to be just arm.
<fALSO>
xypron, i recreated my cross compiler to be just arm-
<fALSO>
it ran OK after that
<fALSO>
the only thing missing is the support for "ccache" but that wasnt probably supported, and uboot is small enought to not need it :)
<fALSO>
I used to do CROSS_COMPILE="ccache armv7a-hardfloat-linux-gnueabi-"
<fALSO>
that sed doesnt like it that way ;-)
<fALSO>
xypron, its OK with me, awesome that you managed to merge the patches so quickly =)
<hanetzer>
dormito: the dtsi, you mean? perhaps one of the downstream (as in, in #include order) board-specific files sets it up and yours doesn't?
<hanetzer>
because a lot of times the board dts will override the soc dts
<hanetzer>
*soc dtsi
___nick___ has joined #u-boot
sobkas has joined #u-boot
<dormito>
hanetzer: I mean the full dts. I decompiled the dtb and looked at it
<hanetzer>
ah. hrm. well. not familiar with that platform, or, as I said, atf stuff