00:36 <lucascastro> Hello, I just doing some studying on u-boot. When I load/make *defconfig, i.e Bananapi_M2_Ultra_defconfig

00:37 <lucascastro> SYS_LOAD_ADDR is written to config but I can't recognize where its comes from.

00:37 <lucascastro> Does someone can tell me about this?

00:46 <Tartarus> Well, it's a Kconfig option

00:47 <Tartarus> $ git grep config\ SYS_LOAD_ADDR

00:47 <Tartarus> Kconfig:config SYS_LOAD_ADDR

00:47 <lucascastro> I had run rgre

00:49 <lucascastro> rgrep, but the bpim2u write 0x42000000, I can't find where the 0x42000000 came from, and I'm trying to find it on R40 manual but i'm guess it's calculated somehow.

00:50 <Tartarus> Yes, that's the default for all sunxi platforms

00:50 <Tartarus> And likely came out of some ref manual or another

00:50 <lucascastro> got it .

00:50 <lucascastro> it's already defined on Kconfig

15:27 <marex> cambrian_invader: hey, do you recall why https://git.openembedded.org/openembedded-core/commit/?id=5e12dc911d0c541f43aa6d0c046fb87e8b7c1f7e adds the KERNEL_PN dependency into uboot-sign.bbclass ?

16:06 <Forty-Bot> marex: note [1] ?

16:20 <SlimeyX> make help

16:20 <SlimeyX> Makefile:40: *** missing separator. Stop.

16:20 <SlimeyX> whats that about

16:34 <marex> Forty-Bot: I found a dependency loop in there :(

16:37 <Forty-Bot> marex: what's the loop?

16:37 <marex> Forty-Bot: basically if UBOOT_ENV is set , then kernel-fitimage bbclass do_install depends on u-boot do_populate_sysroot (depends on u-boot do_install) because it needs to bundle the env into the fitImage , but u_boot do_uboot_assemble_fitimage has to run before u-boot do_install and depends on kernel do_install to deploy the kernel fitImage so it can be used as input for signing

16:38 <marex> Forty-Bot: (does what I wrote make sense?)

16:38 <marex> Forty-Bot: I can think of ways to resolve it, but they all include breaking changes, sigh

16:44 <Forty-Bot> marex: sure, that makes sense

16:44 <Forty-Bot> marex: but I think you can just do the thing I suggested in the note

16:45 <Forty-Bot> tbh idk what the point of the UBOOT_ENV stuff is; if I want to change the U-Boot environment, I just modify the default environment in the source

16:46 <marex> Forty-Bot: UBOOT_ENV scripts embedded in fitImage , useful when you want to extend U-Boot env during e.g. an update , the script in the fitImage can be signed too

16:46 <marex> Forty-Bot: maybe uboot-sign.bbclass should generate/use empty fitImage instead ?

16:46 <Forty-Bot> I guess, but you don't have to put it in the same FIT

16:47 <Forty-Bot> like, when I added dm-verity support (which I should get around to upstreaming at some point...) I just created a separate script that gets sourced during the boot process

16:48 <Forty-Bot> anyway, to be specific, yes you should generate an empty fitImage with the same structure as normal but with no data

16:48 <marex> Forty-Bot: I dont even need the same structure, all I need is the config node, no ?

16:49 <Forty-Bot> you need the whole thing for stuff like kernel_sign_keyname etc.

16:50 <Forty-Bot> since images can be individually signed to permit mix and match attacks :)

16:53 <marex> Forty-Bot: not for the uboot-sign.bbclass , right ?

16:54 <marex> Forty-Bot: that mkimage ... -r fitImage is a throw-away fitImage, isn't it ?

16:55 <Forty-Bot> to be clear; I suggest adding a assemble_dummy_fitimage task to kernel-fitimage that creates a FIT with no data (and therefore doesn't need to depend on u-boot:do_populate_sysroot)

16:55 <Forty-Bot> and then depending on that instead of assemble_fitimage in uboot-sign

16:58 <marex> Forty-Bot: but uboot-sign does not depend on kernel-fitimage assemble_fitimage , it depends on KERNEL_PN (really should depend on KERNEL_PN do_populate_sysroot I guess)

16:58 <Forty-Bot> yes

16:58 <marex> Forty-Bot: but ... I don't realy get this, the mkimage in uboot-sign bbclass generates a throwaway fitImage with the -r parameter, doesn't it ?

16:59 <marex> so why not pass in empty fitImage ?

16:59 <Forty-Bot> no, it consumes a throwaway fitimage

16:59 <Forty-Bot> and yes, you can, but the whole point is that the keys embedded in u-boot's FIT are determined by the keys used in the dummy FIT

17:00 <Forty-Bot> so the dummy has to have the same structure as the real thing, in order to ensure the correct keys are embedded

17:01 <marex> Forty-Bot: doesn't that mkimage ... -r generate only a /signature node in the fitImage

17:01 <marex> ?

17:03 <Forty-Bot> -K also embeds the keys into u-boot's dtb

17:05 <marex> Forty-Bot: sigh ... right ... thanks

17:06 <marex> Forty-Bot: but this still won't help us break the dependency loop

17:06 <Forty-Bot> why not?

17:06 <marex> the kernel recipe would have to run all the way until do_populate_sysroot to make ${STAGING_DIR_HOST}/sysroot-only/fitImage available to the u-boot recipe, right ?

17:07 <Forty-Bot> hm; maybe we can make that happen earlier?

17:08 <marex> Forty-Bot: if I could start putting stuff into sysroot earlier, then I would put the env into sysroot earlier

17:08 <Forty-Bot> alternatively, you can separate out the kernel variables into a kernel-config bbclass like what is done for u-boot

17:08 <Forty-Bot> and then include that from u-boot to create the dummy recipe there

17:09 <marex> this is not a kernel variables problem , this is a dependency ordering problem , really

17:09 <Forty-Bot> well the only thing we really need is the knowlege of what keys we want to sign the kernel with

17:10 <marex> I am thinking of rebuilding the u-boot env file using mkimage in kernel-fitimage.bbclass , that would be easy too

17:10 <marex> but I cannot access that env file because it is in u-boot recipe

17:42 <rfs613> SlimeyX: in case you haven't figured it out yet... you likely have spaces instead of tabs on line 40 of the Makefile

17:43 <SlimeyX> this is a fresh clone from git 2025.01 final

17:46 <rfs613> SlimeyX: seems fine here. What version of make are you using?

17:47 <SlimeyX> GNU Make 4.4.1

17:47 <SlimeyX> Built for x86_64-pc-linux-gnu

17:49 <rfs613> hmm.. should be new enough... did you get the source from git using a tag, or using a tarball? (just trying to figure out what's different).

17:50 <marex> remove the undefine on like 40 in Makefile and see if the rest works ?

17:56 <SlimeyX> from git

17:57 <rfs613> yeah i guess commenting out line 40 (or deleting it) would be worth a try...

17:57 <rfs613> but the error ('mising separator') does not really make sense on that line

17:58 <rfs613> so maybe the its line 40 of a different Makefile?

18:40 <rfs613> SlimeyX: ^^^

18:53 <SlimeyX> weird i rebooted the box and error is gone, wtf

19:22 <SlimeyX> under my #defin e config extra env settings if i remove "protect on $ubootaddr +$filesize && " will that allow me to save the settings and they will stick

20:00 <rfs613> SlimeyX: might try running memtest86 to see if there's any problems with the RAM on that machine? Or the disk misbehaving?

20:01 <rfs613> SlimeyX: as for "protect on", that *might* let you save settings, but there are several possible ways of "blocking" the save/restore of environment.

20:01 <rfs613> it's hard to say which one(s) are in play on your particular board/configuration

20:03 <rfs613> the "protect on" works on flash devices which offer a feature of write-protecting some or all of the blocks of the flash.

20:04 <rfs613> some flash chips retain the protection setting even across power cycle, so in such case, just removing "protect on" would not unlock the flash.

20:07 <SlimeyX> https://bucblinn-my.sharepoint.com/:u:/g/personal/brian_gonyer_blinn_edu/Eex81nTFdOdFvJ_3JJkrHUwB2biTH_udUfkQzjxsS6zJzA?e=cOLbRH

20:07 <rfs613> note that ""protect on $ubootaddr +$filesize" is probably trying to protect u-boot binary, so that you don't accidentally erase it, and then cannot boot.

20:07 <SlimeyX> ah

20:08 <rfs613> the environment is typically stored in a different area of the flash, so you can modify it, without affecting u-boot code itself

20:11 <rfs613> seems to be a wifi access point, and seems to be supported by dd-wrt

20:14 <rfs613> https://wikidevi.wi-cat.ru/Adtran_Bluesocket_BSAP-3040 shows the stock boot messages

20:15 <SlimeyX> heh yeah i posted the logs ;)

20:15 <rfs613> can see the message "Erasing SPI flash...Writing to SPI flash...done" which suggests it is probably doing "env save" (or "saveenv") during the boot

20:16 <rfs613> are you able to reach the u-boot command prompt?

20:16 <SlimeyX> yeah it has a bootkey set which is b100:

20:21 <rfs613> okay, so I guess you are able to do 'setenv', but not 'env save' to make the change persistent?

20:23 <rfs613> oh i just found your post of the default environment

20:25 <rfs613> (I don't seem to see the "protect on" anywhere in there...)

20:35 <rfs613> also you got the mtd partition layout.. so looks like the first 1MB is for u-boot (binary code), and the next 64kB is for the u-boot environment

20:38 <SlimeyX> yeah i want to modify all that at some point

20:39 <rfs613> does the userspace happen to include fw_printenv by any change?

20:39 <rfs613> *chance

20:44 <SlimeyX> yes, i think a userspace app was changing things back to "defaults"

20:47 <rfs613> certainly possible... but in that case, best option would be to track down that userspace and "fix" it.

20:50 <SlimeyX> nah im going to run openwrt on it instead of the yocto build they put on, without a license and a controller to connect it to its just a heavy ass brick

20:52 <rfs613> with lots of antennas ;-)

20:55 <SlimeyX> [ 0.000000] Linux version 5.15.85 (briang@briang-optiplex9020) (powerpc64-openwrt-linux-musl-gcc (OpenWrt GCC 11.3.0 r21563-9ed1830bdc) 11.3.0, GNU ld (GNU Binutils) 2.37) #0 SMP Tue Dec 27 18:10:05 2022

20:55 <SlimeyX> [ 0.000000] Using CoreNet Generic machine description

20:56 <SlimeyX> heh messed with this a while back, couldnt figure out the radios :\ but i can replace them with 4x4 ax cards instead of the qcom 9990 or whatevers are installed

20:57 <SlimeyX> https://asiarf.com/product/wi-fi-6-11ax-4t4r-mini-pcie-module-mt7915-aw7915-np1/

21:01 <SlimeyX> and neither network card works gotta to see why that is also