<sjg1>
rfs613: You can put 'no_check: True' in your .patman file to avoid doing it every time. See 'If you want to change the defaults for patman's command-line arguments'
<sjg1>
Tartarus: 363G in /var/snap - who invented snap?
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
thopiekar has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
vagrantc has quit [Quit: leaving]
<Tartarus>
Yeah, I'm an old cranky person who dislikes all these new fangled sandboxes and prefer my old fangled sandboxes instead ;)
mckoan|away has joined #u-boot
jclsn0 has joined #u-boot
jclsn has quit [Ping timeout: 256 seconds]
<sjg1>
'docker container prune' fixed it this time
<sjg1>
Tartarus: so I hope kaki comes back to life
srk- has joined #u-boot
srk has quit [Ping timeout: 272 seconds]
srk- is now known as srk
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
apritzel has joined #u-boot
apritzel has quit [Ping timeout: 250 seconds]
jclsn0 is now known as jclsn
stefanro has quit [Ping timeout: 240 seconds]
apalos- is now known as apalos
stefanro has joined #u-boot
<Jacmet>
I'm looking at doing a robust/redundant boot setup with the spl from eMMC, but it doesn't right away seem obvious to do so given the hard coded / build time constants for what it loads. How do other people handle it? E.G. I guess you could conceptually expand CONFIG_SPL_FS_LOAD_PAYLOAD_NAME to a function that returns different strings depending on A/B boot or similar, but the partition number is also a
<Jacmet>
build time constant?
frieder has joined #u-boot
Jacmet_ has joined #u-boot
Jacmet has quit [Quit: leaving]
Jacmet_ is now known as Jacmet
mckoan|away is now known as mckoan
lucaceresoli has joined #u-boot
MiNuS_89 has joined #u-boot
matthias_bgg has joined #u-boot
sszy has joined #u-boot
tre has joined #u-boot
monstr has joined #u-boot
cbmuser_ has quit [Quit: WeeChat 1.6]
cbmuser has joined #u-boot
tre has quit [Remote host closed the connection]
apritzel has joined #u-boot
paulbarker has quit [Quit: Connection closed for inactivity]
mmu_man has joined #u-boot
matthias_bgg has quit [Remote host closed the connection]
matthias_bgg has joined #u-boot
<kabel>
Tartarus: which azure product do we use for CI? Azure Pipelines or Azure DevOps ?
<kabel>
ok I found it, sorry
ladis has joined #u-boot
lucaceresoli has quit [Remote host closed the connection]
lucaceresoli has joined #u-boot
MiNuS_89_ has joined #u-boot
MiNuS_89_ has quit [Read error: Connection reset by peer]
MiNuS_89 has quit [Ping timeout: 240 seconds]
tperrot has quit [Quit: leaving]
tprrt has joined #u-boot
tprrt has quit [Client Quit]
tprrt has joined #u-boot
tprrt is now known as tperrot
torez has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
milkylainen_ has joined #u-boot
<cambrian_invader>
Jacmet: typically you script the boot partition based off of the boot count
<cambrian_invader>
(and/or some other variable)
zibolo has quit [Ping timeout: 240 seconds]
<Jacmet>
cambrian_invader: yes, but that doesn't help for adding redundancy for when the spl tries to load the rest of u-boot
guillaume_g has quit [Quit: Konversation terminated!]
<Tartarus>
Yeah, doing redundant for updates u-boot in SPL is tricky and tends to be custom still
<kabel>
anyone wanna look at my u-boot-net patches? :)
apritzel_ has joined #u-boot
<Jacmet>
Tartarus: it would be be great if there was an easy way to provide a custom high level logic for the spl instead of having the logic fixed and all those build time configuration options for what partition and file to load
<Jacmet>
Tartarus: but I don't quite see how to do that with the current code, besides indirectly doing stuff like adding a custom function behind CONFIG_SPL_FS_LOAD_PAYLOAD_NAME and similar
<marex>
kabel: try rfried
<Tartarus>
Yeah, but that becomes kinda tricky with other requirements like size
<kabel>
rfried: I sent a bunch of u-boot-net patches, could you please let me know when will you have time to look at them? thx
<kabel>
rfs613: s/when/when (if at all)/ :D
<kabel>
s/rfs613/rfried/ :D
<Jacmet>
Tartarus: I don't quite see how this would clash with the size requirements. Making boot_from_devices() weak would already be helpful
<Tartarus>
Because making something flexible and run-time configurable and stuff tends to make things larger.
<Tartarus>
Happy to be wrong :)
<Jacmet>
Tartarus: the question is how such logic should looks like. There are already a LOT of config options to tweak how the SPL should behave, but it doesn't quite look flexible enough. Allowing a platform to have their own high level logic (in C code rather than through a bunch of complicated config options) would IMHO be more flexible and smaller
sobkas has joined #u-boot
<Jacmet>
Tartarus: but ok, I'll give it a try. I was just getting confused as it seemed like a pretty normal thing to want to do, and I couldn't find it in the existing logic
<Tartarus>
The OTA line is usually drawn above U-Boot itself, not including u-boot itself is part of the why
<Jacmet>
Tartarus: ok, my experience seems to tell me that whenever I have a non-updatable SW component in my project I end up regretting it sooner or later ;)
<Jacmet>
Tartarus: this is on zynqmp where the boot rom already has fallback logic to look for the spl in different locations (or filenames rather) - So it is kind of annoying that all the different spl copies I can have will all try to load (and possibly fail) the same u-boot
<Tartarus>
Yeah, what is/isn't possible depends on the SoC and what logic you want to try and do
<sjg1>
cambrian_invader: Jacmet: The bootstd series uses driver model so can run in SPL fairly easily - bootflow_scan_next() followed by bootflow_run_boot()
apritzel has quit [Ping timeout: 240 seconds]
<sjg1>
Having said that the A/B boot side of it is not done yet. Still waiting to get some sort of agreement on the basic structure
<kallisti5[m]>
hm.. any known regressions in master on the SiFive unmatched?
<kallisti5[m]>
Updated from a Nov 5th, 2021 u-boot with OpenSPI 0.9 to a March 17th u-boot with OpenSPI 0.9 and 1.0. The March 17th image fails to boot with both SPI's
MiNuS_89 has joined #u-boot
<MiNuS_89>
marex: I managed to build my own kernel and get the same behavior with the original u-boot and the new one (work on one and wrash on PCI on the second one) . Now I can start to play around with disabling options to know what prevent the boot with the new U-Boot. I disable PCI and let you know.
<marex>
MiNuS_89: turning things off until you identify what triggers the crash is a good idea
<marex>
MiNuS_89: probably build yourself busybox (statically linked) and use it as a ramdisk
<MiNuS_89>
marex: will past with paste.debian.net for better visibility
<marex>
MiNuS_89: try setting this before booting the kernel
<marex>
=> setenv fdt_high 0x84000000
<marex>
then boot
<marex>
that will limit FDT placement below 0x84000000
<kallisti5[m]>
> hm.. any known regressions in master on the SiFive unmatched?
<kallisti5[m]>
I've rebased all the way back to the original working version.. same issue. Starting to think GCC 11.1/11.2 is the devil
apritzel_ has joined #u-boot
<kallisti5[m]>
I'm building my old gcc 8.2 toolchain to see if it fixes it
<kallisti5[m]>
if so... i hate gcc
<MiNuS_89>
marex: fdt_high had no impact. I will play around a bit with the kernel to be sure it's not a build issue as when I removed PCI support everything was empty in the kernel config. It removed everything. I also tried fdh_high with OpenWRT 22.02.2 vanillia kernel same thing it freeze on PCI
<marex>
kallisti5[m]: instead of hate, report a bug or send a patch ...
<MiNuS_89>
will also spend more time reading again memory section of U-Boot
<kallisti5[m]>
I guess lol :-)
<marex>
MiNuS_89: the memory looks ok, assuming you do have 128 MiB of DRAM
<marex>
MiNuS_89: it is KSEG0, so OK
<MiNuS_89>
yes I do have
<marex>
MiNuS_89: oh, right, the AR9331 I used didn't have PCIe ... of course
<marex>
the 934x might've had PCIe, but it's been a long time
<MiNuS_89>
I do have 128 MB, the only doubt is to have the flash at 0x0 as it's supposed to be located at CONFIG_SYS_FLASH_BASE=0x9F000000
<marex>
unless you try to do XIP, you can ignore the flash for now
<MiNuS_89>
ok
<MiNuS_89>
the strange thing is the ethernet if working, as I do not have JTAG i use tftp to load in memory
<MiNuS_89>
so if something goes wrong on PCI init it should impact ethernet ability to operate properly
<kallisti5[m]>
AAHHHHAHAHAH it was the microsd card
<marex>
MiNuS_89: are you sure ?
<marex>
MiNuS_89: I thought the PCIe is for WiFi MACs only
<kallisti5[m]>
my lungs. I was down to bisecting with multiple gcc toolchains 😆
<marex>
that's where the ath10k is connected
<marex>
MiNuS_89: the ar9xxx should have a gigabit MAC built into it I think
<MiNuS_89>
I check that on an operational device (I have more than one)
Finde has quit [Ping timeout: 256 seconds]
ladis has quit [Quit: Leaving]
<MiNuS_89>
marex: you are right only wireless is reported on PCI : 00:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac Wireless Network Adapter
<MiNuS_89>
I will try to dig a bit more into that issue but it looks like an init missing somewhere and it's above my competencies. I can survive without a new bootloader.
<marex>
MiNuS_89: do you have sources of the ancient vendor uboot ?
<marex>
if so, look what kind of register writes they do there, it might give you a hint
<MiNuS_89>
yes but it's super different on the structure you guys have change so much things
<marex>
the blame lies squarely on atheros for not upstreaming their stuff and rotting on U-Boot 1.1.4 or whatever version they are stuck at
prabhakarlad has quit [Quit: Client closed]
<MiNuS_89>
they are still stucked with U-Boot 1.1.4 with brace yourself toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2.tar.bz2
<marex>
so, yes ... run git diff between actual 1.1.4 and their ap152 fork and look for anything related to PCIe
<marex>
then fill it into arch/mips/ somewhere
<MiNuS_89>
will try and let you know if I manage to make it work
<MiNuS_89>
I don't understant thos manufacturer that struggle with oldies instead of trying to contribute ... anyway. I will dig a bit and if I find I will share it and if not I will drop de ball. Thanks for the support
<marex>
MiNuS_89: well 1.1.4 is like 20 years old (?)
<marex>
it's been different times
<MiNuS_89>
and ap152 is not so old
<marex>
they just forked once and started piling up stuff in that version
<MiNuS_89>
marex: and we are stucked with static environment :-) while the new u-boot offer many new stuffs .... It's very strange that nobody decided to integrate all that on the main version to benefit of new features.
<MiNuS_89>
by nobody I mean nobody at Qualcom/Atheros
<marex>
I tried upstreaming at least some of it some time ago
<marex>
feel free to pick it up and maintain it further, it would be nice if you did
<MiNuS_89>
I have tons of projects to follow but yes if I find something I will publish it for sure.