qschulz has quit [Remote host closed the connection]
qschulz has joined #u-boot
<samueldr>
Hi! I need to move this env-based workaround in a way to make it happen before PREBOOT (main_loop really) is ran, planning to RFC a cleanup of those PREBOOT-based usb start
<samueldr>
my naïve approach would have been to have SYS_BOARD configurable for sunxi and add an additional environment define, but it's not desirable AFAIUI
<samueldr>
am I missing a mechanism that would work on sunxi to further add to the environment for a specific defconfig?
<marex>
sjg1: so it does
<marex>
samueldr: is that to get usb keyboard working ?
<samueldr>
the environment variable yes, it's an increased timeout for usb hubs wakeup
<samueldr>
this is the only usage within U-Boot that is done through PREBOOT, all others are done through board-specific headers and directly affecting the default env
<samueldr>
the underlying goal is to then move the usb start outside of PREBOOT such that PREBOOT is left clear and open for more boards, and users less likely to try to use PREBOOT for something and accidentally break USB_KEYBOARD
<samueldr>
in other word, make the USB_KEYBOARD config more robus
<samueldr>
robust*
<samueldr>
it's AFAICT the only board that has further workarounds for usb within its PREBOOT commands
<marex>
why not just set the usb_pgood_delay in default env if the board needs it ?
<marex>
(or better yet, this is likely a property of the bus, so it should be in DT)
<samueldr>
my understanding is limited, but I think it's not a property of the bus, but of a device on the USB bus
umbramalison has quit [Quit: %So long and thanks for all the fish%]
<samueldr>
though in this device it turns out to be required as a hub needing it is built-in
<samueldr>
so it would also need to be user-facing
<marex>
it adds a delay after Vbus is enabled and before enumeration starts
<marex>
that's what the usb_pgood_delay does
umbramalison has joined #u-boot
<marex>
it's for the cases where the device does not respond to enumeration quickly enough as spec would like it to, for whatever reason
<marex>
indeed there are USB sticks which suck the same way
<samueldr>
AFAIUI yes, so that devices on the bus that breaks the spec end up working, but the controller itself doesn't need it
<samueldr>
so, about default env, I figure you mean `CONFIG_EXTRA_ENV_SETTINGS`, right?
<marex>
so it seems what you would need to do to make this right is describe the USB topology (or part of it) in DT and add this extra delay to the hub device, to indicate it needs longer start up time
<marex>
samueldr: yes
<samueldr>
on sunxi everything ends-up using CONFIG_EXTRA_ENV_SETTINGS from sunxi-common.h, and SYS_BOARD is hardcoded to be the SoC family
<samueldr>
so AFAIUI there is no way for a single board to add to EXTRA_ENV_SETTINGS
<samueldr>
which is why I initially thought of RFC-ing making SYS_BOARD configurable so that boards can further customize it via board-specific headers
<marex>
look how the extra env settings are extended by the later for that specific board
<marex>
that might be an option for you too
<marex>
samueldr: how is SYS_BOARD related to PREBOOT ?
<samueldr>
oops, I meant SYS_CONFIG_NAME, not SYS_BOARD
<samueldr>
and yes, this is exactly what I wrote for sunxi
thopiekar has quit [Ping timeout: 248 seconds]
<samueldr>
ooh, I see, if I added TARGET_OLIMEX_TERES_I as a new config like TARGET_DH_STM32MP1_PDK2 that would work while keeping SYS_CONFIG_NAME the same, I think
<samueldr>
so rather than having CONFIG_SYS_CONFIG_NAME="teres-i-a64" (for example) in the defconfig, it would have TARGET_OLIMEX_TERES_I=y which in turn in the Kconfig would configure that
<samueldr>
is that about right?
<marex>
yes
<marex>
the TARGET basically indicates which board you are building for
<marex>
and there can be a Kconfig which selects the details
<samueldr>
yes, that's what I got, but I didn't connect the dots to TARGET_* configs
<marex>
board/st/stm32mp1/Kconfig
<marex>
like so ^
<samueldr>
and annoyingly some arches make it a user-facing config
<marex>
and board/dhelectronics/dh_stm32mp1/Kconfig
<samueldr>
yes, TARGET_PINEBOOK_PRO_RK3399 would be another example of that
thopiekar has joined #u-boot
<samueldr>
thanks for unsticking me!
<marex>
samueldr: glad I could help
<samueldr>
I got hung up on the fact there's no sunxi boards with TARGET configs, so let's make the first one :)
<marex>
samueldr: could it be sunxi has some specific reason for not defining TARGET_ per board ?
<samueldr>
¯\_(ツ)_/¯
<samueldr>
seeing how it's done on other boards, it feels to me it could be as simple as it's not been needed yet
<marex>
samueldr: cant you set CONFIG_SYS_CONFIG_NAME in configs/yourboard_defconfig if that's all you need to override ?
<samueldr>
it won't work because it's not a user-selectable/configurable config
<marex>
samueldr: so, usb_pgood_delay should likely go into DT as a property of some vbus regulator instead, some startup-delay-us or so
<marex>
that leaves the 'usb start' in preboot
<samueldr>
in principle I agree, in practice it looks like it would be really hard to do
<samueldr>
my actual goal is to remove usb start from PREBOOT, as this is brittle and requires care to make sure usb is started for USB_KEYBOARD
<marex>
see Linux Documentation/devicetree/bindings/regulator/fixed-regulator.yaml , the fixed-regulator for example already supports the startup delay , U-Boot supports it too iirc
<samueldr>
the usb_pgood change is only a requirement so that a single board keeps working
<marex>
so the goal is to get rid of preboot ... but ... why is preboot a problem ?
<marex>
because user might override it ?
<samueldr>
preboot is not a problem, but having an internal config using it is brittle as it requires any further preboot usage to take care in adding it too
<marex>
U-Boot DT supports /config node, see "git grep config.{" ... you might want to implement some config option which says, for specific board, that it needs to start up USB on boot unconditionally (e.g. because of the keyboard)
<marex>
then there goes your preboot problem
<samueldr>
there's already CONFIG_USB_KEYBOARD for that
<samueldr>
which configures PREBOOT, but it composes badly
<samueldr>
as any other workarounds added to PREBOOT requires USB_KEYBOARD users to not forget to implement it in PREBOOT
<samueldr>
to not forget usb start in preboot*
<marex>
samueldr: try the /config {} node in U-Boot DT extras, that might be the right place to put this
<marex>
add some u-boot,start-usb-on-boot; and then use that in probably common/board_r.c to determine whether to start usb or not
<marex>
while U-Boot is initializing itself
<samueldr>
I'm sorry, this is something that I think is probably right, but is not helpful in this current discussion, but be good when I send the RFC about that
<marex>
what would be even more interesting would be if you could do u-boot,start-usb-on-boot = <&controller>; and limit which controllers you want to bring up on startup via phandle reference to them
<samueldr>
there's still the pgood issue that needs solving, but I guess that could be a /config/ DT prop
<marex>
samueldr: the pgood issue is likely a matter of vbus regulator startup delay property
<marex>
so that also goes into DT, just elsewhere
<marex>
see Linux Documentation/devicetree/bindings/regulator/fixed-regulator.yaml , the fixed-regulator for example already supports the startup delay , U-Boot supports it too iirc
<samueldr>
I have absolutely no way to test this, I need to implement a change without being able to test it so that a board is not broken by the other change
vagrantc has quit [Quit: leaving]
<samueldr>
I get what you mean with the vbus startup delay, I think, but without being able to test the change, I can't know for sure that "just" adding the startup delay to the right bus won't break it
<marex>
I don't understand this ... don't you have this laptop hardware ?
<samueldr>
no
<samueldr>
I'm doing due diligence when making a major change within U-Boot
<marex>
can't you send the patches to the board maintainers and ask them to test ?
<marex>
samueldr: you can ask olimex or the board maintainers about the exact problem with the hub
<marex>
I'll be back in a bit
<samueldr>
the commit I linked to explains it, it's the mcu used on the keyboard that is in a "firmware prompt" for 2s before loading its HID interface
persmule has quit [Remote host closed the connection]
<marex>
oh, yuck
persmule has joined #u-boot
<marex>
samueldr: if the keyboard does show up on the USB early, you might be able to deal with this via some USB quirk
<marex>
like if USB device with USB VID/PID <something> is detected, wait before scanning further
<samueldr>
so this all comes back to what I was doing: making the change the least controversial possible so that it doesn't block the actual meat of the RFC :)
persmule has quit [Remote host closed the connection]
persmule has joined #u-boot
indy has joined #u-boot
indy has quit [Ping timeout: 260 seconds]
<macromorgan>
so here's a noodle scratcher... why would the system fail to boot in SPL stage if I have both an Optee image and the rockchip_rng.c driver loaded?
<macromorgan>
no Optee + rockchip_rng, works. Optee + no rockchip_rng, works. Optee + rockchip_rng, doesn't work. As best I can tell that driver doesn't even get loaded in the SPL stage...
indy has joined #u-boot
indy has quit [Ping timeout: 268 seconds]
indy has joined #u-boot
indy has quit [Ping timeout: 260 seconds]
indy has joined #u-boot
indy has quit [Ping timeout: 268 seconds]
indy has joined #u-boot
mrnuke has quit [Read error: Connection reset by peer]
ldevulder_ has quit [Remote host closed the connection]
ldevulder has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
jclsn has joined #u-boot
<apalos>
/q pbrobinson
mmu_man has joined #u-boot
jagan has joined #u-boot
<pbrobinson>
apalos: ?
<apalos>
whitespace on /q pbrobinson
jagan has quit [Ping timeout: 260 seconds]
matthias_bgg has joined #u-boot
mmu_man has quit [Ping timeout: 240 seconds]
mmu_man has joined #u-boot
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #u-boot
sakman has quit [Ping timeout: 252 seconds]
mmu_man has quit [Ping timeout: 268 seconds]
matthias_bgg has quit [Ping timeout: 268 seconds]
mmu_man has joined #u-boot
jagan has joined #u-boot
matthias_bgg has joined #u-boot
sakman has joined #u-boot
sakman has quit [Remote host closed the connection]
sakman has joined #u-boot
destmaster84 has joined #u-boot
<destmaster84>
upgrading my yocto image using the u-boot 2021.04 the systen doesn't boot because Unknown command 'ubifsmount' - try 'help'... There's need to explicit enable UBI support in u-boot config before build it ?
<Tartarus>
yes, you need to enable ubifs support
camus has quit [Read error: Connection reset by peer]
<destmaster84>
Tartarus: because I never enabled it before, can you confirm that in the previous u-boot version was enabled by default?
prabhakarlad has quit [Quit: Client closed]
camus has joined #u-boot
destmaster84 has quit [Quit: Client closed]
<Tartarus>
It wasn't
<Tartarus>
Check your board port
akaWolf has quit [Ping timeout: 260 seconds]
prabhakarlad has joined #u-boot
akaWolf has joined #u-boot
LinuxHackerman has quit [Quit: Reconnecting]
LinuxHackerman has joined #u-boot
frieder has quit [Remote host closed the connection]
<apalos>
sjg1: thanks for the update, I think it looks better now
<apalos>
I'll have a closer look tomorrow. The only thing I did notice is a compilation warning, butI can fix that before merging
ldevulder_ has joined #u-boot
ldevulder has quit [Ping timeout: 268 seconds]
derRichard has quit [Quit: leaving]
camus has quit [Ping timeout: 260 seconds]
camus has joined #u-boot
jagan has quit [Ping timeout: 268 seconds]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #u-boot
ldevulder_ is now known as ldevulder
akaWolf has quit [Ping timeout: 260 seconds]
akaWolf has joined #u-boot
vfazio has quit [Read error: Connection reset by peer]
vfazio has joined #u-boot
monstr has quit [Remote host closed the connection]
vfazio_ has joined #u-boot
vfazio_ has quit [Client Quit]
matthias_bgg has quit [Quit: Leaving]
vagrantc has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
hays has quit []
hays has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
Domon has joined #u-boot
<Domon>
Can somebody explain, why in some devices, for flash uboot image into spi flash use like such commands:
<Domon>
Hello, wrote in wrong channel, but hope somebody can help me.
<Domon>
But not use sf? sf command even not enabled in uboot :/
<hanetzer>
Domon: depending on the board/soc, if you load a u-boot into ram that *does* support the sf command and do `go $addr` you can use sf there. however, I think it may be that your board simply doesn't require it.
prabhakarlad has quit [Quit: Client closed]
<Domon>
hanetzer: But problem, cp command flash image into RAM, but somehow it appearing in NOR flash. I can't understant this magic, even if know, that mips have RAM arrea, that maps NOR into RAM for boot purpose. But for example, writing into NAND also can use cp command, and here my brain breaks
hays has quit []
<hanetzer>
Domon: idk about your hw specifics offhand, standard disclaimers apply
prabhakarlad has joined #u-boot
<Domon>
So if it appearing in qualcomm soc's, it may be some custom qualcomm logic?
<hanetzer>
is it a router?
<hanetzer>
you may want to look into pepe2k's u-boot_mod repo if that's the case
<Domon>
Yes, it is router. Thank you :)
hays has joined #u-boot
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
prabhakarlad has quit [Quit: Client closed]
<marex>
Tartarus: do I recall it right you had hardware with smc911x ?
<marex>
Domon: sf commands are for SPI NOR ; cp.b commands are for Parallel NOR or HyperFlash
<marex>
the cp.b is in fact intercepted by the MTD subsystem in case it is directed at memory mapped NOR (=the parallel nor), otherwise it behaves like regular memcpy
<Domon>
marex: Thank you. One moment, that i don't understand, NAND also mapped to RAM by soc, if using cp.b can also update NAND?
GNUtoo has quit [Remote host closed the connection]
redbrain has quit [Read error: Connection reset by peer]
GNUtoo has joined #u-boot
redbrain has joined #u-boot
thopiekar has quit [Ping timeout: 268 seconds]
thopiekar has joined #u-boot
<marex>
Domon: NAND is not memory mapped, no
<marex>
at least not in most cases
hanetzer has quit [Quit: WeeChat 3.5]
<Domon>
Thank you :)
aggi has joined #u-boot
pbergin has quit [Ping timeout: 244 seconds]
<marex>
Domon: there is 'nand' command to operate raw nand and ubi/ubifs to operate UBI/UBIFS on top
mmu_man has quit [Ping timeout: 268 seconds]
<Domon>
marex: Problem, that router that i now using, don't have nand command :/
<marex>
Domon: could be some ancient vendor u-boot fork ?