Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2022.07 is OUT / Merge Window is OPEN, -next is CLOSED / Release v2022.10 is scheduled for 3 October 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
thopiekar has quit [Ping timeout: 268 seconds]
minimalist has joined #u-boot
minimalist has quit [Read error: Connection reset by peer]
minimalist has joined #u-boot
minimal has quit [Read error: Connection reset by peer]
thopiekar has joined #u-boot
minimalist has quit [Quit: Leaving]
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
thopiekar has quit [Ping timeout: 268 seconds]
thopiekar has joined #u-boot
umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
srk- has joined #u-boot
srk has quit [Ping timeout: 252 seconds]
srk- is now known as srk
LeSpocky has quit [Ping timeout: 268 seconds]
LeSpocky has joined #u-boot
vagrantc has quit [Quit: leaving]
mmu_man has quit [Ping timeout: 264 seconds]
mrnuke_ has quit [Ping timeout: 265 seconds]
zkrx has quit []
zkrx has joined #u-boot
m5zs7k has quit [Ping timeout: 250 seconds]
m5zs7k has joined #u-boot
mckoan|away is now known as mckoan
ldevulder has joined #u-boot
sszy has joined #u-boot
zkrx has quit []
zkrx has joined #u-boot
guillaume_g has joined #u-boot
zeewark1 has quit [Quit: Leaving]
ikarso has joined #u-boot
monstr has joined #u-boot
prabhakarlad has joined #u-boot
mmu_man has joined #u-boot
matthias_bgg has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
aggi has quit [Quit: connection closed.]
aggi has joined #u-boot
camus has quit [Ping timeout: 265 seconds]
camus has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
mmu_man has joined #u-boot
redbrain has joined #u-boot
alpha_one_x86 has joined #u-boot
<alpha_one_x86> I see spi_nand read freeaddr kernel kernel_sz , what should be kernel_sz ? dtb or initrd?
davlefou has quit [Ping timeout: 264 seconds]
davlefou has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
minimal has joined #u-boot
marc1 has quit [Read error: Connection reset by peer]
mmu_man has quit [Ping timeout: 264 seconds]
mrnuke has joined #u-boot
torez has joined #u-boot
monstr has quit [Remote host closed the connection]
persmule has quit [Ping timeout: 258 seconds]
persmule has joined #u-boot
aggi has quit [Quit: connection closed.]
marc1 has joined #u-boot
mckoan is now known as mckoan|away
vagrantc has joined #u-boot
aggi has joined #u-boot
hir12111 has joined #u-boot
<hir12111> Hi all, is there a way to undef a define in a board header file? (in a config-friendly way, without having to patch)
GNUtoo has quit [Remote host closed the connection]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
GNUtoo has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
guillaume_g has quit [Quit: Konversation terminated!]
<hramrach> alpha_one_x86: probably the length of the kernel binary
vitali64 has joined #u-boot
<cambrian_invader> hir12111: generally, no
<cambrian_invader> you can of course send a patch to make it depend on a CONFIG_...
umbramalison has quit [Remote host closed the connection]
mmu_man has joined #u-boot
<clever> hramrach: https://paste.debian.net/1255192/ me&vit have got uboot far enough that rpi.c can query how much ram the system has, but then u-boot starts malfunctioning in pretty weird ways after that
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
ikarso has quit [Quit: Connection closed for inactivity]
umbramalison has joined #u-boot
hir12111 has quit [Quit: WeeChat 3.6]
matthias_bgg has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 248 seconds]
vitali64 has quit [Quit: Lost terminal]
mmu_man has joined #u-boot
<clever> hramrach: https://paste.debian.net/1255217/ i'm trying to make sense of why the init_sequence_f array went nuts near the end, but i dont currently have the u-boot.map file to fully map things out, do you have any guesses from this log?
torez has quit [Quit: torez]
elafon has quit [Ping timeout: 264 seconds]
elafon has joined #u-boot
alpernebbi has quit [Ping timeout: 248 seconds]
alpernebbi has joined #u-boot
manu has quit [Read error: Connection reset by peer]
manu has joined #u-boot
<hramrach> sorry, no idea about that.
<hramrach> I am currently familiar with uclass iterators :>
<clever> hramrach: what about how to make the debug() prints actually print?
<clever> cranking up the log-level didnt help
<hramrach> clever: you #define DEBUG at the very top of the C file, before the includes
<clever> and is that in combination with the log-level, or overriding it?
<clever> i saw some signs of it overriding log-level but it didnt seem to work
<hramrach> new style logging should emulate the effects of DEBUG where DEBUG is defined and new style logging is used, at least that's what the docs say
<cambrian_invader> uh, IIRC there is some bug related to that
<cambrian_invader> I don't remember the exact details
<clever> cambrian_invader: can you make any sense of the log i pasted above?
<cambrian_invader> looks like you ran out of memory
<clever> cambrian_invader: but it has 64mb of ram, and it shouldnt have ran out so fast
<clever> i think its stray pointers, and just printing from random addresses
<cambrian_invader> did you set up your malloc arena to reflect that?
<cambrian_invader> if you think it is printing from random addresses, try adding some padding somewhere
<clever> cambrian_invader: this chunk of code has set gd->ram_size to indicate that the board has 64mb of ram
<cambrian_invader> no, the MALLOC_F_LEN stuff
<clever> ah, the old += allocator trick
<clever> it should be set to whatever the default is for the pi2
<clever> configs/rpi_2_defconfig:CONFIG_SYS_MALLOC_F_LEN=0x400
<clever> which is only 1kb!
<clever> cambrian_invader: what is the purpose of u-boot relocating itself? i thought it was being built to just run from a fixed addr?
<cambrian_invader> SPL is built to run at a fixed address
<cambrian_invader> but U-Boot proper always relocates
<cambrian_invader> the reason is twofold
<cambrian_invader> first, on XIP systems, we want to copy U-Boot into RAM
<clever> ahhh, and u-boot always has an SPL tacked onto it?
<cambrian_invader> second, on non-XIP systems, often the load address for U-Boot and whatever follows U-Boot is the same
<cambrian_invader> so we need to relocated U-Boot before it clobbers itself
<clever> makes sense
<clever> the default build of u-boot for the rpi, assumes its loaded to 0x8000, because that is where linux loads to by default
<clever> and yeah, if you want linux loaded there, you gotta move!
<cambrian_invader> note that SPL also "relocates" but that's just about where the global data and malloc live
<cambrian_invader> and I think the stack too
<clever> and jump_to_copy is what deals with that?
<cambrian_invader> probably
<cambrian_invader> I'm not as familiar with the arm guts
<clever> #if !defined(CONFIG_ARM) && !defined
<clever> i think its disabled on arm
<clever> arch/arm/lib/crt0.S: bl board_init_f
<clever> ah, maybe via here
<clever> that has a massive 50 line comment explaining things!
<clever> cambrian_invader: a lot of those problems you described, are also ones i'm having on the VPU side, and one crazy idea i have, is to just port u-boot to the VPU and let uboot do the raminit!
<cambrian_invader> yes, that's probably one of the easier ways to do it
<cambrian_invader> 128k is roomy enough for SPL
<clever> you have a bootcode.bin stage, 128kb max, that runs from cache-as-ram and a fixed address, very much like the SPL
GNUtoo has quit [Remote host closed the connection]
<clever> and then you have the same problem, the second stage may want to load to the same addr
<cambrian_invader> what's the vpu arch?
<clever> some rumors say its a variant of a synopsys ARC dsp
<hramrach> something very odd
<clever> other say that synopsys was just hired to make the toolchain, and it was an entirely broadcom custom isa
<cambrian_invader> huh
<clever> the people that know, arent speaking
<clever> cambrian_invader: the submodules here, give you a fully working binutils+gcc that can compile to the VPU
<clever> for the bootcode.bin stage, the rom just loads it to 0x8000_0000, and then jumps to 0x8000_0200
<clever> the 0x200 byte hole, is the perfect size for the irq/exception vector table
<hramrach> you would be the first to make u-boot port that loads Linux to a non-native CPU, though
<clever> hramrach: yeah, it would be a really wonky design, where u-boot keeps running even after starting linux, lol
<clever> and u-boot then has to load a second (vpu) binary and execute that
<cambrian_invader> I think that happens already for EFI
<clever> or wait for a binary to be pushed over by linux
<clever> the vpu binutils, was written to make things more friendly to arm developers
<clever> the opcodes and general syntax are designed to look like arm asm
<clever> mov sp, _fstack
<clever> bl manual_uart_cfg
<clever> by cherry-picking examples, you would never know it isnt arm
<clever> mov r0, 0x7e20001c
<clever> but then it goes and does things arm cant, like a full 32bit immediate :P
GNUtoo has joined #u-boot
<clever> cambrian_invader: also, due to how the rpi boots, the SPL would have to live up to its name, and actually load the secondary program
<clever> while on rpi, its already been appended and is sitting in ram
<clever> cambrian_invader: does u-boot need threads and context switching?
<cambrian_invader> no
<cambrian_invader> the whole thing is single-threaded
<cambrian_invader> aside from bringing up additional cores
<clever> then you can skip that part of my example code
<clever> *REG32(IC1_WAKEUP) = (uint32_t)(&core2_start);
<clever> much like many arm chips, you just write an address to a magic register, and the 2nd core begins executing from there
<clever> cambrian_invader: i guess u-boot has no need for interrupts either then?
<cambrian_invader> usually we install some basic handlers which print something
<cambrian_invader> so you can e.g. debug your SErrors
<clever> the original rpi-open-firmware codebase did the same
<clever> any interrupt or exception was a fatal error, dump all registers and hang
<clever> which led to a fun bug, it would do just that, 1 hour after booting
<clever> a timer compare register defaulted to 0, and it ticked at 1mhz
<clever> 32bit counter, 1mhz, ~71 minutes to wrap around and match 0
<clever> cambrian_invader: on the VPU side, the interrupt vector table is just an uint32_t[128], 32 slots of cpu exceptions, 32 slots of software interupts, and then 64 slots of hw interrupts
<clever> upon receiving an exception/interrupt, it pushes pc+sr(status reg) to the stack, disables interrupts, and jumps to the addr in the matching slot
<clever> there is also a secure vs normal mode, each has its own stack, bit0 of the addr in the exception table can force a switch to secure mode
<clever> and like arm secure mode, the ram can be configured so a region is protected and secure-only
<clever> and certain peripherals are secure only
* marex reads wall of text
minimal has quit [Quit: Leaving]
<clever> marex: all make sense?
<marex> sure
<marex> clever: is there a toolchain for the VPU coprocessor btw ?
<marex> or is that just some hand-roll assembler translator so far ?
<clever> full binutils + gcc toolchain
<clever> gcc has ~2 compile bugs ive found, and lacks support for the vector opcodes, but is otherwise fully usable
<clever> 1 bug just leads to the assembler failing, so its a bit anoying but can be worked around
<clever> the 2nd bug is a bit more nasty, a switch-case sometimes malfunctions, if it uses the lr register
<clever> ive only observed it once
<marex> nice
<clever> the biggest issue with debugging though, is the lack of jtag
<clever> so all you can do is printf everything
<marex> clever: lack of JTAG for what, the VC4 or ARM cores ?
<clever> marex: this chunk of hand written asm, will bring the PL011 uart online at 115200 baud, without using any stack, and before bss has even been setup
<clever> VC4/VPU jtag is undocumented
<clever> rpi engineers have stated that the tools they have are very nice
<clever> but they arent sharing :P
<clever> arm jtag needs to be enabled by the VPU during boot, but works perfectly fine
<marex> clever: did you try running urjtag on it and determine the scan chain length at least ?
<marex> maybe there is one device with very short IR
<marex> and maybe that IR can be matched to existing IP
<clever> some notes on the IR lengths
<clever> 22bit IR, but many IR codes repeat, and the DR lengths seem all over the place
<marex> Weird length, weird content. ... might be boundary scan register
<clever> its likely you need a secret handshake to unlock the debug stuff
<marex> ie. 3x pin count of the BGA , one for IN value of the pin, one for OUT setting of the pin, one for nOE output enable
<clever> yeah
<clever> on the original pi1, the lan9512 and vpu jtag are on a pair of 0.1" headers
<clever> marex: https://i.imgur.com/QqiG40k.png on the pi1a+, they moved the vpu jtag to an unpopulated SMD header, but where nice enough to label it
<clever> on later models (including the pi4), they kept the same header/pinout, but dropped the labeling
<clever> marex: for arm jtag, you must expose it thru the pinmux array (several options), and set the ARM_C0_JTAGGPIO control bit in a special register, before turning on the arm
<clever> there is also signs that there is a hardware accelerated jtag bit-banging peripheral, that lets the VPU bit-bang the arm JTAG internally, without exposing it to outside pins
<clever> ARM_C0_JTAGGPIO == Debug on GPIO on, but there is also ARM_C0_JTAGBASH == Debug on GPIO off
<clever> and ARM_C0_JTAGOFF
<clever> marex: the fact that it has a flag to enable jtag, but its not gpio jtag
<marex> clever: makes me wonder whether there isn't documentation for any of the other self-standing videocore 2D IPs which were e.g. in the ipod, maybe around rockbox project
<clever> yeah, i have to wonder how much it has in common with those older platforms
<clever> but ive got no idea where i would find firmware blobs for old ipod's and roku2's
<marex> clever: you likely want the chip datasheet, or maybe even BSDL file