00:00 <clever> unlikely to find that

00:04 <clever> marex: one interesting thing ive found, is that the VEC can generate up to 3 analog outputs, in 3 channel mode it can do either YPbCr or RGB, in 2 channel mode it can do s-video, and in 1 channel mode it can do composite

00:04 <clever> but at least on all rpi soc's, only 1 DAC is in the silicon, so its limited to composite only

00:05 <clever> oh, and ive heard that the bcm2835 has a whole FM radio receiver in it

00:46 <clever> marex: so, if i was crazy enough to try and port u-boot to another arch, where the spl and uboot proper are 2 files, which arch could i look at to copy bits from?

01:54 <Forty-Bot> clever: look at riscv

01:54 <Forty-Bot> since it's pretty recent

01:56 <clever> Forty-Bot: i'll have a look over it if i decide to embark on that crazy idea

02:45 <clever> oh, and one feature i was planning to add to u-boot, another way of passing some device-tree into it on startup, that doesnt use the rpi arm stubs

02:45 <clever> https://github.com/librerpi/lk-overlay/blob/master/app/inter-arch/include/platform/bcm28xx/inter-arch.h#L3-L11

02:46 <clever> this structure is added to the binary at an aligned addr (probably in the SPL stage), and as the u-boot.bin is copied into ram, the header is located, and the dtb_base is modified

02:47 <clever> i'm guessing SPL would then need to copy that into the global-data, and then u-boot proper can do something with the dtb before it gets stepped on

02:52 <clever> but tracing how the rpi u-boot handles the firmware dtb, its odd, and doesnt seem to go thru the SPL code?

02:53 <clever> reset: runs save_boot_params, which uses =fw_dtb_pointer to get the addr of something in .data, this is basically the first opcode in u-boot.bin, so its definitely SPL and nothing has been relocated yet

02:53 <clever> fw_dtb_pointer is then used by a function under board_init_r, which is in the relocated code??

04:31 <marex> clever: which arch ?

04:31 <marex> SPL and U-Boot are generally two files (well, two differently configured builds of U-Boot no less)

05:19 <clever> marex: rpi arm

05:20 <clever> https://github.com/u-boot/u-boot/blob/master/board/raspberrypi/rpi/rpi.c

05:22 <clever> and also lowlevel_init.S from the same file

12:39 <Tartarus> Er

12:39 <Tartarus> We could, but don't, take the DT that the Pi firmware passes along

12:39 <marex> Tartarus: if you read the backlog, I think you would find out clever is writing a replacement fw

12:39 <Tartarus> Ah, ok

12:42 <clever> Tartarus: one issue with the official armstubs, is that you need to insert the addr of the firmware dtb and kernel, at an addr just below 256 bytes, but if i want to go stubless and put u-boot at the reset vector, getting a header at that addr could be tricky, and i dont want to force that limit on every future arm kernel

12:43 <clever> https://github.com/librerpi/lk-overlay/blob/master/app/inter-arch/include/platform/bcm28xx/inter-arch.h#L3-L11

12:43 <clever> https://github.com/librerpi/lk-overlay/blob/master/app/inter-arch/inter-arch.c#L18-L22

12:43 <clever> Tartarus: my solution to that, is to have this structure at a 16-byte aligned addr, anywhere in the arm kernel, and it gets populated with the dtb

12:45 <Tartarus> Makes sense

12:46 <Tartarus> For a moment I thought you were just dealing with some of the issues U-Boot normally has on Pis because we don't take the DT as passed along

12:46 <Tartarus> This is much more complex and interesting :)

12:46 <clever> then the _start only has to worry about setting up its own stack, and the initial value of r2/x0 means nothing

12:46 <clever> https://github.com/librerpi/lk-overlay/blob/master/platform/bcm28xx/arm/arm.c

12:47 <clever> Tartarus: lines 94-145 runs on the VPU, and creates my own custom DTB, its not meant to be compatible with how things like linux boots, its only to ferry over custom variables

12:47 <clever> while being both forwards and backwards compatible with other versions of itself

12:48 <clever> lines 190-199 selects the right embedded .bin file, so you could bake 3 builds of u-boot into it

12:48 <clever> 203-216 copies that .bin to the arm reset vector

12:48 <clever> 233-263 finds the inter_arch header and modifies it

12:49 <clever> the rest is all code to turn the arm core(s) on

20:23 <clever> marex: i think ive identified where u-boot is failing, gd->ram_size doesnt matter, gd->bd->bi_dram does!

20:23 <clever> marex: and rpi.c is configured to populate bi_dram from the dtb that is absent

20:23 <marex> clever: nice

20:24 <clever> there is a weak/default implementation of dram_init_banksize

20:24 <clever> 243 gd->bd->bi_dram[0].start = gd->ram_base;

20:24 <clever> 244 gd->bd->bi_dram[0].size = get_effective_memsize();

20:24 <clever> but if uboot is built with CONFIG_OF_BOARD, rpi.c overrides that, and has no fallback for when dtb parsing fails

20:24 <clever> so it then just claims to have 0 bytes of ram

20:24 <clever> and things dont go well from there

20:28 <marex> clever: if you want to make things simple and compatible, pass a DT from your firmware too

20:29 <clever> marex: part of the issue, is that i dont want to be duplicating all of the code for loading and patching a dtb file

20:29 <clever> so i'm just passing a stripped down dtb via my own api

20:29 <clever> and i need to now modify uboot to read that

20:30 <marex> clever: makes sense, just load some small DT blob which you bundle with your firmware and pass it on

20:30 <marex> then the next stage(s) would just work without changes

20:30 <clever> even simpler!

20:31 <marex> no need for your own DT compiler in the firmware, like RPi does

20:31 <clever> https://github.com/librerpi/lk-overlay/blob/master/platform/bcm28xx/arm/arm.c#L94-L145

20:31 <clever> marex: this is the entire dtb

20:31 <clever> only 2 nodes currently, with 5 key/value pairs

20:32 <clever> adding a /memory node is next on the list, so i can populate bi_dram

20:32 <marex> yep, dont forget to add #address-cells and #size-cells

20:32 <marex> :)

20:32 <clever> until now, this was only being parsed by my own code with libfdt, so i didnt have to follow the #address-cells rules

20:32 <clever> but if i want to recycle some u-boot code, that would be best