<jclsn>
Can you think of any possible reasons on why sf protect lock is not working in my case? I already tried looking the code. stm_lock is making use of the block protect pins. Are those to be defined in the device tree?
<jclsn>
Ah I guess this should be detected by sf probe
<sjg1>
jclsn: Which legacy subsystem are you looking at?
jpanisbl has joined #u-boot
<jclsn>
sjg1: First of all I am pretty new to U-Boot code. I have just looked at the gpio cmd lately and it seems to be a wrapper around the driver model. Same goes for the sf cmd. It is a bit confusing, but I guess necessary for legacy support
jpanisbl has quit [Quit: Konversation terminated!]
ikarso has quit [Quit: Connection closed for inactivity]
<rfs613>
jclsn: most flash chips have some hardware flash protection features. They often have "interesting" limitations, such as the protection ranges being powers of two, or being volatile (not kept across reset), etc. Of course some flash chips have perfectly sane block-based protection.
<rfs613>
then there is the flash controller, which might impose its own layer of protection - again there are all kinds. These generally work by denying the erase/program commands if they fall into certain ranges. Buf of course with the various 3/4 byte addressing, and extensions like paging register, it can be hit-and-miss.
<rfs613>
and lastly you have the u-boot code to drive all this. Historically this code has been mostly unware of the lower level protections, so it would allow you to issue erase/program commands, without any indication of error (until you try to read back the data).
<sjg1>
jclsn: Also I see there are two APIs for write-protection, one in the SPI flash uclass and another in the mtd non-uclass. There are only tests for the first one
<rfs613>
hehe, was about to mention something along those lines...
mckoan has quit [Read error: Connection reset by peer]
vagrantc has joined #u-boot
<sjg1>
For GPIO, sunxi and mxc (at leasst) still seem to use the old GPIO interface. Still, the migration deadline has passed so in theory we could just break those boards
<sjg1>
rfs613: It is not nice...I think the mtd matches Linux which is why, but the straggler needs cleaning up
Eschik has quit [Killed (copper.libera.chat (Nickname regained by services))]
goliath has joined #u-boot
splud has joined #u-boot
<splud>
greetings. I'm attempting to gather some info from an ARM device which is having trouble communicating with it's emmc device.
<splud>
it previously used to boot, but it's timing out with the emmc on reads. what use is the md commands reading from the mmc portmapped address - would there be any useful diagnostic data there?
<cambrian_invader>
try enabling CONFIG_MMC_TRACE
<splud>
okay, I'll do that once I replace the spi flash on the device. Any _read_ diagnostics that I might be able to perform?
<cambrian_invader>
huh?
<splud>
to compile and enable that on the device, I'll need to update it. I'm trying to do non-descructive evaluation of the problem if possible.
<cambrian_invader>
you can try staring at mmc info
<cambrian_invader>
(e.g. the command `mmc info`)
<cambrian_invader>
but generally U-Boot is compiled without debugging aids
<cambrian_invader>
so you may need to recompile to get anything useful
<splud>
mmc info is present, but theres comm issueswith the emmc device. Read timeouts - the attempt to bootis BEFORE I get a prompt.
<splud>
afk need to deal with something at top of the hour.
<splud>
apologies, had to unplug an EV.
teejay_ has joined #u-boot
teejay has quit [Ping timeout: 246 seconds]
<marex>
splud: u-boot version ?
<marex>
splud: you can try and start uboot from uboot, then try the trace
<marex>
you can force emmc into 1 bit mode (in DT, set bus-width = <1> ) and reduce the clock rate (clock-frequency = <400000>;) for example
<marex>
(I think it was clock-frequency ...)
<marex>
also check pinmux, clock tree
<marex>
and yeah, MMC_TRACE as cambrian_invader suggested
<cambrian_invader>
marex weren't you collecting sd cards a while back
<marex>
cambrian_invader: not just a while back ... it did have a follow up btw
<marex>
I ended up building me an SD card in an FPGA, with DRAM as backing store and USB upload into that DRAM
<marex>
I am contemplating V2 without the FPGA, but lets see, there are other things I'd like to explore first
<cambrian_invader>
I have an "interesting" card on my hands which only reports SCR.SD_SPEC=1 half of the time
<cambrian_invader>
so sometimes it gets detected as an MMC and we time out
<marex>
cambrian_invader: jeeze
<marex>
cambrian_invader: I have two cards where one never clears CACHE bit after cache ops were requested
<marex>
cambrian_invader: the card also does not hang, it just never finishes
<cambrian_invader>
huh
<marex>
cambrian_invader: and then I have another one, newer, from this year, and that one finishes just fine
<cambrian_invader>
really gives you confidence in their wear-leveling abilities
<marex>
c467c8f081859 ("mmc: Add MMC_QUIRK_BROKEN_SD_CACHE for Kingston Canvas Go Plus from 11/2019")
<marex>
in Linux that is ^
<cambrian_invader>
although maybe they just never figured anyone would use the cache...
<marex>
cambrian_invader: Linux only enabled it just before 6.1.y, that's why I ran across it
<marex>
cambrian_invader: and i could find like 2 other cards which implement the CACHE, no other cards I tested (and I have a stack) do
<cambrian_invader>
is that defined in the mmc spec or just sd?
<marex>
cambrian_invader: cache ?
<marex>
cambrian_invader: SD spec in some extension block