umbramalison has quit [Quit: %So long and thanks for all the fish%]
umbramalison has joined #u-boot
LeSpocky has quit [Ping timeout: 268 seconds]
LeSpocky has joined #u-boot
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
vagrantc has quit [Quit: leaving]
<sjg1>
marex: I sent a patch with what I hope is a starting point for you
tlwoerner_ has joined #u-boot
tlwoerner has quit [Ping timeout: 244 seconds]
tlwoerner_ has quit [Ping timeout: 268 seconds]
akaWolf has quit [Ping timeout: 252 seconds]
akaWolf has joined #u-boot
LeSpocky has quit [Ping timeout: 240 seconds]
LeSpocky has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #u-boot
frieder has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
guillaume_g has joined #u-boot
redbrain has joined #u-boot
Forty-Bot has quit [Ping timeout: 245 seconds]
Forty-Bot has joined #u-boot
sszy has joined #u-boot
prabhakarlad has joined #u-boot
jagan has quit [Quit: Connection closed]
matthias_bgg has joined #u-boot
jclsn has joined #u-boot
<jclsn>
Is there any way to get support on device trees? I am becoming frustrated because nothing works
mmu_man has joined #u-boot
<hramrach>
'nothing works' is somewhat too general
<hramrach>
some things work for me, some don't
<marex>
hramrach: 'everything sucks'
<marex>
maybe asking an actual question would be a good starting point
<LeSpocky>
the correct answer to the actual question would be "yes". *scnr*
<hramrach>
yes, it's completely true, everything sucks. but gotta work with what's available.
<LeSpocky>
fwiw, when I started learning about dts I also struggled hard, it's a somewhat steep learning curve
<LeSpocky>
in u-boot it's even more complicated than in linux, because to conversion from old u-boot to dm and dts is still ongoing and not every driver supports it yet
<hramrach>
for me the DT is not so much of a problem. The problem is the stupid decisions that software makes supposedly based on the DT content that I fail to comprehend
<marex>
LeSpocky: yeah, DM, awful ...
<marex>
hramrach: ^
<hramrach>
I already asked my question, and di not get an answer, just commenting on the 'nothing works' part
<hramrach>
I can attest that some wthings work and some don't
<marex>
hramrach: this channel isn't free of charge 24h tech support
<marex>
hramrach: sometimes you need to dig into the code yourself
<marex>
hramrach: the people here can provide pointers, but dont expect an immediate solution, that doesn't always happen
<hramrach>
sure, that happens that nobody knows the answer
<hramrach>
and when the project becomes so cmplex that it happens too often the development focus moves elsewhere
<marex>
hramrach: drivers/core got like 15 patches each in last two releases, does it look like focus moved elsewhere ?
<hramrach>
no, the potential problem I see is that there are very few people who actually understand how drivers/core works, and u-boot as a project dealing with actual hardware depends on contributions from large number of occasional contributors to keep the hardware working and remain relevant, and sometimes understanding of the driver model is required for the contribution to happen
<marex>
hramrach: how it works isn't really hard to figure out if you sprinkle printf()s around and sit on it for a bit
<hramrach>
tried, no idea how it works
<hramrach>
and I should not need to sprinke printks, it should be read this, this is how it works, sprinkle printks if it's does not do what it says shere
<hramrach>
yeah, saw something like that. It says the same thing I hear all the time 'when a driver needs to be used it is probed'. But how is 'needs to be used' determioned? IF you are writing some code can that code is what 'needs to use' the driver, and in what case? Should you then probe it? How?
monstr has joined #u-boot
rvalue has quit [Read error: Connection reset by peer]
<paulbarker>
hramrach: device_probe() is a no-op if the device has already been probed, so it should be safe to call where you need it. I had to figure this out and handle it for SPI devices in the patches I sent today
rvalue has joined #u-boot
elafon has quit [Remote host closed the connection]
elafon has joined #u-boot
mmu_man has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
lucascastro has joined #u-boot
<sjg1>
LeSpocky: I have this:
<sjg1>
[toolchain]
<sjg1>
sandbox = /
<sjg1>
hramrach: Do we need to manually bind the sysreset driver, or could it be in the DT and done automatically?
<sjg1>
hramrach: If you need a device use a 'get' function, like uclass_get_device_by_seq() and it will be probed automatically. There is lots of docs in the uclass.h and device.h headers
<sjg1>
hramrach: " * The device is probed to activate it ready for use."
<sjg1>
marex: Did you see my example csf patch?
mmu_man has quit [Ping timeout: 252 seconds]
mmu_man has joined #u-boot
<hramrach>
sjg1: many sysreset drivers are manually bound like this
<hramrach>
it's basically that the pmic is a MFD, it has nodes for regulators, and disabling writing something somewhere to the PMIC also resets the system. And it needs not be specified in the DT because it's inherent function of the pmic - every time you have this pmic it does it
<hramrach>
so basicaly it should NOT be bound to the DT node but just binding it as pmich child without a node does not change anything, the problem is elsewhere
prabhakarlad has quit [Quit: Client closed]
<hramrach>
hm, I ca nsee how this happens - the proble of the pmic fails (for unknown reason), and when the sysreset is child of pmic it cannot be probed either so its probe fails, which in turn causes uclass_first_device to return null, and sysreset_walk cannot get to the other pmic because it's the second one, and the iteration fails on the first one
<hramrach>
I will try to patch it, and see if that helps
<hramrach>
thanks for help
lucascastro has quit [Ping timeout: 268 seconds]
<sjg1>
hramrach: Er, yes, I understand what a PMIC is. But the sysreset should be in the DT, really. The regulators are. This is just something that Linux decides to do and it causes us a lot of problems in U-Boot. So my suggestion is to fix the binding and send it upstream to Linux and watch the fireworks
<LeSpocky>
sjg1: I'll save that for later, thanks
<sjg1>
hramrach: But for the sysreset_walk() we should probably continue after error
<rfs613>
hramrach: I had a similar problem trying to use syscon-sysrest. The issue was the driver providing syscon needed to probe first, but I had a circular loop, as the same driver was also "providing" syscon.
<rfs613>
I solved it by moving the regs = <...> into its own node for syscon, though I suspect this may ruffle feathers with the devicetree maintainers
<hramrach>
sgj why should it be in the DT? You have the pmic, you can reset. The regulators are in the DT because they have parameters to set, and because you need to refer to them for dependencies of other devices. nothing like that for sysreset
<sjg1>
hramrach: The DT is there to provide device info...doing things in an ad-hoc manner makes the devices harder to discover and reduces the benefit of DT. E.g. if I want to use a GPIO to reset and not the pmic, I need to change the PMIC driver to remove the binding of the sysreset there :-( In general we should not be creating devices in an ad-hoc manner.
<hramrach>
sjg1: the DT is there to provide device info *that cannot be probed*. You say that you have rk808 in the DT it means you can reset (or power off in this case, really)
<sjg1>
hramrach: No, the DT is not there just for things that cannot be probed. Where did you get that from?
<sjg1>
hramrach: There might be multiple things in the system that can do the reset. Just because the PMIC does a reset doesn't mean that is what the system will use
<hramrach>
A |spec|-compliant devicetree describes device information in a system that cannot necessarily be dynamically detected by a client program.
<sjg1>
hramrach: That does not support what you are saying
<sjg1>
hramrach: The LTO thing is silly...the Linux rule seems to be that if we might need it in the DT (to reference it from elsewhere) we put it in there, but if someone decided we might not, then we don't. That is not the way DT bindings should be done. In practice they are Linux-specific and this is not right (TM)
<hramrach>
so the device tree says you have a rk808 chip - what else do you need to know?
<sjg1>
hramrach: You've just say that you need to know what the regulators are used for, right?
<sjg1>
hramrach: You need to know what the sysreset is used for too (or if it isn't actually used)
<broonie>
LTO?
<sjg1>
broonie: LDO
<hramrach>
sjg1: you would have to know if the sysreset is used in case the rk808 was also used in non-standard configurations in which you cannot powwewr off the main SoC with it
<sjg1>
hramrach: Are you talking about 'enum sysreset_t' ? We could certainly add a DT property to specify what it can reset
<hramrach>
while it's not impossible it's pretty unlikely as well
<hramrach>
no, the sysreset_t is fixed, and has no meaning outside of u-boot
<hramrach>
there is only the potential that you could desolder a rk808 form a rockchip board and connect it over whatever bus to some system at random, and then it would not provide the powweroff option for the system
<hramrach>
if it would even power on without connecting to the SoC it was tailored for
<rfs613>
hramrach: before DT, there were thousands of board-specific files (.c code) which often were identical apart from things like the physical base address of a device, or the IRQ number it used, etc.
<hramrach>
yes, I understand that. What we are talking about here that a number of boardss has a pmic which is tailored to be paired with a specific SoC family, and the driver assumes that you can send some command to the pmic to power off the system
<hramrach>
While it may be technically possible to desolder the pmic, and use it on some different system for something other than powering the SoC it is not very likely
<rfs613>
can the same SoC be used without the PMIC?
<hramrach>
not sure actually
* broonie
doesn't get what the thing with LDOs ishere.
<rfs613>
in general if they are separate devices, it's hard to predict how they will be used in the future
<broonie>
You do get people trying to displace the default PMIC vendor for use with SoCs, though it's typically a very tough sell since if your PMIC doesn't work the board is scrap.
<paulbarker>
In the current market, using alternative PMICs is definitely going to happen
<hramrach>
here the pmic and the SoC is made by the same company so there is not much point, and using it separately without the SoC does not make much sense even if it were possible because you can get general purpose pmics easier and cheaper
<hramrach>
Given that the poweroff is assumed for quite a while already, and adding DT ssupport to the driver would mean that people with old DT without the new node will not be able to power off it will be a tough sell without some devices in the wild using the regulator in a non-standard way
<sjg1>
hramrach: But this makes no sense, really. You seem to be saying that if the PMIC is tightly coupled to the SoC (quite common) then the sysreset must not be in the DT because it is always present. But if another PMIC is used, or where the reset comes from elsewhere (so that we can reset more than just the CPU), how do we model that? We have to change the code
<sjg1>
broonie: LDO is a regulator and PMICs typically support multiple LDOs and these are in the DT
<hramrach>
sjg1: if another pmic is used the driver won't run
<broonie>
sjg1: I know what an LDO is and that it is in DT. What is the issue with LDOs?
Xeroine has joined #u-boot
<sjg1>
"no, the sysreset_t is fixed, and has no meaning outside of u-boot" - I mean there could be a binding to control what the sysreset is for. E.g. you cannot just reset the SoC on a secure system, you must reset the TPM too
<sjg1>
hramrach: If another PMIC Is used *as well*
<sjg1>
broonie: No issue, just that they are in the DT binding, and IMO sysreset should be too
<hramrach>
sure, then you have much more complex problem than just stating if there is a sysreset
<hramrach>
probably something similar to powerseq or how is the binding called
<hramrach>
and then you would need the resets in the DT to express the reset sequence
<hramrach>
but for the pmic sysreset is somewhat of a misnomer - it actually powers off the SoC which in u-boot is handled by sysreset, and then you donot have problem with secure boot because it just powers off everything
<hramrach>
(unless you use multiple pmics and do not chain them reasonably)
prabhakarlad has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
<hramrach>
sjg1: I am not saying that the sysreset must not be in the DT - I am saying that from the available information it sounds redundant, was not added to start with which sounds reasonable, and changing that now would break things so there should be a really good reason for the change
<hramrach>
if you had a really bad case of chained pmics you would need a powerseq for powering off the system, and with the poweroff capability of the pmic not expressed in the DT you would not have a way to express the sequence either, there's that
<sjg1>
hramrach: re sysreset, see cold and warm resets. E.g. Chromebooks support both. The first resets the main PMIC / power supply, the second resets just the SoC, or perhaps its PMIC too
<sjg1>
hramrach: This is really simple to solve by putting it in the DT, as we do with other PMIC functions like LTO and GPIOs. I don't think the original decision is defensible, particularly in hindsight. We should really fix the binding and stop worrying about it
<sjg1>
hramrach: How on earth can you implement reset in SPL when of-platdata is being used and device_bind() is not available?
<hramrach>
no idea about that. In fact I woder what it be even used for
<hramrach>
sjg1: well, I don't define the DT bindings. I think there are reasons to add the reset and poweroff capabilities to DT as discussed above, and it could be summarized and new binding proposed. It will be problematic to change the bindings for existing pmics but for new bindings it can be done right from the start.
matthias_bgg has quit [Ping timeout: 245 seconds]
Guest4494 has joined #u-boot
akaWolf has quit [Ping timeout: 268 seconds]
matthias_bgg has joined #u-boot
akaWolf has joined #u-boot
<sjg1>
hramrach: of-platdata is a way to reduce SPL size by compiling in the devices and DT into the C code. It is used a lot on Rockchip, for example
<sjg1>
hramrach: Re PMIC bindings and 'hidden-from-DT' devices in general, I will have a crack at writing something up
mmu_man has quit [Ping timeout: 240 seconds]
<marex>
sjg1: I did
prabhakarlad has quit [Quit: Client closed]
frieder has quit [Remote host closed the connection]
<hramrach>
it is not clear why it was not visible before but it may get overwritten by something with a single CR, and it is not clear why it happens, either
<hramrach>
nonetheless, with the uclass iteration fixed no other random things fail, in particular it is still possible to reset the board because the other syssreset keeps working
Guest4494 has quit [Quit: Client closed]
prabhakarlad has joined #u-boot
<sjg1>
marex: hramrach: good
<sjg1>
Are people attending osfc this year? What about ELCE?
frieder has joined #u-boot
kabel has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]