umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
LeSpocky has quit [Ping timeout: 265 seconds]
LeSpocky has joined #u-boot
rabbi[11] has quit [Ping timeout: 252 seconds]
thopiekar_ has quit [Ping timeout: 252 seconds]
thopiekar has joined #u-boot
scientes has joined #u-boot
scientes has quit [Ping timeout: 252 seconds]
<sjg1>
hanetzer: You're welcome (which feedback?)
<hanetzer>
sjg1: tbh mostly making patman/checkpatch not bitch at me, and a bit about the idea of bugging linux-rockchip a bit. I'm certain the uart2sd thing should work, I just gotta find the right bit to fiddle.
<LeSpocky>
sjg1: I'm going to inspect the stacktrace now, it's of course not strcmp() that's faulty, but some function call above
<LeSpocky>
sjg1: stacktrace at https://hastebin.com/rujexubede.properties … to me it looks like those driver list is built at link time, and the entry in question has no name
hanetzer has quit [Ping timeout: 252 seconds]
hanetzer has joined #u-boot
monstr has joined #u-boot
sszy has joined #u-boot
mncheck has joined #u-boot
mckoan|away is now known as mckoan
guillaume_g has joined #u-boot
tnovotny has joined #u-boot
matthias_bgg has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
apritzel_ has joined #u-boot
ladis has joined #u-boot
mckoan is now known as mckoan|away
monstr has quit [Remote host closed the connection]
mmu_man has joined #u-boot
mncheck has quit [Write error: Connection reset by peer]
<milkylainen>
Caution! Your devices Erase group is 0x400
<milkylainen>
The erase range would be change to 0x0~0x7ff
<milkylainen>
1025 blocks erased: OK
<milkylainen>
Erasing more than the erasegroup on an emmc hwpartition? (bootX)
naoki has quit [Remote host closed the connection]
naoki has joined #u-boot
camus has quit [Quit: camus]
mmu_man has quit [Ping timeout: 250 seconds]
<sjg1>
hanetzer: Ah OK good
mmu_man has joined #u-boot
dormito has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
<sjg1>
LeSpocky: what commit is this and is it the sandbox build?
<sjg1>
LeSpocky: It should not be using platdata here. Possibly there is a problem with scmi
<dormito>
I've noticed that for at least the lx2160a-cex7 (which is not in mainline) u-boot seems to make several changes to the dtb handeed to the kernel. What I'd like to know is: is there a mechanism to have those changes noted somewhere, like a dt overlay (specifically I'd like to apply the same changes to another dtb, so that I can kexec)?
<LeSpocky>
sjg1: that was todays master, I built with sandbox_defconfig on i386 … same commit runs find when built on amd64
<LeSpocky>
and maybe I should enable debug logging
mmu_man has joined #u-boot
<sjg1>
LeSpocky: yes, it seems quite wonky. I actually wonder whether it is an alignment thing. You could print out the driver info records in bind_drivers_pass(). But the one you have seems corrupt as there is no UCLASS_ROOT device with that child_post_remove value, nor is of_to_plat a valid value
<sjg1>
LeSpocky: what distro are you using?
Gravis has quit [Ping timeout: 252 seconds]
<LeSpocky>
this is Debian GNU/Linux 11 (bullseye) on both hosts I used today, as I said, one is arch i386, the other arch amd64
<LeSpocky>
host gcc is version 10.2.1
matthias_bgg has quit [Read error: Connection reset by peer]
Gravis has joined #u-boot
torez has joined #u-boot
matthias_bgg has joined #u-boot
jagan has joined #u-boot
monstr has quit [Remote host closed the connection]
jagan has quit [Ping timeout: 244 seconds]
<Forty-Bot>
dormito: afaik no
<Forty-Bot>
you can do a diff of the device tree before/after
<Forty-Bot>
but IMO most of the modifications done should just be in the device tree in the first place
<dormito>
Forty-Bot: I agree. however I'm especially noting u-boot upstream commit 18c62dfeb0, which seems to modify the compatible for some PCIe controllers (for lx2160a chips). I had assumed that behavior wasn't unique (and thus asked for a general solution).
<dormito>
actually, I dont think that comit directly modifies the compatible, it change change the way/circumstances in which its done.
guillaume_g has quit [Quit: Konversation terminated!]
Gravis has quit [Ping timeout: 244 seconds]
hanetzer has quit [Ping timeout: 244 seconds]
Gravis has joined #u-boot
hanetzer has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
Gravis has quit [Ping timeout: 265 seconds]
Gravis has joined #u-boot
jclsn has joined #u-boot
jclsn has quit [Client Quit]
jclsn has joined #u-boot
jclsn has quit [Client Quit]
jclsn has joined #u-boot
<dormito>
poking at it futher, it seems u-boot also patchs up some/all iommu-map properties (upstream linux dts's seem to expect this).
mmu_man has joined #u-boot
<cambrian_invader>
yeah, IMO the iommu stuff should be in the base dt
<cambrian_invader>
but I think it's done this way because the IOMUU node isn't upstream yet
<dormito>
can the iommu stuff be in the dt? ATM, I can freely modify the base dt, and fix it that was would be great, but if those values are modified by u-boot at boot time, I can't know apriori. But if u-boot is just stuffing in fixed vlaues, that's easy
Gravis has quit [Ping timeout: 265 seconds]
mmu_man has quit [Ping timeout: 268 seconds]
<cambrian_invader>
I believe it just stuffs in fixed values
<cambrian_invader>
depending on the soc
<dormito>
cambrian_invader: thanks, I'll look into that then.
vagrantc has joined #u-boot
lucascastro has joined #u-boot
lucascastro has quit [Ping timeout: 246 seconds]
minimal has joined #u-boot
persmule has quit [Ping timeout: 258 seconds]
persmule has joined #u-boot
apritzel_ has quit [Ping timeout: 250 seconds]
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
<sjg1>
Tartarus: let me know if you want to talk about the SPL thing here
rabbi[11] has joined #u-boot
mmu_man has joined #u-boot
persmule has quit [Ping timeout: 258 seconds]
vagrantc has quit [Quit: leaving]
persmule has joined #u-boot
<Tartarus>
sjg1: At the high level, I'm concerned about making new behavior in this area either default or that it could be bypassed when it is intentionally used
<sjg1>
Do you mean that people might add two drivers for the same type without knowing?
<Tartarus>
Well, you're noting the enum in spl.h that says what we can find the next stage on
<Tartarus>
I want to be sure we don't make it easy for someone to bypass that if we load SPL from NAND we load U-Boot from NAND and instead load U-Boot (or some other malicious payload) from SD card instead
vagrantc has joined #u-boot
<sjg1>
I don't really understand how that changes here. If someone adds a new loader with the same type and a higher priority, it will override the first loader.
<sjg1>
Tartarus: that's how it works now...
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
<Tartarus>
I guess I don't see the case where we wouldn't have a single loader, for a given boot device
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
<sjg1>
Even for the board-specific method?
<Tartarus>
Since I think we're at a bit cross-purpose, what in-tree example do you mean there?
<Tartarus>
When I was saying load from X now do Y I was thinking of either sunxi or rockchip that some special punt-to-ROM-real-quick mode
<sjg1>
There is no in-tree example. We only have a single loader for each type at present, unless there is a bug somewhere. Basically the 'problem' with the code at present is that it selects the highest-priority loader for each type and tries that. Any lower-priority loaders of that type are ignored
<Tartarus>
Right, but I see that as a feature
<sjg1>
OK, then we really don't need the prirority
<Tartarus>
Yes, I think that might have been added either with something future in mind?
<Tartarus>
pre linked list there wasn't priority
macromorgan has quit [Read error: Connection reset by peer]
macromorgan_ has joined #u-boot
<sjg1>
Tartarus: that's right. I would like to unify the types across all architectures. It seems odd to have BOOT_DEVICE_BOARD1, BOOT_DEVICE_BOARD2, etc.
<sjg1>
Essentially you are saying that someone might add another thing to the code with a higher priority. But that is already possible, right?
<Tartarus>
BOOT_DEVICE_BOARD is perhaps the funny one
<Tartarus>
Since I think it showed up before a number of other SoCs came in and expanded the list of BOOT_DEVICE_xxxx options
<Tartarus>
sunxi that means FEL (one of the special cases I was thinking about) and imx it means the special USB loader method
<Tartarus>
riscv/mips just enum it, to keep things compiling? or copy/paste? not sure
umbramalison has quit [Quit: %So long and thanks for all the fish%]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
GNUtoo has quit [Ping timeout: 258 seconds]
umbramalison has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #u-boot
GNUtoo has joined #u-boot
<sjg1>
They are not consistent across archs. Ideally I would move this to DT so we can point to actual devices and use common code. See spl_mmc.c for example. Ick! But anyway that is out of scope of my patch. I could just do BOOT_DEVICE_BOARD1 and BOOT_DEVICE_BOARD2 :-)
behanw has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
persmule has quit [Remote host closed the connection]
macromorgan has quit [Read error: Connection reset by peer]
persmule has joined #u-boot
macromorgan has joined #u-boot
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #u-boot
macromorgan has quit [Quit: Leaving]
Gravis has joined #u-boot
torez has quit [Quit: torez]
<Tartarus>
Well, neither case of BOOT_DEVICE_BOARD should be "BOARD", at this point
<Tartarus>
And it can't come from DT
<Tartarus>
It's a runtime thing from a pre-DT world/stage, ie how the switches or fuses on the board are set
brassado has joined #u-boot
brassado is now known as sam_sepi0l
minimal has quit [Read error: Connection reset by peer]