01:21 <hanetzer> wrt BOOT_TARGET_FOO; that's about booting an OS, not u-boot from the spl?

12:01 <montjoie> hello, I try to compile uboot on ubuntu/debian and always got ModuleNotFoundError: No module named 'pkg_resources' even if I install all python/python3 - pkg_ressources/setuptools/setuptools-scm

12:01 <montjoie> I verified, pkg_resources is present in /usr/lib/python3

12:51 <MrSaturn> marex: you are a genius

14:04 <marex> MrSaturn: no, that's a recurring topic, if you have small FIFO, no flow control, and you pipe too many data into it at once, that;s what you end up with, overflow

15:25 <hanetzer> so. CONFIG_SYS_INIT_SP_ADDR is the address in memory (as in, external dram or the like) used in u-boot proper, and CONFIG_SPL_STACK is the spl analogue and is *probably* inside the device's internal sram?

15:36 <Tartarus> OK, so, sigh, this is a confusing area

15:37 <Tartarus> CONFIG_SYS_INIT_SP_ADDR is where we have a temporary stack pointer, and is typically going to be in some sort of special memory that's not SDRAM

15:37 <Tartarus> (exceptions exist for the cases where none of U-Boot runs before SDRAM is enabled)

15:39 <Tartarus> CONFIG_SPL_STACK (and CONFIG_TPL_STACK) are SPL (and TPL) specific variants of this because in some cases we don't put the initial SP for full U-Boot in special memory but instead just a known OK spot in SDRAM because SPL has initialized SDRAM and we might need a non-trivial amount of stack early on for $reasons

15:40 <Tartarus> Then there's CONFIG_SPL_STACK_R / CONFIG_SPL_STACK_R_ADDR for having SPL move stack pointer to SDRAM, again for $reasons and that's often related to filesystem access I believe.

15:41 <Tartarus> Part of the confusion here is that CONFIG_SYS_INIT_SP_ADDR can be set to say SRAM and that location used for SPL and full U-Boot, not as re-using the stack pointer but just the memory area

15:43 <hanetzer> uh huh. see, I've got a device I should really throw away and forget everything about, but I can't leave it alone. for lack of jtag/similar I've actually modeld quite a lot of the basics of it in qemu, and can execute its bootrom that way and see what's going on

15:45 <hanetzer> by the time it starts trying to execute code on the external flash, sp is pointing to 0x4010500, which is 0x500 bytes into the sram.

16:42 <marex> Tartarus: time to start documenting this, properly ?

16:42 <marex> hanetzer: ^

16:43 <hanetzer> it'd be nice. there's a lot of good documentation for other similar config values :)

16:43 <marex> hanetzer: are you up for sending a patch then ?

16:43 <Tartarus> marex: A note to self for when I go and move that section of stuff out of README and board.h files, sure

16:44 <hanetzer> like, CONFIG_SYS_SDRAM_BASE

16:44 <marex> Tartarus: does your list of notes look like a roll of TP yet ?

16:44 <hanetzer> marex: I can't document what I don't grok :)(

16:44 <Tartarus> marex: heh

16:44 <hanetzer> hopefully I'll be able to send a patchset for the machine :P

17:23 <hanetzer> hrm. I have a second board of this I'm willing to sacrifice; could *probably* pop off the soc and beep out the jtag_en pin and see if there's something I can do to enable jtag tbh

17:32 <marex> hanetzer: what board / soc is that ?

17:32 <hanetzer> marex: consumer cctv device / hisilicon hi3521a

17:33 <marex> maybe the jtag is fused off in some otp ?

17:33 <hanetzer> doubtful. I was able to extract the on-chip brom with u-boot's tftp

17:33 <hanetzer> and no such otp/efuse is in their docs

17:34 <hanetzer> in other woids, not exactly a secure soc

17:38 <marex> hanetzer: if it has HDMI, there is a chance it also has some odd secure key store, and likely OTP

17:38 <hanetzer> perhaps. I had another board, hi3520d (similar but not the same) that I just had to move a resistor on

17:39 <marex> oh, heh

17:39 <hanetzer> some generic taobao purchase.

17:39 <hanetzer> maybe I should see if I can find a board with the exact same soc

17:50 <hanetzer> breh. 'all pins but JTAG are extracted' why would you have a dev board and bring out everything but jtag

17:50 <marex> hanetzer: to make your life miserable ?

17:51 <marex> hanetzer: https://hackaday.com/2009/12/17/accessing-bga-pins/

17:55 <hanetzer> I mean. I have another board with a lqfp similar chip which I know has jtag... could just work against that.

17:56 <hanetzer> just for the 'basis'

18:14 <hanetzer> heh... going thru my old notes. found an image where I put a light under the pcb to shine-thru the traces and trace out where jtag was

18:32 <marex> hanetzer: very little ground planes, huh

18:32 <hanetzer> yeh

18:47 <hanetzer> aight, this is the chip I think it is.