xypron changed the topic of #u-boot to: #u-boot SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot 2023.01 / Merge Window is OPEN, -next is CLOSED / Release v2023.01 is scheduled for 2023-01-09 / Channel archives at https://libera.irclog.whitequark.org/u-boot
mmu_man has quit [Ping timeout: 252 seconds]
WoC has joined #u-boot
cousteau has joined #u-boot
<cousteau> Sup
jybz has quit [Excess Flood]
jybz has joined #u-boot
<cousteau> Any recommendation for a tftp server for Windows? (asking here mostly because I'm gonna use it with u-boot, and I assume several people here will have dealt with that before)
<cousteau> Top Google result is SolarWinds, which I've tried and is severely limited...
WoC has quit [Remote host closed the connection]
WoC has joined #u-boot
WoC has quit [Ping timeout: 260 seconds]
WoC has joined #u-boot
<cousteau> https://sourceforge.net/projects/tftp-server/ sounds interesting. "Can specify Server Interfaces and Ports", just what I needed!
<Forty-Bot> marex: I think it's good if you update the commit messages
<Forty-Bot> sorry I meant to follow up to your email
<Forty-Bot> if you are going to manually implement the clock_get stuff, you should explain why
ElementW has quit [Read error: Software caused connection abort]
ElementW has joined #u-boot
<Forty-Bot> and IMO you should drop patch 2
<Forty-Bot> even if it's "free" we don't want to encourage it
<marex> Forty-Bot: the commit messages are from Linux, and dropping patch 2 would make the backporting difficult, besides, I think we should keep the property
<Forty-Bot> I mean for the first patch
<marex> if you want to flag it as deprecated, do so in the DT schema
<Forty-Bot> it's already flagged as deprecated in dt schema
<Forty-Bot> if it wasn't used before, there's nothing to support
<marex> well, then it is documented and discouraged
<Forty-Bot> so we don't need to add it
<Forty-Bot> because anything we add has to stay for a long time
<Forty-Bot> which make it hard to remove it
<Forty-Bot> we should have used the second style in the first place, and now we have to wait for a stable release to remove it from the kernel
<Forty-Bot> if you add it here, we will have to wait a while before it gets removed
<marex> Forty-Bot: was it actually removed from the kernel ?
<marex> Forty-Bot: if so, we backport that patch too
<Forty-Bot> no, but when we get a stable release I will send a patch to do so
<marex> then send the matching patch to U-Boot as well, and problem solved ?
<Forty-Bot> we shouldn't add something which is 1. deprecated, and 2. will be removed
<Forty-Bot> it's not even necessary for support
<Forty-Bot> all you have to do is keep the second patch but remove the part which reads the property
<marex> which means modify someone else's patch, which I want to avoid
<Forty-Bot> I give you permission ;)
<marex> you're not the author though
<Forty-Bot> so?
<Forty-Bot> it's a different codebase
<Forty-Bot> and it's all GPL anyway
<marex> Forty-Bot: I think you are now conflating licensing and authorship
thopiekar has quit [Ping timeout: 260 seconds]
<Forty-Bot> it doesn't matter if you use the patch verbatim
thopiekar_ has joined #u-boot
<Forty-Bot> just put a note in the commit message "Adapted from Linux commit foo"
<marex> sorry, no, that has to be separate patch
WoC has quit [Ping timeout: 248 seconds]
WoC has joined #u-boot
samueldr has quit [Read error: Software caused connection abort]
samueldr has joined #u-boot
<Forty-Bot> ok, then make it patch 3 :P
* marex goes bonkers from all the outstanding patches 3-/
<marex> Forty-Bot: v2 out
* Forty-Bot should review some clock patches
<marex> Forty-Bot: linux ?
<Forty-Bot> U-Boot
<marex> fun
<Tartarus> Because I missed your feedback, sorry.
<Forty-Bot> >.>
<Forty-Bot> I suppose I will need to send a patch then
<marex> Forty-Bot: btw ABX80X is really one of the worst compatibles
<marex> Forty-Bot: compatible should be specific
<Forty-Bot> yeah
<Forty-Bot> but it's nice as a fallback
<Forty-Bot> e.g. compatibles = "ab0810", "abx80x";
<Forty-Bot> which is kinda what compatibles were intended to be
<marex> Forty-Bot: should be "foo,newchip10", "foo,oldchip01";
<marex> Forty-Bot: and "foo,newchip20", "foo,oldchip01";
<Forty-Bot> maybe, but often it's not clear what the oldchip is
cousteau has quit [Remote host closed the connection]
thopiekar_ has quit [Ping timeout: 248 seconds]
thopiekar has joined #u-boot
hanetzer has quit [Ping timeout: 248 seconds]
hanetzer has joined #u-boot
<marex> Forty-Bot: ToS chip
<marex> Forty-Bot: the oldest one
<Forty-Bot> again, not always clear
<marex> Forty-Bot: example ?
<Forty-Bot> which of the aquantia phys is the oldest
<marex> Forty-Bot: is that actually relevant, since the PHY is either auto-detected by ID registers 2/3 or specified by ethernet-phy-idNNNN.MMMM ?
<Forty-Bot> not in that case, but it's a good example
<marex> Forty-Bot: I disagree, since ... ^
<Forty-Bot> well, imagine if it wasn't that way :P
<marex> pick one which is actually showing the problem, please
<Forty-Bot> actually, most of the phy variants use the same functions
<marex> Forty-Bot: my imagination (ugh ... that's not a good example either) is rather limited
<Forty-Bot> but of course you can make the same argument about traditional compatibles
<Forty-Bot> and of course if you are writing the device tree you could always just pick a compatible manually...
<Forty-Bot> *shrug*
<marex> Forty-Bot: my point is, it is likely not a good idea to define DT compatible which does not match any existing hardware
<Forty-Bot> yeah
<Forty-Bot> I see your point
<marex> like abx80x ;-)
hanetzer1 has joined #u-boot
hanetzer has quit [Ping timeout: 260 seconds]
jclsn has quit [Ping timeout: 252 seconds]
WoC has quit [Remote host closed the connection]
WoC has joined #u-boot
persmule has joined #u-boot
WoC` has joined #u-boot
WoC has quit [Ping timeout: 260 seconds]
WoC` is now known as WoC
jevinskie[m] has quit [Read error: Software caused connection abort]
jevinskie[m] has joined #u-boot
ikarso has joined #u-boot
cJ has quit [Ping timeout: 248 seconds]
WoC` has joined #u-boot
WoC has quit [Ping timeout: 260 seconds]
cJ has joined #u-boot
mncheck has joined #u-boot
<apalos> xypron: back to that menu patchset for EFI
<apalos> I asked Kojima-san to remove the 'delete' option for keys
<apalos> The idea behind the menu, is that you can disable the u-boot console which is a security threat
<apalos> So I don't want to allow people deleting keys. I told him to remove the 'delete' option
<apalos> So the only way you delete a key is provide an authenticated empty variable
<apalos> and then update the variable with the new values
<apalos> It might be cumbersome but
<apalos> 1. that's why DBX exists
<apalos> 2. I don't see any other options for doing this securely
<apalos> EDK2 allows you to delete the PK without any authentication, but EDK2 runs on servers in protected data-centers
<apalos> not in the middle of nowhere (and everyone can get physical access)
<apalos> and the 'delete' would only ever work if you didnt register a KEK to begin with
<apalos> So I don't see why we should carry that extra code
jclsn has joined #u-boot
hanetzer1 has quit [Ping timeout: 252 seconds]
sszy has joined #u-boot
mckoan|away is now known as mckoan
<xypron> apalos: ok for me
sughosh has joined #u-boot
apritzel has joined #u-boot
cousteau has joined #u-boot
cJ has quit [Ping timeout: 260 seconds]
cJ has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
hanetzer1 has joined #u-boot
frieder has joined #u-boot
hanetzer1 is now known as hanetzer
mmu_man has joined #u-boot
apritzel_ has joined #u-boot
apritzel has quit [Read error: Connection reset by peer]
dlg has quit [Ping timeout: 252 seconds]
dlg has joined #u-boot
mps has quit [Ping timeout: 246 seconds]
cousteau has quit [Remote host closed the connection]
matthias_bgg has joined #u-boot
sughosh has quit [Remote host closed the connection]
sbach has quit [Read error: Connection reset by peer]
mps has joined #u-boot
sbach has joined #u-boot
cousteau has joined #u-boot
cousteau has quit [Quit: Quit]
xroumegue has joined #u-boot
<Tartarus> Forty-Bot: again, sorry about that. In the future please feel free to move stuff to Changes Requested in patchwork when you provide feedback. My guess is that I saw it had a reviewed by tag and didn't scroll all the way down to make sure there wasn't further feedback, when I was checking things over.
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
<Forty-Bot> Tartarus: yeah, that's a good idea
<Forty-Bot> that patch *really* needed some work
torez has joined #u-boot
torez has quit [Quit: torez]
apritzel__ has joined #u-boot
apritzel_ has quit [Ping timeout: 260 seconds]
WoC` is now known as WoC
matthias_bgg has quit [Quit: Leaving]
ikarso has quit [Quit: Connection closed for inactivity]
matthias_bgg has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
akaWolf has joined #u-boot
akaWolf has quit [Ping timeout: 252 seconds]
persmule has quit [Remote host closed the connection]
sszy has quit [Ping timeout: 252 seconds]
persmule has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
mckoan is now known as mckoan|away
vagrantc has joined #u-boot
frieder has quit [Remote host closed the connection]
mmu_man has joined #u-boot
WoC` has joined #u-boot
akaWolf has joined #u-boot
WoC has quit [Ping timeout: 260 seconds]
akaWolf has quit [Ping timeout: 260 seconds]
akaWolf has joined #u-boot
prabhakarlad has joined #u-boot
torez has joined #u-boot
akaWolf has quit [Ping timeout: 248 seconds]
akaWolf has joined #u-boot
PhoenixMage has quit [Ping timeout: 272 seconds]
PhoenixMage has joined #u-boot
apritzel__ has quit [Ping timeout: 260 seconds]
akaWolf has quit [Ping timeout: 246 seconds]
<paulbarker> I'm making some progress fixing SPI boot on the am335x when CONFIG_SPL_OF_CONTROL=y, I've now hit a snag
<paulbarker> I've marked the relevant nodes in the device tree with `u-boot,dm-pre-reloc` so they are preserved for the SPL
<paulbarker> However, the spi0 node is not bound during `dm_init_and_scan()`
<paulbarker> The spi0 node is contained within a `target-module` node which has `compatible = "ti,sysc-omap2", "ti,sysc"`, so it needs the ti-sysc bus driver
<paulbarker> I've got CONFIG_TI_SYSC=y, so this driver is built for the main u-boot binary, but there is no corresponding option for the SPL, so this driver isn't present in the SPL
akaWolf has joined #u-boot
<paulbarker> So the target-module node (see https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/am33xx-l4.dtsi#L952) is not enumerated and so the spi0 node is not found
<paulbarker> The same issue occurs for the uart0 node, however as it is referenced as `/chosen/stdout-path`, it is bound anyway at https://github.com/u-boot/u-boot/blob/master/drivers/serial/serial-uclass.c#L67
<paulbarker> But there's no equivalent for the spi driver, or I guess for any other block driver
<Tartarus> So no symbol gating going in to drivers/bus/ for SPL/TPL
<paulbarker> Tartarus: None that I can see
<Tartarus> Worth starting by moving the line in drivers/Makefile out of the SPL/TPL check and seeing (a) if the world builds in CI and (b) a before/after size test if so
<paulbarker> I've confirmed that after building I have `drivers/bus/ti-sysc.o` but no equivalent `spl/drivers/bus/ti-sysc.o`
<Tartarus> It's just CONFIG_TI_PWMSS CONFIG_TI_SYSC and CONFIG_UNIPHIER_SYSTEM_BUS so it might be fine
___nick___ has joined #u-boot
<paulbarker> Tartarus: So would you say the solution is to build the ti-sysc driver in SPL so that the device tree node is enumerated properly?
<Tartarus> Yes
<paulbarker> Tartarus: Ok, that lets me get further. I now have a device_probe failure, but it's progress
<Tartarus> Possibly other stuff that needs to be compiled in SPL too, but is not.
<paulbarker> pinctrl is my first guess, going to continue working through it
<paulbarker> This is about step 4 of fix one issue and see what the next failure is
<paulbarker> To upstream the change so that the ti-sysc can be compiled into SPL - do we want to always compile the bus drivers into SPL if their main config option is set? Or define new options like CONFIG_SPL_TI_SYSC?
<paulbarker> New options would let us tightly control SPL/TPL code size
<paulbarker> They're not huge drivers, but at least on the am335x I know I'm close to the limit of what will fit in the 64k SRAM available for the SPL
<Tartarus> Well, Roger had to add SPL_MEMORY to control drivers/memory recently
<Tartarus> (and added it in scripts/Makefile.spl)
<Tartarus> Similar for SPL_BUS and still using CONFIG_TI_SYSC might be the easy first pass
<Tartarus> Of course SPL_BUS is not a great symbol name.
<Tartarus> And I'm honestly not sure, but a world build before/after would be the way to check, what the fall out of just always doing drivers/bus/ when their symbol is enabled
<Tartarus> As it seems pretty likely it's needed
<Tartarus> It's just the uniphier case I don't have a good gut feel on
matthias_bgg has quit [Quit: Leaving]
<paulbarker> Tartarus: Understood, I'll try a world build with `obj-y += bus/` moved out of the SPL conditional once I've got this board booting
marc1 has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Ping timeout: 260 seconds]
marc1 has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
akaWolf has quit [Ping timeout: 248 seconds]
mmu_man has joined #u-boot
akaWolf has joined #u-boot
___nick___ has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
prabhakarlad has joined #u-boot
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
mmu_man has quit [Ping timeout: 260 seconds]
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #u-boot
<paulbarker> It's alive! It needed the ti_sysc driver enabling, CONFIG_SPL_OF_TRANSLATE=y, CONFIG_SPL_CLK=y, CONFIG_CLK_TI_CTRL=y and appropriate `u-boot,dm-pre-reloc` properties adding to the device tree
<paulbarker> Tomorrow I'll try to clean up those changes and prep for upstreaming
mmu_man has joined #u-boot
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
akaWolf has quit [Ping timeout: 260 seconds]
<Tartarus> Great
___nick___ has quit [Ping timeout: 260 seconds]
___nick___ has joined #u-boot
prabhakarlad has joined #u-boot
akaWolf has joined #u-boot
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #u-boot
akaWolf has quit [Ping timeout: 260 seconds]
akaWolf has joined #u-boot
___nick___ has quit [Ping timeout: 248 seconds]
torez has quit [Quit: torez]
guillaume_g has quit [Quit: Konversation terminated!]
akaWolf has quit [Read error: Connection reset by peer]
akaWolf has joined #u-boot
akaWolf has quit [Ping timeout: 246 seconds]
mmu_man has quit [Ping timeout: 260 seconds]
akaWolf has joined #u-boot
umbramalison_alt has quit [Quit: %So long and thanks for all the fish%]
mmu_man has joined #u-boot
umbramalison has joined #u-boot
mncheck has quit [Ping timeout: 252 seconds]