Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2023.07 is OUT / Merge Window is OPEN, next branch is CLOSED / Release v2023.10 is scheduled for 02 October 2023 / Channel archives at https://libera.irclog.whitequark.org/u-boot
thopiekar has quit [Ping timeout: 246 seconds]
<marex> aisha[m]: which soc/board/... details please ?
<aisha[m]> this is for rockpro64_rk3399 board
<marex> sjg1: I finally had a chance to test the new, now supposed to be working branch with binman stuff
<marex> sjg1: the change is, that, now not even SPL starts, it is completely totally broken
<sjg1> Tartarus: i doubt it
<marex> aisha[m]: see atf docs/plat/rockchip.rst
<marex> aisha[m]: probably just make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31 or some such
<marex> (in atf tree)
<aisha[m]> I found out after reading the source, that it expects a file of the type elf, called bl31.elf, so I downloaded the atf repo and did a make, which created a bl31.elf, then copied it to my local repo and then did a make with make BL31=path to elf
<aisha[m]> it seems to progress farther now
<aisha[m]> EEEYYY it compiled
<aisha[m]> tyty marex :)
<marex> sjg1: if I revert the top three patches, it works ... oh well ...
<marex> sjg1: looking at the flash.bin, it is massively different, e.g. some part which starts with _FDTMAP_ is missing , and there seem to be DRAM init blobs listed in that missing section too
vagrantc has joined #u-boot
mncheck has quit [Ping timeout: 245 seconds]
<Tartarus> sjg1: Well, what I _need_ is "way to find new defconfigs without MAINTAINERS entry"
<Tartarus> It was genboards.cfg, and then buildman -R
<Tartarus> Give me a new option that's just going to tell me what I want, and that's fine I suppose
<Tartarus> A long term better thing and hey, does Linux have one itself, is give me files that lack MAINTAINER coverage
naoki has joined #u-boot
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #u-boot
thopiekar has joined #u-boot
tchebb has quit [Ping timeout: 252 seconds]
tchebb has joined #u-boot
alpernebbi has quit [Ping timeout: 246 seconds]
alpernebbi has joined #u-boot
sng has joined #u-boot
sng has quit [Ping timeout: 245 seconds]
naoki has quit [Ping timeout: 252 seconds]
sng has joined #u-boot
vagrantc has quit [Quit: leaving]
sng has quit [Ping timeout: 252 seconds]
vagrantc has joined #u-boot
Slimey has quit [Remote host closed the connection]
wooosaiiii has joined #u-boot
vagrantc has quit [Quit: leaving]
naoki has joined #u-boot
sng has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
sng has quit [Remote host closed the connection]
monstr has joined #u-boot
mncheck has joined #u-boot
<lvrp16> whats the plan with the "bootdevice" environment variable? I use it quite extensively in my out of tree code and wondering if I should use something more robust that doesn't rely on environment variables.
<lvrp16> cmd/nand.c and disk/part.c both use it automagically
mncheck-m has joined #u-boot
mncheck has quit [Read error: Connection reset by peer]
sng has joined #u-boot
goliath has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
frieder has joined #u-boot
<sfo[m]> In my understanding in an ideal world uboot dt is in sync with Linux dt. Changes present in uboot are supposed to be upstreamed into Linux and the Linux dt gets synched back to uboot from time to time?
<lvrp16> sfo[m]: the other way around, linux -> u-boot
<sfo[m]> yeah
ikarso has joined #u-boot
<sfo[m]> Then, I don't understand the reason behind https://source.denx.de/u-boot/u-boot/-/commit/d0e62eeda822c657586cb46fa1e4b934b3cc0905 as there are different DTS for each of the boards mentioned
mmind00_ is now known as mmind00
mmind00 has quit [Quit: mmind00]
mmind00 has joined #u-boot
<sfo[m]> From my tests I conclude that a subset of the mentioned DTs is enough to load uboot
<sfo[m]> but removing the dts for some of the boards and keeping another specific one does not feel right
<sfo[m]> how does a newcomer (coming from a linux context) know that rk3399-rock-pi-4a should be used for rk3399-rock-pi-4b in uboot?
Adrian___ has joined #u-boot
stefanro has joined #u-boot
<lvrp16> some maintainers do not do a great job. the state of the dts tree is also be cleaned up.
<lvrp16> it's a confusing mess. ask the vendor. they should be doing it themselves
jaganteki has joined #u-boot
paulbarker has joined #u-boot
sng has quit [Ping timeout: 246 seconds]
mmu_man has joined #u-boot
jpanisbl has joined #u-boot
matthias_bgg has joined #u-boot
ldevulder has quit [Remote host closed the connection]
sszy has joined #u-boot
ldevulder has joined #u-boot
sszy has quit [Client Quit]
sszy has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
LordKalma has quit [Quit: Server has probably crashed]
LordKalma has joined #u-boot
LordKalma has quit [Client Quit]
LordKalma has joined #u-boot
LordKalma has quit [Client Quit]
LordKalma has joined #u-boot
LordKalma has quit [Client Quit]
LordKalma has joined #u-boot
mmu_man has joined #u-boot
Adrian has joined #u-boot
jaganteki has quit [Quit: Client closed]
Adrian___ has quit [Ping timeout: 252 seconds]
jaganteki has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
<Kwiboo> sfo[m]: the main/only diff on 4A vs 4B models is wifi/bt, something that is not working in u-boot, there is also only a rock-pi-4-rk3399_defconfig without the model specific suffix
mmu_man has joined #u-boot
<Kwiboo> typically the linux dtb will be used when linux is loaded, so for u-boot booting purpose the b variant is not really needed
<sfo[m]> sure, but then wouldn't a generic rk3399-rock-pi-4.dts (instead of rk3399-rock-pi-4a.dts) make more sense in u-boot?
<Kwiboo> guessing it is easier to keep files in sync when filename matches and not having to rename it
jaganteki has quit [Quit: Client closed]
sng has joined #u-boot
camus has quit [Remote host closed the connection]
camus has joined #u-boot
jpanisbl has quit [Ping timeout: 245 seconds]
mmu_man has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
jaganteki has joined #u-boot
<naoki> Kwiboo: Kwiboo, sfo[m]: dtb for each board is available in Linux, but u-boot binary from rock-pi-4-rk3399_defconfig load dtb for ROCK Pi A... we(radxa) need to provide patched u-boot for each board
<naoki> (I understand it's just env matter)
jpanisbl has joined #u-boot
jclsn has joined #u-boot
jclsn has quit [Client Quit]
Adrian has quit [Ping timeout: 250 seconds]
jclsn has joined #u-boot
<naoki> how should I send this patch?
<marex> naoki: git send-email --annotate --to=u-boot@lists.denx.de -1 <commit ID>
Adrian has joined #u-boot
jaganteki has quit [Ping timeout: 246 seconds]
mmu_man has quit [Ping timeout: 250 seconds]
<sfo[m]> naoki: out of curiosity, what changes do you apply on top of vanilla u-boot for the radxa images?
<naoki> we build 7 images for ROCK 4 variants
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 245 seconds]
jpanisbl has quit [Quit: Konversation terminated!]
jaganteki has joined #u-boot
wooosaiiii has quit [Quit: wooosaiiii]
wooosaiiii has joined #u-boot
sng has quit [Read error: Connection reset by peer]
jaganteki has quit [Ping timeout: 246 seconds]
sng has joined #u-boot
<marex> naoki: why not single image ?
apalos- has joined #u-boot
<marex> naoki: why not upstream it all instead ?
<naoki> marex: is it better to use single image with 7 extlinux.conf?
<naoki> well, "why not upstream it" what is "it"?
apalos- has quit [Quit: ZNC 1.7.2 - https://znc.in]
<marex> naoki: it is better to use single bootloader image, since it is less confusing to users which one to pick
<marex> naoki: it == the outstanding patches
<sfo[m]> I think that's what I was thinking 😉
<marex> naoki: yes, thanks !
<marex> "It will be better to re-use one defconfig all the board in one series, " -> indeed
ikarso has quit [Quit: Connection closed for inactivity]
mncheck-m has quit [Ping timeout: 245 seconds]
apalos- has joined #u-boot
<sjg1> marex: OK so it doesn't even boot SPL? Does the fdtmap help show what is different?
<marex> sjg1: hexdump of flash.bin shows that it is completely different file , it shouldnt be
splud has joined #u-boot
<sjg1> marex: OK I'll need to have another look. It was mostly the same when I did it. You are using gh/for-marek the same, right?
<sjg1> Tartarus: re missing maintainers, yes I thought buildman did that, but when I remove board/bosch/guardian/MAINTAINERS I don't get an error from 'buildman -R -'
<naoki> sjg1: thanks. I sent some patches to ML, I think I can do it. then, what I wanted to ask about https://lists.denx.de/pipermail/u-boot/2023-January/504988.html is, I need this patch, but I'm not author of it
<sjg1> naoki: You can still include it when emailing - it will show up with a From: line in the patch so that the correct author is recorded
<sjg1> nohit: (If that is what you were asking)
<naoki> sjg1: thanks, I'll do it
ikarso has joined #u-boot
<marex> sjg1: why not simply diff the hexdump of flash.bin to see whether whatever you pushed out works first ?
mmu_man has joined #u-boot
<marex> sjg1: and yes, I was using the GH branch
stipa has quit [Read error: Connection reset by peer]
<sjg1> marex: Oh wow it is wildly different now. I'm not sure what I was looking at
<Tartarus> sjg1: Ugh, when did that get broken? Let me confirm I'm not quite misremembering things
jaganteki has joined #u-boot
<Tartarus> it used to :)
<Tartarus> bisecting
<sjg1> Tartarus: Thanks...I've seen it too but perhaps it broke. I'll need to add a test for that too...
goliath has quit [Quit: SIGSEGV]
<Tartarus> commit e8da1da82f1ea1842d6137cdbecef4dc79bb594c
<Tartarus> Date: Tue Oct 11 08:15:37 2022 -0600
<Tartarus> Author: Simon Glass <sjg@chromium.org>
<Tartarus> buildman: Handle the MAINTAINERS 'N' tag
<Tartarus> that's what broke it
<Tartarus> So the regex stuff isn't quite right
stipa has joined #u-boot
<sjg1> Tartarus: OK thank you. I will take a look and cover that stuff with a test somehow too
<sjg1> marex: I honestly don't know. We really need to find a way to fix the DT dependencies. Perhaps I was building something old?
<marex> sjg1: maybe , I tend to do git clean -fqdx before each test build
<sjg1> marex: Oh I think I lost the setlocalversion thing. What was that incantation again?
<marex> export SOURCE_DATE_EPOCH=0
<marex> echo foo > .scmversion
monstr has quit [Remote host closed the connection]
<sjg1> marex: OK I pushed to for-marel again. It looks like there was an fdtmap at the start of the image!
<sjg1> marex: Diff looks minimal now, as it did for me before: initial header, binman symbols and the fdt at the end
<marex> sjg1: I'll take a look a bit later. What was the problem ?
sng has quit [Ping timeout: 245 seconds]
sng has joined #u-boot
Adrian has quit [Ping timeout: 245 seconds]
pgreco_ has joined #u-boot
pgreco has quit [Ping timeout: 264 seconds]
mmu_man has quit [Ping timeout: 245 seconds]
<sjg1> marex: not sure it wilk work. I think I just find the number of steps confusing. The fdtmap at the start was definitely wrong, but also I had problems with scm version or rc version
sszy has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
sng has quit [Remote host closed the connection]
sng has joined #u-boot
mmu_man has joined #u-boot
vagrantc has joined #u-boot
jaganteki has quit [Quit: Client closed]
sng_ has joined #u-boot
sng has quit [Read error: Connection reset by peer]
<marex> sjg1: well if you hexdump flash.bin before/after, is it the same ?
<sjg1> I just wrote that above!
<marex> sjg1: are you sure you did clean build each time ?
* marex is reasonably sure he is triggering violent reflexes in sjg with this question :)
<sjg1> marex reasonably...it would be cleaer if I had a script
<marex> or a test case ?
ikarso has quit [Quit: Connection closed for inactivity]
goliath has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
<sjg1> marex: wll yes but that will come
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot
<apteryx> hello! I encountered the error "xhci-pci init cannot map PCI mem bar" when attempting to boot a Raspberry Pi 4 with U-Boot, *only* when a WaveShare 35B LCD module is connected (otherwise it boots fine). Any idea of things to look/try?
<marex> apteryx: diff control DT with/without
<marex> fdt addr $fdtcontroladdr ; fdt print
<marex> you can capture serial console output in both cases, and run diff on both outputs
<marex> search around pcie node
<apteryx> hm, I don't have serial access while the LCD is connected, so don't know how to input these commands
<apteryx> I tried a USB keyboard but it doesn't seem to work at this stage
jaganteki has joined #u-boot
<apteryx> probably because of that error ^^
<marex> apteryx: add serial console :)
ldevulder has quit [Quit: Leaving]
grgy has joined #u-boot
<apteryx> it's a rpi 4 and the serial console is exposed via pins shadowed by the LCD connector :-/
<apteryx> but I think I may have blown the LCD
<apteryx> by hot-connecting it... seems it doesn't work on the rpi3 either anymore (and it was before)
<apteryx> nevermind, it's still working, phew
rfried5 has joined #u-boot
camus1 has joined #u-boot
tafama has joined #u-boot
rburton_ has joined #u-boot
pavelow_ has joined #u-boot
JPEW_ has joined #u-boot
jsmolic_ has joined #u-boot
redbrain_ has joined #u-boot
mmu_man_ has joined #u-boot
eloy_ has joined #u-boot
vagrantc has quit [Quit: leaving]
goliath has quit [*.net *.split]
mmu_man has quit [*.net *.split]
camus has quit [*.net *.split]
redbrain has quit [*.net *.split]
apteryx has quit [*.net *.split]
tafa has quit [*.net *.split]
urja has quit [*.net *.split]
jsmolic has quit [*.net *.split]
pavelow has quit [*.net *.split]
eloy has quit [*.net *.split]
rburton has quit [*.net *.split]
rfried has quit [*.net *.split]
swiftgeek has quit [*.net *.split]
JPEW has quit [*.net *.split]
camus1 is now known as camus
rfried5 is now known as rfried
rburton_ is now known as rburton
frieder has quit [Remote host closed the connection]
vvn has quit [Ping timeout: 240 seconds]
paulbarker has quit [Quit: Connection closed for inactivity]
vvn has joined #u-boot
goliath has joined #u-boot
sng_ has quit [Read error: Connection reset by peer]
sng has joined #u-boot
swiftgeek has joined #u-boot
urja has joined #u-boot
apteryx has joined #u-boot
jaganteki has quit [Quit: Client closed]
sng has quit [Remote host closed the connection]
johang has joined #u-boot
JPEW_ is now known as JPEW
johang has quit [Quit: leaving]
johang has joined #u-boot
apteryx has quit [Ping timeout: 250 seconds]
pgreco_ has quit [Ping timeout: 240 seconds]
mmu_man_ has quit [Ping timeout: 245 seconds]
mmu_man has joined #u-boot
naoki has quit [Quit: naoki]
Wouter0100670440 has quit [Quit: Ping timeout (120 seconds)]
Wouter0100670440 has joined #u-boot
<NishanthMenon> Tartarus: following up from the last month's conversation on config fragments https://libera.irclog.whitequark.org/u-boot/2023-06-07 -> https://lore.kernel.org/all/20230713223455.bngcabgcebxqn6sr@prison/ I am not sure who in nvidia might be interested, but might be good to see if this is going in the right direction..
<marex> heh, @prison
<marex> NishanthMenon: fragments or even just ability to include common part of defconfig in another defconfig would be mighty useful
<Tartarus> Well, fragments work today
<Tartarus> And https://patchwork.ozlabs.org/project/uboot/patch/20230711212048.1340990-2-j-kacines@ti.com/ does what I asked someone to do (thanks!) of letting us put them in the board dir, rather than configs/ dir itself
vagrantc has joined #u-boot
Wouter0100670440 has quit [Quit: The Lounge - https://thelounge.chat]
Wouter0100670440 has joined #u-boot