<__ad>
any idea why i cannot go hs2/400 on imx7s ?
<__ad>
config options are set
<__ad>
mode stays at 52Mhz Mode: MMC High Speed (52MHz)
stefanro has quit [Quit: Leaving.]
sng has quit [Remote host closed the connection]
dossalab has quit [Quit: dossalab]
<marex>
__ad: in U-Boot or in Linux ?
<marex>
__ad: did you enable CONFIG...UHS and HS200 and HS400 ?
<marex>
do you have switchable 3V3/1V8 vccq described in your DT ?
<__ad>
marex: u-boot, config otions are enabled. maybe the last point
Guest89 has joined #u-boot
Guest89 has left #u-boot [#u-boot]
<marex>
__ad: which board is this ?
<marex>
__ad: I vaguely recall seeing some sdhci goo in DT on some machines where HS200/400 modes were unstable
<__ad>
imx7s
<marex>
__ad: there is some ability to inhibit this in DT
<marex>
__ad: board, not soc
<__ad>
i maybe miss some dt part
<__ad>
in linux it works
<__ad>
i have fixed 1.8v, so maybe missing no-1-8-v, trying
tnovotny has quit [Quit: Leaving]
<marex>
__ad: you MUST have 1V8 vccq (IO voltage), that is mandatory for HS200/HS400
<marex>
__ad: with no-1-8-v you won't be able to switch to either of those modes
Gravis has quit [Ping timeout: 245 seconds]
Gravis has joined #u-boot
Gravis has quit [Client Quit]
<__ad>
marex: thanks. first, i am stuck on the u-boot-imx crappy stuff
<__ad>
then also SPL is involved, enabling HS400_SPL compilation breaks :)
Gravis has joined #u-boot
torez has joined #u-boot
valdemaras has joined #u-boot
Gravis has quit [Ping timeout: 250 seconds]
Gravis has joined #u-boot
<marex>
__ad: no problem with that in mainline u-boot
milkylainen has joined #u-boot
prabhakarlad has joined #u-boot
milkylainen has quit [Client Quit]
mckoan is now known as mckoan|away
ikarso has quit [Quit: Connection closed for inactivity]
sng has joined #u-boot
tixlegeek has joined #u-boot
<Clamor>
__ad: just curious, what you are loading from mmc in spl
sng has quit [Remote host closed the connection]
jaganteki has quit [Ping timeout: 246 seconds]
Gravis_ has joined #u-boot
soxrok2212 has quit [Read error: Connection reset by peer]
Gravis has quit [Ping timeout: 255 seconds]
soxrok2212 has joined #u-boot
Gravis_ has quit [Ping timeout: 250 seconds]
Gravis has joined #u-boot
goliath has quit [Quit: SIGSEGV]
Hammdist has quit [Quit: Client closed]
valdemaras has quit [Quit: valdemaras]
ikarso has joined #u-boot
Hammdist has joined #u-boot
torez has quit [Quit: torez]
rvalue has quit [Ping timeout: 246 seconds]
monstr has joined #u-boot
rvalue has joined #u-boot
vagrantc has joined #u-boot
monstr has quit [Remote host closed the connection]
<marex>
Clamor: probably u-boot
valdemaras has joined #u-boot
<Clamor>
marex: ok
sng has joined #u-boot
<marex>
Clamor: where does nv load stuff from ?
<Clamor>
marex: depends on straps, in my case emmc, but HS200/400 is not required
<marex>
Clamor: that is not required on imx either
<marex>
Clamor: but in u-boot proper, when loading larger blobs (kernel fitImage), it is useful to reduce boot time
<Clamor>
Obviously. True but this requires dm regulator and proper emmc setup as you have mentioned
<Clamor>
marex: if I don't find the cause of early i2c fail I might need to implement all power related stuff to avoid always on
qqq has joined #u-boot
sng has quit [Remote host closed the connection]
sng has joined #u-boot
goliath has joined #u-boot
Clamor has quit [Ping timeout: 244 seconds]
<marex>
ha
Clamor has joined #u-boot
<marex>
what is "early i2c fail" ?
jaganteki has joined #u-boot
prabhakarlad has quit [Ping timeout: 246 seconds]
<Clamor>
marex: if I call i2c xfer in the early stages of booting uboot (last stage before kernel) I get failure. At the same time if called later it works fine.
<Clamor>
I suppose i2c has hidden dependency
torez has joined #u-boot
frieder has quit [Remote host closed the connection]
rvalue has quit [Read error: Connection reset by peer]
<Tartarus>
I'm still thinking about the use case he described, all the same
<Tartarus>
Should we expect everyone to know to pip install .../requirements.txt or not
<pivi>
Tartarus: I do not personally mind. In our use case we just run a subset of the whole .gitlab-ci.yaml (that is different from the upstream one) for our use case to save time, and we run the whole/upstream one only "on-demand".
goliath has quit [Quit: SIGSEGV]
<Tartarus>
Yeah, it just raises a good question about what we should / shouldn't expect downstream consumers to do
Clamor has quit [Read error: Connection reset by peer]
prabhakarlad has joined #u-boot
<pivi>
Tartarus: yes, I agree that the question is valid. Whatever works for you we'll adapt. I already proposed internally to just do the same as the upstream gitlab-ci.yml file.