Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2022.01, v2022.04-rc2 are OUT / Merge Window is CLOSED / Release v2022.04 is scheduled for 4 April 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
sobkas has quit [Quit: sobkas]
<apritzel> Tartarus: I get some download error with the coreboot CI job: https://source.denx.de/u-boot/custodians/u-boot-sunxi/-/jobs/406170
mckoan|away has quit [Ping timeout: 256 seconds]
apritzel has quit [Ping timeout: 240 seconds]
<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
<Tartarus> and failure cases
<cambrian_invader> Jacmet: I think sjg1 had some stuff in this area e.g. https://lore.kernel.org/u-boot/20220306125016.3133737-1-sjg@chromium.org/ but I don't think it's designed for SPL
<Jacmet> cambrian_invader: thanks, that indeed looks to be for the "full" u-boot
monstr has quit [Remote host closed the connection]
<Jacmet> anyway, thanks - Will hack on it a bit
<cambrian_invader> (this is more because I know simon has been working in something adjacent, so perhaps he has some ideas)
frieder has quit [Remote host closed the connection]
apritzel_ has quit [Ping timeout: 250 seconds]
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
mckoan is now known as mckoan|away
baltazar has quit [Ping timeout: 256 seconds]
baltazar has joined #u-boot
<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
<marex> that helps too once you get to init
<rfried> kabel: what patches are yours ?
<MiNuS_89> marex: it's even shorter without PCI ;-)
<rfried> kabel: you just pushed those few hours ago.
<rfried> I thought there some patches rotting in my mailbox that i missed.
<rfried> I'll get to those later this week.
<MiNuS_89> [ 0.000000] Kernel panic - not syncing: early_init_dt_alloc_memory_arch: Failed to allocate 8701 bytes align=0x40
<MiNuS_89> there is definitely memory allocation issue.
<cambrian_invader> make sure the memory in "bdinfo" looks correct
<MiNuS_89> ArcherC7V5 # bdinfo
<MiNuS_89> boot_params = 0x87f73370
<MiNuS_89> DRAM bank = 0x00000000
<kabel> rfried: thx
<MiNuS_89> -> start = 0x80000000
<MiNuS_89> -> size = 0x08000000
<MiNuS_89> flashstart = 0x00000000
<MiNuS_89> flashsize = 0x00000000
<MiNuS_89> flashoffset = 0x00000000
<MiNuS_89> baudrate = 115200 bps
<MiNuS_89> relocaddr = 0x87fa0000
<MiNuS_89> reloc off = 0xe8fa0000
<MiNuS_89> Build = 32-bit
<MiNuS_89> current eth = eth@0x19000000
<marex> paste.debian.net
<MiNuS_89> ethaddr = 98:5d:ad:43:dd:38
<MiNuS_89> IP addr = <NULL>
<MiNuS_89> fdt_blob = 0x87f4ed90
<MiNuS_89> new_fdt = 0x87f4ed90
<MiNuS_89> fdt_size = 0x00001140
<MiNuS_89> lmb_dump_all:
<MiNuS_89> memory.cnt = 0x1
<MiNuS_89> memory[0] [0x80000000-0x87ffffff], 0x08000000 bytes flags: 0
<MiNuS_89> reserved.cnt = 0x1
<MiNuS_89> reserved[0] [0x87f4cba8-0x87ffffff], 0x000b3458 bytes flags: 0
<MiNuS_89> devicetree = separate
<j`ey> lol any mods? :P
<MiNuS_89> cambrian_invader: looks ok.
<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.
<marex> everyone is busy, what else is new, heh
<MiNuS_89> ;-)
MiNuS_89 has quit [Quit: MiNuS_89]
sobkas has quit [Quit: sobkas]
vagrantc has joined #u-boot
sobkas has joined #u-boot
torez has quit [Quit: torez]
mthall has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
mthall has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
sobkas has quit [Quit: sobkas]
mthall has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
mthall has joined #u-boot
lucaceresoli has quit [Ping timeout: 240 seconds]