00:08 <Ermine> CounterPillow: thank you

16:32 <macromorgan> so I'm looking at the RAM code again for the RK3588 in U-Boot. If I want to keep moving forward with the ATAGS parsing for RK3588... would it make sense to flag the main dram_init_banksize() function as __weak so I can modify? Or am I being naive?

16:51 <qschulz> macromorgan: what do you have in mind?

16:56 <Ermine> I'm trying to build downstream kernel from firefly's linux sdk, and I get following error: https://pastesite.org/view/raw/eb99fdd7 . Does anybody have experience about how to deal with it? The device in question is rk3588s-evb4-lp4x-v10 . Guide on firefly's linux sdk is here: https://wiki.t-firefly.com/en/ROC-RK3588-PC/linux_compile.html

17:00 <qschulz> find where firefly_multicodecs_control_gpio is defined

17:00 <qschulz> then read the Makefile in the same directory of the file where you found that function defined

17:00 <qschulz> extract the CONIFG_ that is used to compile (or not) the source file into an object file

17:00 <qschulz> make menuconfig, enable the config that requires it

17:01 <qschulz> s/requires/enables/

17:07 <macromorgan> qschulz: I'm thinking of either marking dram_init_banksize() as __weak here: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-rockchip/sdram.c?ref_type=heads#L38

17:08 <macromorgan> or I'm thinking of adding a weak function that returns 0 to that file... something like int __weak board_read_ram() and then defining the function in the rk3588 specific code

17:08 <macromorgan> I'm just not sure what ramifications of that would be

17:08 <qschulz> macromorgan: what are you trying to solve as a problem?

17:08 <macromorgan> use ATAGS parsing to get the RAM banks for the RK3588

17:08 <macromorgan> or rather that's the solution to the problem

17:09 <qschulz> macromorgan: I don't see how this is helping, that's my issue

17:09 <macromorgan> the problem is that 1) there are addresses we shouldn't write to and 2) the current RAM bank definitions don't include all available RAM

17:09 <qschulz> do you mean you would redefine the board_read_ram in rk3588.c only?

17:10 <macromorgan> I'm actually (now that I say it out loud) leaning towards a weak function in sdram.c that returns 0 and then redefine that function in rk3588.c so that it parses the ATAGS RAM banks

17:11 <macromorgan> that way we can fall back to the old way of doing things if we can't read the ATAGS

17:11 <macromorgan> without duplicating the code

17:12 <qschulz> macromorgan: I'm not getting it (but it's also not my day, so probably nothing to do with your phrasing :) )

17:12 <qschulz> what would this help compared to the v1 you sent on the ML today?

17:12 <macromorgan> I should have phrased that as an RFC honestly rather than a V1, so that was my first mistake

17:13 <macromorgan> but it seems like Kever doesn't want me to include all that ATAGS code which I get

17:14 <macromorgan> I guess I can wait for further direction though before I continue on. Maybe there's another way we should be defining RAM banks (based on registers), or maybe there's some 3rd option I'm not aware of.

17:14 <qschulz> I haven't played with bloblist yet (completely missed that train), but my assumption is that they want to parse the ATAGS into a bloblist so that we can reuse the bloblist functions to find what we want?

17:14 <macromorgan> hmm... I guess I didn't take away that from the conversation but that makes more sense

17:14 <macromorgan> I'll have to look into bloblists then

17:15 <qschulz> if that's not what they want, I don't understand what they do want, because we get ATAGS from the TPL, and I can almost guarantee that Rockchip won't update their blobs to expose bloblists

17:16 <qschulz> macromorgan: when things aren't clear when you receive feedback from the community, just ask for clarification (maybe by providing some hints at what you think you understood and asking for validation)

17:16 <qschulz> that way you avoid wasting precious hours/days on things that were not requested/suggested :)

17:16 <macromorgan> thanks, I'll do that next time

17:16 <qschulz> I'm not in Kever's or Tom's head so cannot help you with that one

17:18 <qschulz> but if that can make you feel better, I also wouldn't know where to go from your v1 based on that feedback :)

17:21 <macromorgan> no, I think if there's a standard way (bloblist) that makes the most sense

17:30 <Ermine> qschulz: that helped, thank you!