<Tartarus>
There was a suggestion of BOARD as well recently, iirc, but it broke a few platforms
<shadows>
how do I view output from Makefile "$(warning ...)" ? does not seem to appear with Y=1 KBUILD_VERBOSE=1
<shadows>
BOARD seems redundant in practice when OF_UPSTREAM is in use
<shadows>
each board enters the U-Boot board target's defconfig as part of CONFIG_OF_LIST and each of those is being looked after for a -u-boot.dsti include
<shadows>
or whatever it is without the typos
<shadows>
Tartarus: particularly I'm too daft to figure out what is the meaning of scripts/Makefile.lib line 200:
<shadows>
I'm looking for a human language description of it to toss into the commit message so I can explain where in the ordering my patch adds SYS_CONFIG_NAME
flyback has quit [Quit: Leaving]
flyback has joined #u-boot
<shadows>
DEVICE_TREE_DEBUG=1 maybe? hmm
broonie has quit [Server closed connection]
broonie has joined #u-boot
<shadows>
still don't know what the purpose of that first bit of wizardry is in the search order
<shadows>
what is 'arch/riscv/dts/-u-boot.dtsi' ? I'm going to describe it in the commit message generically as 'dtsi location' in the search order, but what is that for and is there a better description
clamor has joined #u-boot
<shadows>
Tartarus: patch sent to the list. I quickly searched what existing U-Boot board targets would be affected, all are already '#include "u-boot.dtsi"' or the name is already being found and used higher up on the search order than what I'm suggesting, so no change. Maybe this annoys some external user of U-Boot though which I can't test for that what I cannot see
<shadows>
I have a direct user for this pattern in mind with starfive_visionfive2_defconfig but it will be a few Linux devicetree rebasing releases yet and U-Boot release as well before I can fully implement the removal of the arch/riscv/dts/jh7110-* files which removes a bunch of clutter
<shadows>
also potentially there's some JH7110 CPU targets that will need their own discrete U-Boot targets. Not sure about this at the moment, but the Pine64 PineTab-V if we take it has a lot of wild changes in the bootloader that would have little in common with the visionfive2 variants
<shadows>
still would be OF_UPSTREAM but it would be neater I think to have u-boot overrides that match the name of the board target defconfig, just easier to understand and not guess or try to interpret what the involved filenames are
<shadows>
I think this accomplishes what SYS_BOARD would have, but without the breakage? hopefully.
haritzondo has joined #u-boot
Lightsword_ has joined #u-boot
haritz has quit [Ping timeout: 258 seconds]
fionera has quit [Ping timeout: 258 seconds]
dsimic has quit [Ping timeout: 258 seconds]
agraf has quit [Ping timeout: 258 seconds]
Lightsword has quit [Ping timeout: 258 seconds]
warthog9 has quit [Ping timeout: 258 seconds]
Lightsword_ is now known as Lightsword
fionera has joined #u-boot
warthog9 has joined #u-boot
dsimic has joined #u-boot
gsz has joined #u-boot
agraf has joined #u-boot
ndesaulniers has quit [Server closed connection]
ndesaulniers has joined #u-boot
monstr has joined #u-boot
haritzondo has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
ikarso has joined #u-boot
crb has joined #u-boot
crb has quit [Remote host closed the connection]
crb_ has joined #u-boot
crb_ has quit [Remote host closed the connection]
crb_ has joined #u-boot
crb_ has quit [Ping timeout: 248 seconds]
crb has joined #u-boot
kabel has quit [Server closed connection]
kabel has joined #u-boot
warpme has joined #u-boot
crb_ has joined #u-boot
clamor has quit [Ping timeout: 248 seconds]
crb has quit [Ping timeout: 256 seconds]
clamor has joined #u-boot
ungeskriptet has quit [Remote host closed the connection]
ungeskriptet has joined #u-boot
frieder has joined #u-boot
pbergin has joined #u-boot
gsz has quit [Ping timeout: 245 seconds]
Jones42 has joined #u-boot
darkxst_ has quit [Server closed connection]
darkxst has joined #u-boot
frieder_ has joined #u-boot
rgallaispou has joined #u-boot
mmu_man has joined #u-boot
rburton has quit [Server closed connection]
rburton has joined #u-boot
frieder has quit [Quit: Leaving]
frieder_ has quit [Quit: Leaving]
frieder has joined #u-boot
<frieder>
Hi, it looks like patches to /drivers/power haven't been applied for a while.
<frieder>
According to MAINTAINERS it is for Jaehoon Chung to care about this, but his last activity on the list dates back to January.
___nick___ has joined #u-boot
___nick___ has quit [Client Quit]
___nick___ has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
gsz has joined #u-boot
pbergin has quit [Ping timeout: 258 seconds]
prabhakalad has quit [Ping timeout: 248 seconds]
prabhakalad has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Ping timeout: 256 seconds]
slobodan has joined #u-boot
pbergin has joined #u-boot
prabhakalad has quit [Ping timeout: 260 seconds]
prabhakalad has joined #u-boot
gsz has quit [Ping timeout: 258 seconds]
pbergin has quit [Ping timeout: 256 seconds]
gsz has joined #u-boot
gsz has quit [Ping timeout: 256 seconds]
haritz has joined #u-boot
haritz has joined #u-boot
mripard has joined #u-boot
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
rsalveti has quit [Server closed connection]
rsalveti has joined #u-boot
kcxt has quit [Server closed connection]
kcxt has joined #u-boot
naoki1 has joined #u-boot
naoki1 has quit [Client Quit]
naoki has quit [Ping timeout: 248 seconds]
naoki has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
dsimic has quit [Ping timeout: 248 seconds]
dsimic has joined #u-boot
naoki has quit [Quit: naoki]
naoki has joined #u-boot
naoki has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
naoki has quit [Ping timeout: 248 seconds]
dujem has quit [Remote host closed the connection]
dujem has joined #u-boot
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #u-boot
ungeskriptet has quit [Remote host closed the connection]
Laralubsch has quit [Server closed connection]
ungeskriptet has joined #u-boot
toric has joined #u-boot
naoki has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
naoki has quit [Client Quit]
naoki has joined #u-boot
<toric>
How would I go about modifying the device tree to mux the pins currently owned by the USB driver to be owned by a GPIO driver with default pulldown? Currently the USB pins are floating till linux boots up, which on our board seems to be causing some issues with QC-cabpable chargers suddenly deciding to give us 12v...
naoki has quit [Client Quit]
naoki1 has joined #u-boot
naoki1 has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
naoki has quit [Quit: naoki]
naoki1 has joined #u-boot
naoki1 is now known as naoki
naoki has quit [Read error: Connection reset by peer]
naoki has joined #u-boot
gsz has joined #u-boot
dujem_ has joined #u-boot
pbergin has joined #u-boot
dujem has quit [Ping timeout: 256 seconds]
dujem_ is now known as dujem
___nick___ has quit [Ping timeout: 260 seconds]
___nick___ has joined #u-boot
naoki1 has joined #u-boot
dujem_ has joined #u-boot
dujem has quit [Ping timeout: 260 seconds]
dujem_ is now known as dujem
naoki has quit [Ping timeout: 258 seconds]
naoki1 is now known as naoki
jmasson has left #u-boot [#u-boot]
rgallaispou has quit [Ping timeout: 258 seconds]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #u-boot
___nick___ has quit [Ping timeout: 245 seconds]
rgallaispou has joined #u-boot
___nick___ has joined #u-boot
warpme has quit [Ping timeout: 258 seconds]
naoki1 has joined #u-boot
naoki has quit [Ping timeout: 258 seconds]
naoki1 is now known as naoki
naoki1 has joined #u-boot
naoki has quit [Ping timeout: 258 seconds]
naoki1 is now known as naoki
clamor has quit [Read error: Connection reset by peer]
clamor has joined #u-boot
<cambrian_invader>
toric: gpio-hog?
Hypfer has quit [Ping timeout: 260 seconds]
<Jones42>
apart from 'tail' - what's the proper way to extract the script from my boot.scr.uimg?
<Rutherther>
using dumpimage from u boot tools?
<Rutherther>
something like "dumpimage -T script -o boot.scr boot.scr.uimg"
frieder has quit [Remote host closed the connection]
<Jones42>
Rutherther: hm. that's what I've been trying to do. Not sure how to interpret the "dumpimage: failed to verify header of Default Image support" error message though.
<Jones42>
Any idea what went wrong?
Hypfer has joined #u-boot
<Rutherther>
Jones42: is type of that image really script? What does dumpimage -l show?
<Jones42>
I'm trying to figure out some things in phytec's default yocto image. So it's nothing I've messed up myself.
<Jones42>
also: it does boot, and I can (somewhat) read the script with cat.
<Rutherther>
Jones42: it seems to me that you have a "multi" image with script being the first (and only) image. So you would first have to do "dumpimage -T multi -p 0" and then "dumpimage -T script" on the produced file
<cambrian_invader>
generally if a devicetree binding is present in a U-Boot driver but isn't documented under doc/device-tree-bindings then Documentation/devicetree/bindings in Linux will apply instead
<Rutherther>
Jones42: I don't know then. I would expect it to be one of the images that are supported by u-boot, but I don't know which one. I guessed multi, it's wrong it seems. Unfortunately I don't know the image types respective magic headers nor a tool that would print the type of the image in a format supported by -T. So the most I can tell you is that you can list the types with "mkimage -T list" and that I would expect one of them to work.
<Jones42>
Rutherther: I guess I'll just dig through the dumpimage sources then :-) Thanks for your help, though!
<toric>
cambrian_invader: if you are willing to help somone who is completely lost in the device tree, https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/imx6ul.dtsi im trying to disable usbphy1 completely and set all of its pins to pull down, but I have no clue where to start, I dont see pin names or numbers anywhere in the usb nodes.
<cambrian_invader>
set status = "disabled"?
<cambrian_invader>
the pin stuff is likely in the dts for your board
<cambrian_invader>
which will include imx6ul.dts
<toric>
That sets the pins to floating at 0.6v, which is whats causing the issue we are seeing. https://github.com/lentinj/u-boot/blob/master/doc/README.usb means we cant just set usb to initalize with uboot, it has to be disabled before linux can boot, if im reading that right.
<toric>
So to avoid an 'XY' question, I am trying to just nuke USB from orbit because the only thing we are using it for after the bootROM finishes is power, and something that either uboot or the kernel is doing causes quickCharge enabled controllers to send us 12v, which does not end well.
mripard has quit [Quit: WeeChat 4.7.0]
<cambrian_invader>
have you tried enabling it?
<cambrian_invader>
technically you're supposed to only draw a certain amount of power unless the host has configured you (e.g. as a device)
<toric>
Yup, first thing I tried, no observable affect unless I type 'usb start' in the serial config.
<toric>
we are a usb host, quickCharge is a comms protocoll between the host and the power supply.
<cambrian_invader>
sorry, I've never dealt with that
<toric>
NP, having trouble finding people who have.
<toric>
Funny thing is, we dont *use* QC at all, but you cant find any usb power supplies that dont support it these days.
<cambrian_invader>
ok, but don't usb power supplies expect to be connected to usb devices?
<toric>
Yup, and its just fine once the kernel boots and the usb phy is initialized, but untill then we just so happen to float at 0.6v, which is out of the USB spec, and the QC spec exploits that as a means of charge negotiation.
<cambrian_invader>
what is floating?
<cambrian_invader>
shouldn't the data lines have pull ups/downs?
<toric>
the d+ and d- lines. They have pull ups/down on the processor side, but apparently they arent on all the time, probably because of some pinmuxing stuff.
<cambrian_invader>
I don't think usb is pinmuxed on the imx6ul but I could be wrong
<toric>
Well there goes that idea.
<cambrian_invader>
have you tried keeping the USB enabled? if the phy is on then those pull ups/downs should be too
<toric>
We are using a SOM, not the imx6ul directly (dont ask me why, HW was designed by a guy that has since left), so I might just have to get in contact with them.
<toric>
Yah, I tried enabling usb in the uboot defconfig and in the device tree, but uboot doesnt seem to enable the usb phy till you send the 'usb start' command over the console.