persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
zkrx has quit [Read error: Connection reset by peer]
zkrx has joined #u-boot
zkrx has quit []
zkrx has joined #u-boot
zkrx has quit [Client Quit]
zkrx has joined #u-boot
zkrx has quit []
zkrx has joined #u-boot
rvalue has quit [Ping timeout: 265 seconds]
rvalue has joined #u-boot
rvalue has quit [Ping timeout: 265 seconds]
rvalue has joined #u-boot
zkrx has quit []
zkrx has joined #u-boot
camus has quit [Quit: camus]
<hramrach>
there is a patchwork \o/
sukbeom has joined #u-boot
camus has joined #u-boot
sam_sepi0l has quit [Ping timeout: 260 seconds]
hanetzer has quit [Quit: WeeChat 3.6]
hanetzer has joined #u-boot
naoki has quit [Quit: naoki]
Forty-Bot has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
clever has joined #u-boot
vitali64 has joined #u-boot
<clever>
me and vitali64 are trying to bring uboot up on a "new" board, and its not printing a single byte to the PL011 uart, i notice that the load addr in the u-boot elf file is 0x8000, but its being loaded to 0 before exeucution
<clever>
is the u-boot.bin fully PIC?
<vitali64>
The "new" board is actually a RaspberryPi2 running a custom firmware.
<vitali64>
When powering it on, I can see this stuff being printed on the screen:
persmule has quit [Remote host closed the connection]
<marex>
hramrach: yeah, that was the goal on rcar3
<clever>
hramrach: this implies it can run from any 4k aligned addr, but its not entirely clear how it learns what top-of-ram is
<marex>
load u-boot.bin at random address and jump to it, useful during development, since the ARM Trusted Firmware takes effing forever to start there
<clever>
i assume its just using the mmu to map itself to the right addr?
<marex>
clever: what are you trying to do ?
<clever>
marex: run uboot on an rpi2, with the open source firmware
<marex>
clever: that's the firmware which runs on the GPU or whatever vector processor they have in there ?
<marex>
or does this already run on the ARM core ?
<clever>
it runs on the VPU
<clever>
in the current configuration, its copying u-boot.bin to arm physical 0, and turning the arm core on
<clever>
so byte-0 of u-boot.bin is the very first thing the arm runs out of reset
<clever>
and all 4 arm cores run that in parallel
<hramrach>
that will likely not work well
<marex>
what happens if you compile assembler code which does basically '1: mov r0, #address_of_txfifo \n mov r1, #0x30 \n str r1, [r0] \n b 1b' ?
<clever>
oh!, KKKK4444____333322KKK444___333222, thats why each chat is repeated 4 times
<hramrach>
can you enable only 1?
<marex>
oh, heh
<clever>
so if we then dedup that, we get K4_32K4, still a bit scrambled, possibly because it wasnt a PIE build
<clever>
so its off by 0x8000
<clever>
hramrach: not really, some asm would have to be dropped at 0 that only forwards 1 core on
<clever>
and i was working under the assumption that uboot already handled that
<vitali64>
Thanks!
<hramrach>
you can handle it in u-boot if you put the assembler there
<vitali64>
I did get 'K4_32'.
<clever>
yeah, i could also modify the platform code
<vitali64>
Show up on the screen.
<vitali64>
Sometimes.
<clever>
vitali64: and the reason you sometimes got KKKK, is because uboot is running on all 4 arm cores at once
<clever>
hramrach: i do have this example that i'm familiar with, if built with SMP support, it will check the core#, and jump off to arm_secondary_setup, which blocks until core-0 has brought the mmu online, then steals its paging tables, and jumps to arm_secondary_entry() (a c function)
<clever>
at which point, all cores are running C from virtual addresses
redbrain has joined #u-boot
<marex>
clever: these systems generally do have registers where you write the jump address and then reset the core, and it jumps to that address
<clever>
marex: i have not seen any sign of one on the rpi soc
<clever>
at least for the arm cores
<marex>
but like hramrach said, you can also just have a trampoline code, have the core spin in a loop and upon some condition, jump to an address written in DRAM or so
<clever>
the VPU does have such a reg however
<clever>
yep, thats how the official firmware does it
<clever>
i suspect it was created back when arm trusted mode was still new
<clever>
and rather then trust that new thing, they just distrust the whole damn arm :P
<clever>
it can be configure so the arm only has say 32mb of ram, and zero peripherals
<clever>
then its only capable of compute tasks, and cant talk to any hardware
<hramrach>
it'ss more like thinking that arm is just a peripherial core that you can reconfigure and restart if it happens to crash
<clever>
perfect little sandbox to throw untrusted code into
<clever>
yep, that too
<clever>
because the VPU was originally the master, and ran the entire os and all apps
<clever>
on every model, the VPU is a dual-core cpu, with 32 registers of 32bits each, and like arm, some of those registers have a special purpose like status/pc/lr/stack
<clever>
unlike arm, any of those 32bit regs can be interpreted as either a 32bit float, or a 32bit int
<marex>
clever: btw WFI on stm32mp15xx does force the core into low-power state, disables core clock and all that
<marex>
it does save a lot of power
<clever>
so you dont have special float registers, only float opcodes
<marex>
maybe they do the same
<clever>
marex: i have read the arm docs, and there is a signal coming out of the arm cluster, to say when every core is in wfe/wfi state
<clever>
which you can then use to shutdown the clocks
<clever>
or reduce voltages
<clever>
i didnt see a per-core one, but maybe i just missed it
<clever>
and yeah, its then up to the silicon designer/implementor, to wire that into something
alpernebbi has quit [Ping timeout: 246 seconds]
alpernebbi has joined #u-boot
<marex>
clever: you can put one core into WFI and see whether the consumption goes down
<marex>
maybe they have something in the clock block which allows you to turn off core clock manually from core0
<marex>
*measure the consumption using e.g. USB power meter, that should be precise enough
<clever>
marex: from how the hardware is setup, PLLB takes the 19.2mhz crystal multiplies it up to some clock (identical register layout for every PLL), and then the PLLB_ARM tap divides it back down
<clever>
each PLL has up to 4 taps, and there are holes in the register layout when it has fewer
<clever>
very much a copy&paste hw block, and they just assign names based on where it was routed
<clever>
from what i can see, there is only a single arm clock, but there could be unknowns like you describe, between that divider and each core
<clever>
and this has the full clock tree and all of the clock muxes
<clever>
each peripheral, such as the PL011 uart, has an 8 clock mux and divider, so you can pick one of those 8 sources, and divide it down further
<clever>
in the case of the PL011, 0=gnd (no clock), 1=crystal, 2=TD0, 3=TD1 (test/debug clocks), 4=PLLA_PER, 5=PLLC_PER, 6=PLLD_PER, and 7=PLLH_PER
<clever>
the mux isnt listed, but my code is configuring the arm to source 4
vitali64 has quit [Quit: Lost terminal]
lucascastro has joined #u-boot
naoki has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
prabhakarlad has joined #u-boot
lucascastro has quit [Quit: Leaving]
<clever>
marex: ah, i was going to complain about how each platform seems to be re-implementing psci, but upon closer inspection, they are all sharing code in arch/arm/cpu/armv7/psci.S
<clever>
so my only real complaint, is that psci_features isnt dynamically checking the _psci_table, but thats fairly minor
<clever>
so that just means that i need to ensure psci.S is linked into my u-boot, and lands at a reserved addr in ram
<clever>
ah, and that then involves CONFIG_ARMV7_SECURE_BASE
<clever>
and similarly, i can use that secure/reserved region to protect the spintables and parking code, though the hw lacks actual secure arm memory
WoC has quit [Remote host closed the connection]
urja has quit [Quit: WeeChat 3.6]
urja has joined #u-boot
lucascastro has joined #u-boot
lucascastro has quit [Remote host closed the connection]