Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2022.01, v2022.04-rc1 are OUT / Merge Window is CLOSED / Release v2022.04 is scheduled for 4 April 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
dmh has quit [Changing host]
dmh has joined #u-boot
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #u-boot
qschulz has quit [Quit: qschulz]
qschulz has joined #u-boot
jclsn7 has quit [Ping timeout: 272 seconds]
jclsn7 has joined #u-boot
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #u-boot
camus1 has joined #u-boot
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
thopiekar has quit [Ping timeout: 256 seconds]
thopiekar has joined #u-boot
camus1 has joined #u-boot
camus has quit [Remote host closed the connection]
camus1 is now known as camus
jclsn7 has quit [Ping timeout: 240 seconds]
jclsn7 has joined #u-boot
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #u-boot
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #u-boot
jclsn7 has quit [Ping timeout: 256 seconds]
jclsn7 has joined #u-boot
vagrantc has quit [Quit: leaving]
camus has quit [Remote host closed the connection]
camus has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
Thorn has quit [Ping timeout: 256 seconds]
redbrain has joined #u-boot
Thorn has joined #u-boot
redbrain has quit [Quit: leaving]
redbrain has joined #u-boot
mmu_man has joined #u-boot
mmu_man has quit [Remote host closed the connection]
sughosh has joined #u-boot
sughosh has quit [Remote host closed the connection]
akaWolf has joined #u-boot
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #u-boot
<milkylainen_> sjg1: binutils 2.38 is released. Contains the fix to ld where ld ended up with a segv on that strange linker script.
camus1 has joined #u-boot
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
mripard has quit [Ping timeout: 250 seconds]
camus1 has joined #u-boot
camus has quit [Ping timeout: 256 seconds]
camus1 is now known as camus
mripard has joined #u-boot
camus1 has joined #u-boot
camus has quit [Read error: Connection reset by peer]
camus1 is now known as camus
vagrantc has joined #u-boot
mmu_man has joined #u-boot
mripard has quit [Ping timeout: 256 seconds]
stefanct has quit [Ping timeout: 268 seconds]
stefanct has joined #u-boot
<flyback> https://www.cnx-software.com/2021/09/14/ch9102f-a-replacement-for-cp2104-usb-to-uart-bridge/ <--- nice cause silicon labs discontinued the cp2104, and their new cp2102n offical board doesn't have the vio pin which lets you set the i/o voltage, this one does
redbrain has quit [Ping timeout: 272 seconds]
mripard has joined #u-boot
grgy has joined #u-boot
grgy has quit [Quit: ZNC 1.8.2 - https://znc.in]
mthall has quit [Ping timeout: 256 seconds]
grgy has joined #u-boot
grgy has quit [Client Quit]
mthall has joined #u-boot
grgy has joined #u-boot
<samueldr> when scripting an mmc write, how should I discover the mmc block size to provide count?
<samueldr> I have $filesize as a length in bytes, from a load already, and setexpr available
<samueldr> AFAICT I'm only missing a way to get the block size of the target device
mthall has quit [Ping timeout: 256 seconds]
mthall has joined #u-boot
<marex> samueldr: setexpr blkcnt $loadaddr / 0x200
<samueldr> sorry, I didn't mean "how do I get the block count", that is already done and hardcoded with 0x200
<samueldr> my issue is with hardcoding 0x200
<samueldr> which AFAICT the actual block size used for mmc write is actually read from the eMMC device
<samueldr> other persons told me "it should be fine to hardcode 512 byte block sizes", and I mostly agree...
<samueldr> ... except that I don't have strong guarantees it's fine
<marex> samueldr: doesnt the mmc subsystem always operate on 512B blocks ?
<samueldr> I couldn't find any confirmation
<samueldr> if it does, then it's easy enough
<marex> samueldr: have you had a look into the code (it is available) ?
<samueldr> all upstream, so yeah available, I'm digging again now
<samueldr> (in parallel while asking)
<milkylainen_> erase groups are different from writes?
<marex> milkylainen_: that'd be mmc erase subcommand
<milkylainen_> Yes, that's what I'm trying to say.
<samueldr> it will be clamped to 512, at least
<samueldr> but it could be smaller
<milkylainen_> You can "erase" 512b blocks or erase groups.
<milkylainen_> smaller write block tnat 512?
<samueldr> though I guess it's already good to see now that it's limited to 512, but a partial write to the device could put the user in an awkward situation
<milkylainen_> sorry. erase I meant.
<milkylainen_> But what is it you're trying to do? Speed up erasing?
<samueldr> scripting a write
<samueldr> I have a `load` operating giving me `$filesize` in bytes
<samueldr> it's trivial with `setexpr` to get the number of blocks to write
<samueldr> except for the fact that AFAICT the actual block size can't be discovered
<milkylainen_> mmc_partconf_print
<milkylainen_> ?
<milkylainen_>     if(varname)
<milkylainen_>             env_set_hex(varname, part);
<milkylainen_> maybe contains something to access the ext_csd.
<milkylainen_> maybe just the partition.
<milkylainen_> hmm
<milkylainen_> not so useful.
<milkylainen_> Easily tweaked though.
<samueldr> I think JESD84-A43 has us covered
<samueldr> TLDR, read access of 512 bytes is mandatory
<samueldr> and the block size value is clamped at 512
<samueldr> only worry is why does the standard allow an invalid maximum read length (too small)?
<samueldr> (sams verbiage for write)
Zapy has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #u-boot
stefanct has quit [Ping timeout: 256 seconds]
stefanct has joined #u-boot
cpackham[m] has quit [Ping timeout: 250 seconds]
mvaittin has quit [Ping timeout: 250 seconds]
mmu_man has quit [Ping timeout: 272 seconds]
cpackham[m] has joined #u-boot
mvaittin has joined #u-boot