pkg/flash: update flash to use chips package #2849
Conversation
|
I know it seems weird to read the SFDP even when we find the chip, but bear with me. Most important: as time goes by, more and more chips will have an SFDP, and it makes sense to read it. Less important: the packages assumes a valid sfdp in many places, and it's actually a lot simpler to make the effort to read it in, get an empty one, and have operations like DWord fail. Short form: a test was doing a nil deref if I don't read in an empty SFDP :) |
rminnich
force-pushed
the
update-flash-to-use-chips
branch
from
92b4de2
to
f6b615d
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2849 +/- ##
==========================================
- Coverage 75.73% 75.69% -0.04%
==========================================
Files 425 425
Lines 42808 42855 +47
==========================================
+ Hits 32419 32438 +19
- Misses 10389 10417 +28
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Check for the chip ID first, before trying to read the SFDP. If it is found, use those values for density and so on. In any case, always try to read the sfdp. As time goes by, more and more chips will implement it, and it will go from mostly failing to mostly working. Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
rminnich
force-pushed
the
update-flash-to-use-chips
branch
from
f6b615d
to
f6a25dc
Compare
|
FYI: wit this change, I can ID a flash part from an RPI4, connected to QSPI MUX. Next step is read and write. |
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Check for the chip ID first, before trying to read the SFDP. If it is found, use those values for density and so on.
In any case, always try to read the sfdp. As time goes by, more and more chips will implement it, and it will go from mostly failing to mostly working.