<clever>
so linux is then free to trash the memory u-boot.bin had been loaded to
<clever>
and CONFIG_ARMV7_SECURE_BASE has to be reserved
<clever>
or excluded from the /memory in DT
<clever>
marex: oh, and one question, i want my changes to the rpi build of uboot, to always be enabled, so a single u-boot.bin can work on either firmware, but improvements like psci mean DTB changes, which the OS then has to co-operate with, complicating matters
<clever>
due to the secondary core issues, the simplest option is to leave the load-addr and pie as-is, and put a stub before uboot, just like the official firmware
naoki has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
alan_o has joined #u-boot
GNUtoo has quit [Ping timeout: 258 seconds]
GNUtoo has joined #u-boot
thopiekar has quit [Ping timeout: 264 seconds]
thopiekar has joined #u-boot
elvishjerricco has quit [Ping timeout: 248 seconds]
samueldr has quit [Ping timeout: 268 seconds]
Tartarus has quit [Ping timeout: 250 seconds]
samueldr has joined #u-boot
umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
Tartarus has joined #u-boot
vagrantc has quit [Quit: leaving]
LeSpocky has quit [Ping timeout: 252 seconds]
elvishjerricco has joined #u-boot
LeSpocky has joined #u-boot
WoC has joined #u-boot
persmule has joined #u-boot
<marex>
clever: you can point the secure base to SRAM/OCRAM instead of DRAM
<marex>
clever: if the OS currently does not need PSCI, how does Linux bring up the secondary cores ?
<marex>
clever: is there some hackage in arch/arm/mach-bcm* to do that ? Some smp_ops or whatever that was called ?
vagrantc has joined #u-boot
vagrantc has quit [Quit: leaving]
stefanro has quit [Quit: Leaving.]
persmule has quit [Ping timeout: 258 seconds]
persmule has joined #u-boot
GNUtoo has quit [Ping timeout: 258 seconds]
GNUtoo has joined #u-boot
ikarso has joined #u-boot
jkorsnes has quit [Quit: leaving]
hanetzer has quit [Quit: WeeChat 3.6]
mckoan|away is now known as mckoan
guillaume_g has joined #u-boot
stefanro has joined #u-boot
monstr has joined #u-boot
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #u-boot
umbramalison has quit [Quit: %So long and thanks for all the fish%]
apritzel_ has joined #u-boot
sszy has joined #u-boot
kmaincent[m] has joined #u-boot
par[m] has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
mripard has quit [Quit: Bridge terminating on SIGTERM]
LinuxHackerman has quit [Quit: Bridge terminating on SIGTERM]
kallisti5[m] has quit [Quit: Bridge terminating on SIGTERM]
underpantsgnome[ has quit [Quit: Bridge terminating on SIGTERM]
JBB[m] has quit [Quit: Bridge terminating on SIGTERM]
hthiery has quit [Quit: Bridge terminating on SIGTERM]
ric342[m] has quit [Quit: Bridge terminating on SIGTERM]
samueldr has quit [Quit: Bridge terminating on SIGTERM]
elvishjerricco has quit [Quit: Bridge terminating on SIGTERM]
kmaincent[m] has quit [Quit: Bridge terminating on SIGTERM]
Tartarus has quit [Quit: Bridge terminating on SIGTERM]
Julia[m]1 has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
Domon has quit [Quit: Bridge terminating on SIGTERM]
kolbrich has quit [Quit: Bridge terminating on SIGTERM]
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
Tartarus has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
samueldr has joined #u-boot
mripard has joined #u-boot
jevinskie[m] has joined #u-boot
kolbrich has joined #u-boot
JBB[m] has joined #u-boot
LinuxHackerman has joined #u-boot
par[m] has joined #u-boot
elvishjerricco has joined #u-boot
mvaittin has joined #u-boot
kmaincent[m] has joined #u-boot
Domon has joined #u-boot
underpantsgnome[ has joined #u-boot
kallisti5[m] has joined #u-boot
ric342[m] has joined #u-boot
Julia[m]1 has joined #u-boot
hthiery has joined #u-boot
GNUtoo has joined #u-boot
zkrx has quit []
zkrx has joined #u-boot
<clever>
marex: spin tables, device-tree has a name for it
<clever>
all its doing here, is adding a simple-framebuffer if one is available, and optionally adding the spintable to the efi memory map
<clever>
board_fdt_blob_setup inherits a dtb from the armstub, but if i go stubless, that wont be there anymore
hanetzer has joined #u-boot
torez has joined #u-boot
<clever>
marex: i was just thinking of a crazy thing i could do, implement PSCI powerdown for all cores
<clever>
in theory, i can just turn the entire arm cluster off at any time, and when an event happens, turn it back on, and have some code at PC=0 restore control back to the os...
<clever>
ok, so CPU_SUSPEND will suspend a cpu, and if its going into a powerdown state, it must supply the entry-point and r0/x0 token, for non-powerdown states, i assume it just returns normally
<clever>
and from a powerdown state, the core is essentially reset, and returns in physical mode
<clever>
ah perfect, and SYSTEM_SUSPEND is a seperate thing
<clever>
minor problem with my idea, it looks like CPU_SUSPEND terminates upon any interrupt, but i cant capture generic timer interrupts from outside the arm
<clever>
infact, the generic timer would also be halted
<clever>
peripheral interrupts i can capture
alpernebbi has quit [Read error: Connection reset by peer]
<qschulz>
sjg1: it seems I'm unable to write a unit test for this dm patch
alpernebbi has joined #u-boot
lucascastro has joined #u-boot
<qschulz>
sjg1: https://paste.ack.tf/dc8598 is what I came up with, but impossible to actually run this test
<qschulz>
way too many changes to be able to even compile this with sandbox_spl_defconfig
<qschulz>
and with sandbox_defconfig, ./u-boot -T -c "ut dm fdt" does not run it either
<qschulz>
so i'm not against some guidance on how to write a unit test for that patch
<qschulz>
what we want to test is that in pre-reloc, a driver with DM_FLAG_PROBE_AFTER_BIND flag but not DM_FLAG_PRE_RELOC gets probed if it is bound to a device tree node where u-boot,dm-pre-reloc is set
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
<marex>
clever: that WFI in e.g. the stm32mp15xx PSCI suspend/resume implementation is there only to keep the core in low power state
<marex>
clever: I think the MX7 just flips some GPC bits and returns
<marex>
clever: you would probably have to set up the interrupt controller to wake the core up again if you want to do suspend
<clever>
marex: the suspend i was thinking of, would just cut the power to the entire arm cluster, at which point, arm interrupts cant wake it
<clever>
but the peripheral interrupts can also interrupt the VPU, which can turn the arm back on
<clever>
then all 4 arm cores start at PC=0 in EL3 again
GNUtoo has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
minimal has joined #u-boot
<clever>
marex: i can likely also implement SYSTEM_SUSPEND, ive found the specs on how to do suspend to ram with lpddr2, i just have to convince the dram controller to start that, and then power down as much as i can
monstr has quit [Remote host closed the connection]
macromorgan has quit [Ping timeout: 260 seconds]
macromorgan has joined #u-boot
<marex>
clever: is this some standard DRAM controller, like DWC/synopsys one , or custom broadcom one ?
lucascastro has quit [Quit: Leaving]
<clever>
unknown
<clever>
i have drivers and a header, but no clue who makes it
<clever>
gpio 33/33 can be either, but are not on the main header
<clever>
36/37 can be just one uart, 40/41 can be just the other uart, neither is on the gpio header
<clever>
but 40/41 is going thru a low-pass filter, and into the headphone jack for audio
<clever>
9600 baud might survive the low-pass filter
<clever>
or just solder to the other side of it
<marex>
clever: or just desolder the BT chip :)
<apalos>
marex: semihosting?
persmule has quit [Remote host closed the connection]
<clever>
oh, and most of my testing is done on the pi2, it lacks a BT chip
mmu_man has quit [Ping timeout: 264 seconds]
<apalos>
marex: I've only used it in QEMU myself
persmule has joined #u-boot
<cambrian_invader>
marex: you may be thinking of me
<cambrian_invader>
but IMO if you have a real UART, accept no substitutes
<clever>
yeah, from what ive seen, semihosting has some serious bottlenecks
<clever>
it looks like its only a single 8bit buffer, and its entirely polling based on the jtag side
<clever>
so the target core just grinds to a halt every time you print a char, until the jtag adapter eats it
<cambrian_invader>
the solution is to print lines at a time
<cambrian_invader>
which is considerably faster
<clever>
but can semihosting even do that?
<cambrian_invader>
yes
<clever>
i must have missed that while skimming the arm docs
<cambrian_invader>
see drivers/serial/serial_semihosting.c
<cambrian_invader>
you can use read/write with fd 0/1 like usual
<cambrian_invader>
and there's also a less-efficient print0
<clever>
smh_trap(SYSWRITE, &write);
<clever>
ah, thats probably what i missed
<clever>
ahh, this isnt the api i was thinking of
<cambrian_invader>
input is still glacially slow though
<clever>
its just using the hlt or brpt opcode to wait for the debugger, which then eats the whole line at once, using normal write() api's
<cambrian_invader>
because U-Boot reads a character at a time
<cambrian_invader>
and then echos it
<clever>
i was thinking of that other debug register that lets you move a word at a time
<cambrian_invader>
arm_dcc.c?
<clever>
yeah, thats the one
zkrx has quit []
zkrx has joined #u-boot
<clever>
it looks like i got dcc and semihosting crossed, semihosting uses hlt/bkpt/svc to pass control off to something else, and can then do multi-char writes, much like hypercalls to a hypervisor
<cambrian_invader>
The main advantage is in bulk data transfer
<clever>
yep
<cambrian_invader>
booting from semihosting is way faster than using xymodem
<clever>
it can then use a bulk memory read primitive in jtag, to scrape the whole line at once
zkrx has quit []
<clever>
cambrian_invader: and speaking of xmodem, yeah, i implemented xmodem a while back, and it took 2 minutes to boot!
<clever>
but i cant jtag that core, so jtag/semihosting isnt an option either
<cambrian_invader>
:l
<clever>
my next options then, are to overclock the uart
mmu_man has joined #u-boot
<clever>
it was 2 minutes at 115200
<clever>
but 1mhz is viable, at least on the pi end
<clever>
but ethernet would be a far simpler option
zkrx has joined #u-boot
<cambrian_invader>
faster, too :)
<clever>
yep
<clever>
but that means i need to write/port dwc usb drivers
<cambrian_invader>
doesn't U-Boot have those already?
<clever>
u-boot is running on the arm side
<cambrian_invader>
oh, this is from the gpu?
<clever>
i need VPU side drivers, to be able to even load u-boot.bin from the network
<clever>
that rom can then load bootcode.bin from 8 different sources, each enabled with a different OTP(fuse)
<clever>
bootcode.bin has a hard max-size of 128kb, and is running from a cache-as-ram setup
<clever>
and is doing basically the same job as SPL in u-boot
<clever>
bring dram online, then load a bigger binary
<clever>
the pi3 maskrom has usb-host support, and can load bootcode.bin over tftp with the lan9415, or from a usb-MSD device
<clever>
the pi0-pi3 models are otherwise identical at this stage, and typically load bootcode.bin from fat32 off an SD card
<clever>
the official bootcode.bin brings dram online, and then loads start.elf from the same location bootcode.bin came from
<clever>
and start.elf then loads linux, and turns on the arm core
<clever>
cambrian_invader: but https://github.com/librerpi/lk-overlay can be compiled into both bootcode.bin and start.elf forms, and includes drivers for the dram, 2d core, 3d core, and can load .elf files and/or linux
<cambrian_invader>
neat; gl with this
<clever>
currently, its using a custom arm bootloader
<clever>
and i'm trying to get u-boot working instead
<cambrian_invader>
I've always found the binary blobs on the pi flies in the ointment
<clever>
with lk-overlay, you can de-blob the entire system
<clever>
source for every single part that can be modified (the maskrom is set in stone)
<clever>
the ~3 main features missing currently, are hdmi init, smp support, and usb-boot
<clever>
plus the blob-riddled features like hw encode/decode and camera accel
ldevulder has quit [Quit: Leaving]
<marex>
clever: one of the rpi dudes I met recently said something like there is no chance of this RE effort on pi4 because the fw is far more complex
<marex>
sigh
<clever>
marex: i havent been able to figure out the ddr4 init sequence, but there is some good news
<clever>
originally the bootcode.bin/SPL stage, was overly complex
<clever>
it did both ddr4 init, and loading of start4.elf from SD/USB/TFTP/NVME!!
<clever>
so if you want to add something as simple as booting from lora, you have to re-implement the ddr4 init first
<clever>
marex: but with the network install changes, the code went over the 128kb size limit, so RPF split it into another stage
<clever>
bootcode.bin is far more SPL like now, it can only do dram init, and load bootmain.elf from SPI flash, and nothing else
<clever>
bootmain.elf then deals with loading start4.elf from sd/usb/tftp/nvme/https
<clever>
but, bootmain.elf could be replaced
<clever>
you would still rely on the bootcode.bin blob, but its a far dumber binary now
<clever>
marex: however, i havent been focusing as much on the pi4 arm bringup, because i was battling dram init, before the above happend
<clever>
at some point, i need to re-visit getting the arm online
<clever>
and then it should be easy to just run a generic arm .bin file on boot
<marex>
clever: it makes me wonder, isn't there some broadcom mips bootloader which might already be open and contain driver for similar (or the same) DRAM controller due to IP reuse ?
<clever>
possibly, but would that be ddr2 or ddr4?
<clever>
the ddr4 controller is wildly different, and includes its own firmware blobs
<marex>
clever: probably ddr2, i.e. closer to RPi
<marex>
1 or 2 that iis
<marex>
*is
<clever>
the entire pi0-pi3 lineup is using the identical lpddr2 controller
<clever>
other then the power regulator, arm core(s), and arm irq controller, the entire pi0-pi3 soc lineup is identical
<clever>
the bcm2835 has a SMPS directly in the soc itself, for generating the core voltage
<clever>
i think the bcm2836/2837 is generating core with an external PMIC, and configuring it over i2c
<clever>
which reminds me, i have not touched the core-voltage at all, on any model
<clever>
its been running from the default voltage