ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
Forty-Bot has quit [Server closed connection]
Forty-Bot has joined #armlinux
sakman_ has quit [Remote host closed the connection]
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
sakman has joined #armlinux
pivi has joined #armlinux
nsaenz has joined #armlinux
heat has quit [Ping timeout: 245 seconds]
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #armlinux
sakman has quit [Remote host closed the connection]
amitk has joined #armlinux
iivanov has joined #armlinux
monstr has joined #armlinux
monstr has quit [Ping timeout: 258 seconds]
mvaittin has joined #armlinux
alpernebbi has quit []
apritzel has joined #armlinux
iivanov has quit [Remote host closed the connection]
frieder has joined #armlinux
apritzel has quit [Ping timeout: 260 seconds]
alpernebbi has joined #armlinux
iivanov has joined #armlinux
sszy has joined #armlinux
Lucanis has quit [Ping timeout: 240 seconds]
nsaenz has quit [Remote host closed the connection]
biju has joined #armlinux
dliviu has quit [Quit: Going away]
dliviu has joined #armlinux
headless has joined #armlinux
apritzel has joined #armlinux
prabhakarlad has joined #armlinux
prabhakarlad has quit [Quit: Client closed]
headless has quit [Quit: Konversation terminated!]
Amit_T has joined #armlinux
<Xogium>
so I've been trying to figure out how eeprom and nvmem actually work in linux. I tried using the sysfs interface to read and write those, but so far, I was only ever able to read. Writing via echo tells me 'write error: connection timeout'. Same with dd. So I tried echo and tee which said i/o error instead. As for printf it says nothing but also doesn't write so presumably keeps silent about there being
<Xogium>
an actual error
<Xogium>
am I doing something wrong ? Is that how a read-only eeprom behaves ? Fwiw it is an at24c32 and the dt node only sets the i2c address of the eeprom. Doesn't set pagesize or anything like that
<Xogium>
I know the eeprom write protect is controlled via a gpio, but that's pretty much all I know about it
alpernebbi_ has quit []
bjoto has quit [Ping timeout: 258 seconds]
prabhakarlad has joined #armlinux
heat has joined #armlinux
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
frieder has quit [Remote host closed the connection]
pg12 has quit [Ping timeout: 246 seconds]
pg12 has joined #armlinux
<rfs613>
Xogium: writing to the 'eeprom' under sysfs works for me. Though if you have a separte write protect controlled by a GPIO, then you need to control that gpio... there looks to be wp-gpios property you can put in the devicetree for this.
<Xogium>
rfs613: oh, so there is ? I looked at the doc for eeprom dt-bindings and didn't see anything regarding wp gpio
<rfs613>
Xogium: admittedly the description is not very good...
<rfs613>
Documentation/devicetree/bindings/eeprom/at24.yaml just says:
<rfs613>
wp-gpios: true
<rfs613>
but there is an example further below, that shows it uses "standard" gpio description
<rfs613>
wp-gpios = <&gpio1 3 0>;
<Xogium>
ah I was checking out generic eeprom doc
<rfs613>
I believe you will also need to specify the pagesize otherwise it will default to '1'
<Xogium>
makes sense
<Xogium>
32 should do it for that eeprom
<Xogium>
so how does it control the wp ? You set it high or low and it determine the permanent state ?
<rfs613>
I haven't looked into the details of that, because mine doesn't have a write-protect gpio
<Xogium>
I see
iivanov has quit [Read error: Connection reset by peer]
<Xogium>
I'll try things out and see
<rfs613>
hmm, i just searched for "wp-gpios" in the whole tree... several hits under Documentation, many in the dts files, but only two under drivers...
<rfs613>
and those two seem to be related to mmc
* Xogium
frowns
<Xogium>
same here, seems to be mmc only
<rfs613>
so perhaps, you could try manually toggling the wp, either through the legacy sysfs interface for gpios, or the newer method (gpiolib?? not remembering exactly...)
<Xogium>
pF12 to toggle it, I think... I'll try and get the gpio utilities in busybox
<rfs613>
ah, it is libgpiod, and there are userspace tools like gpiodetect, gpioset,...
<Xogium>
I'm surprised busybox doesn't carry those
<Xogium>
could the pagesize be why I can't seem to write on it ?
mag has quit [Quit: Leaving]
<Xogium>
rfs613: if I were to share a link to the board schematics, could you help me figure out the gpio state for the wp of the eeprom ? Asking, because I don't really know if that can be determine using a schematic
<Xogium>
I'm honestly confused on this behavior
mag has joined #armlinux
<rfs613>
Xogium: sorry, just noticed this now... so looking at the at24c32 data sheet, it says regarding the WP pin: "when tied to GND, allows normal write operations. When tied high to Vcc, all write operations to the upper quadrant (8/16k bits) of memory are inhibited. If left unconnected, WP is internally pulled down to GND"
<rfs613>
which is... interesting... to say the least...
<Xogium>
yes I saw that too. I understand the first one but the two other cases are... Weird
<Xogium>
specially the last one I'm not sure what to make of
<rfs613>
well, if you don't connect anything to the WP pin, then writes are allowed.
<Xogium>
ah so it's equivalent to the first case
<rfs613>
yep
<Xogium>
hmm
<Xogium>
there is a complete sentence actually stored in there right now, presubably by the vendor
<Xogium>
but anything I attempt to write just doesn't get written
<Xogium>
Grow old along with me, the best is yet to be.
<rfs613>
so maybe your WP is connected to a GPIO pin which has a pull-up, or is outputing a 1
<Xogium>
mmmh
<rfs613>
can you read the whole 32kbits / 4kB ?
<Xogium>
I think so. I'm not sure how to confirm this
<rfs613>
actually, i think i understand the WP now... it only affects the top "quadrant", in your case that would be the upper 8kbit / 1kbyte
<Xogium>
I tried to printf '\x2' > eeprom and that failed fwiw
<Xogium>
just as a try
<rfs613>
that would be writing to the beginning of the device, which should work regardless of WP (since only the upper quadrant is "protected" via WP)
<Xogium>
yeah :/
<rfs613>
are we sure it is an at23c32 device?
<rfs613>
err, at24c32
<Xogium>
well this is what the manufacturer added in the dt, at the very least
<Xogium>
hmm
<rfs613>
I ask because I would have expected WP to affect the whole device, not just upper quadrant. That seems the most likely reason why writes would be failing.
<Xogium>
iirc that eeprom is on i2c0 on the schematics
<Xogium>
I wish I could give a schematic to chatgpt and it would describe it :D
<rfs613>
the boardID shows at24c256
<Xogium>
mm hmm so 256 kbytes, or kbit ?
<rfs613>
and it looks like there is a testpoint TP32 for accessing the WP signal
<rfs613>
you could tie that to GND directly maybe
<Xogium>
so wait, this means the dt is in fact wrong, correct ?
<Xogium>
that's a fun sentence
<rfs613>
hehe
<rfs613>
i have to run for a bit, but the datasheet for at24c256 says the WP pin affects the entire device, not just upper quadrant
<Xogium>
hah
<rfs613>
i'll be back in half an hour or so...
<Xogium>
alrighty
<Xogium>
thank you so much for your help so far
<Xogium>
I'll check out the data too and fix that darn dt
<Xogium>
rfs613: according to gpioinfo, line 12: "PF12" unused input active-high
<rfs613>
so to enable writes, you need to make that pin go low, to counteract the 10k pull-up (R55)
<Xogium>
rfs613: yeah I'm trying to figure how to do that using gpioset
heat_ has joined #armlinux
heat has quit [Read error: Connection reset by peer]
<Xogium>
I admit the gpioset syntax is extremely confusing
<Xogium>
should I do something like gpioset -l -m signal gpiochip5 12=1 ? Or 0 ? I'm very confused
<Xogium>
woops forgot -b but yeah
<rfs613>
well -l essentually inverts the polarity, so you set it to 1 and it actually puts a 0 on the pin
<Xogium>
I see
<Xogium>
rfs613: that worked ! Hmm now the only thing is how do I actually override the whole content of the eeprom ? I managed to store "this is a test" but there are still part of the previous sentence stored in it too
<rfs613>
the only way is to write to every byte
<rfs613>
dd if=/dev/zero of=/path/to/eeprom for example
<Xogium>
oh
<Xogium>
makes sense
<rfs613>
you can also use seek option of dd to modify somwhere other than at the beginning
<Xogium>
well this is good news, the eeprom now works
<Xogium>
so this would seek 50 bits forward, correct ?
<rfs613>
that will write "testing" begining at byte 50. "seek" uses multiples of the blocksize (not related to teh EEPROM's blocksize)
<Xogium>
ah byte
<rfs613>
bytes, not bits
<rfs613>
bs=512 is the default if not specified
<Xogium>
yeah that's probably why it said file too large ;)
<Xogium>
actually I wonder, is there an equivalent to /dev/zero that would write all 1 instead ?
<rfs613>
there's a simple trick involving tr
<rfs613>
tr "\000
<rfs613>
tr "\000" "\377"
<Xogium>
why 377 ?
<rfs613>
use that as a filter to change 00 bytes to 0xFF
<rfs613>
octal for 0xFF
<Xogium>
oh right
<rfs613>
tr is old and doesn't understand 0x hex notation, IIRC
<Xogium>
specially the one in busybox, surely
<Xogium>
so every time I'd want to write in that eeprom, I'd need to manually use gpioset ?
sudeepholla_ has quit [Remote host closed the connection]
<rfs613>
btw that at24c256 has 32kbytes of storage, and a page size of 64 (not 32)
<Xogium>
yea I saw that and fixed the dt :)
<Xogium>
both for u-boot and linux, because why not
sudeepholla_ has joined #armlinux
<rfs613>
ok. And unlike flash, there is no real need to "erase" it back to 0xFF.
<Xogium>
no ? I thought it was like nor or nand inside, just byte addressed instead of block
<rfs613>
i suppose modern devices might be implemented that way, but historically, EEPROM came before flash. You could re-write any part independently.
<Xogium>
not a bad thing, then. It'll avoid wearing out by writing then erasing then writing again
<rfs613>
the only limitation has to do with address wraparound within the pages, you need to be aware of that
<Xogium>
oh yeah, I see
<rfs613>
it only auto-increments the lower bits of the address
<Xogium>
tbh for now I just want to store 2 mac addresses inside this thing and use them in my dt with nvmem cell
<Xogium>
but I am not sure in which form I should store them. Binary, probably ?
<rfs613>
so I am wonderingif we should report this business of wp-gpios being documented, but apparently not implemented, to someone somewhere...
<Xogium>
yes... I think it would be a good idea
sudeepholla_ has quit [Ping timeout: 258 seconds]
<Xogium>
I do still wonder how this would actually work, would it be toggled at runtime or permanently set to read-only or read-write depending ?
<rfs613>
arnd: ^^^ any thoughts about that? Probably contact Bartosz?
<Xogium>
so now wondering which way is better for storing a mac address so that linux can grab it from the nvmem cell... Should I use printf '\x...' ?
<rfs613>
Xogium: if you're doing it under Linux, you will be scripting the mac change, so I think you can do anything you want.
<rfs613>
if you do it in u-boot (and pass it via DT to linux) there's probably some standard (likely just 6 binary digits at a specific offset)
<rfs613>
s/specific/specified/
<Xogium>
I'm just wondering if the nvmem cell property in dt will be better off with data stored like this, or would a plain text mac do fine ? I have no idea tbh
<Xogium>
first time I attempt this, and that part is mostly for fun
<Xogium>
mostly, since u-boot is currently misbehaving, or linux, not sure which and duplicating the mac address I set on eth1 via the env to eth2 as well. Rude
<rfs613>
lol yeah that isn't nice...
<Xogium>
and I'm not very good at debugging why. I tend to get overwhelmed pretty quickly in C, no real surprise if you have only tts
<Xogium>
I'll just go with binary stored there
sudeepholla_ has joined #armlinux
apritzel has quit [Ping timeout: 240 seconds]
<Xogium>
rfs613: awesome :) I think I've figured it out. Thanks for being so helpful !
<Xogium>
not leaving as I'm definitely interested in the gpio wp thing of course
heat_ has quit [Remote host closed the connection]
heat__ has joined #armlinux
<Xogium>
huh, now that's interesting
<Xogium>
I terminated gpioset
<Xogium>
expecting the gpio to go back to active high/input
<Xogium>
it went back to high, but stayed an output
<rfs613>
yeah, it seems some versions reset it back, and others do not... there are lots of complaints about this behaviour, either way
<Xogium>
this leaves the eeprom writable
<rfs613>
high = write protect
<Xogium>
you'd think so
<rfs613>
and if the pin is an input, it will be tri-stated, so the pull-up resistor (R55) will pull it high
<Xogium>
but now it is active high and output, and I can still write
<rfs613>
do you have it being inverted with -l flag?
<Xogium>
I can't force it back to 0 :D it's now set as output until I reboot
<Xogium>
when I ran gpioset, yes. But now gpioset was terminated
<Xogium>
it is returning 1 with gpioget
<rfs613>
it's amazing how something simple like toggling a single pin has become so complicated in modern systems... :-)
<Xogium>
you bet
<Xogium>
this seems like a bug to me ?
<Xogium>
the -l state did revert when I terminated gpioset with sigint using kill
<rfs613>
i was never clear why gpioset would "reset" things upon exit... but presumably there is a reason behind that decision.
<Xogium>
but output/input now is impossible to fix, due to gpioset releasing the pin after it finished running
<rfs613>
oh, try gpioset without a value.
<Xogium>
so like gpioset 5 12 ?
<rfs613>
12= but no 0 or 1 after
<Xogium>
that doesn't work, it wants an offset value mapping
mvaittin has quit [Ping timeout: 240 seconds]
<rfs613>
gpioset gpiochip5 12=
<rfs613>
something like that?
<Xogium>
either way it huh appears I can write to the eeprom as long as the gpio is an output ? It doesn't even need to be pulled low, clearly, as doing dd and such still works despite active high
<rfs613>
that would depend what value is in teh gpio output register. If it defaults to 0, then as soon as you change it to an output, the pin will go low.
<rfs613>
hmm okay i read that on a blog somewhere. Was just a guess...
<Xogium>
I think you need 0 or 1 but it comes back to 1 the minute it has been... Actually
<Xogium>
earlier I ran into a similar issue, playing with output and input but not low/high. I set to 1 for fun, and was unable to bring it to 0 again. I had to reboot
<rfs613>
typicall you have an output register, whose value can be freely set, but it only appears on the pin if configured as an output.
<rfs613>
meanwhile, you can read the current pin status at any time. If it is an output, it will match with the output register
heat__ has quit [Remote host closed the connection]
<Xogium>
how do I check that ?
<rfs613>
but if it is an input, it will always read 1 in your case, due to the external pull-up (R55) on that board
heat__ has joined #armlinux
<Xogium>
hmm
<rfs613>
i think gpioset / libgpio hides this somewhat... the GPIO controller itself would have registers for this of course.
<Xogium>
when I boot my system, the gpio is definitely showing in gpioinfo as input
<rfs613>
that's usually the default, since it is safe (won't cause some external short-circuit...)
<Xogium>
there's something fishy here since I can still wrinte to the eeprom
<Xogium>
*write
prabhakarlad has quit [Quit: Client closed]
<rfs613>
are you doing power cycle reboot, or just soft-reboot?
<Xogium>
soft reboot. But I mean, I haven't rebooted now
<Xogium>
I just terminated gpioset and noticed I can still write to the eeprom
<Xogium>
this is getting very confusing
<rfs613>
so that suggests the pin is still an output, and the value is 0 (the actual value, not considering inverting via -l option)
<Xogium>
no gpioget returns 1
<Xogium>
so like 1, output
<Xogium>
unless gpiolib utilities are liar
<Xogium>
so... It is like, earlier when I wrote gpioset -b -m signal -l 5 12=1
<rfs613>
AFAIK gpioget should always return the actual pin state (regardless if its an input or output)
<Xogium>
it reverted the -l when terminating, but didn't rever the =1
<rfs613>
looks like gpioget also has -l option
heat__ is now known as heat
<Xogium>
oh, great
<rfs613>
if you use it on set, also use it on get, otherwise you'll see inverted values
<Xogium>
honestly, some part of me thinks the sysfs interface was easier
<rfs613>
i have to agree... the only annoyance with the sysfs interface was that the magic number was hard to figure out... and could change depending on the order of things being probed, new kernel version, etc.
<Xogium>
yeah
<Xogium>
absolutely
<Xogium>
but this lib thing is just... Too much
<rfs613>
you can still use the sysfs version
<rfs613>
or at least, it was still there last time i checked...
<Xogium>
I can't even actually trust its output because gpioinfo tells me active high, but do I have to invert with -l when calling gpioget ? I just don't know. This is making me dizzy
<rfs613>
the -l flag is just there for people who can't understand the "active low" idea.
<rfs613>
software types in particular seem to have a hard time flipping it around, they want 1=on and 0=off
<Xogium>
right
<rfs613>
so if you put -l then gpioset/gpioget will flip it for you
<Xogium>
so using =0 or =1 is the same thing, correct ?
<Xogium>
depending on what you want to make happen
<rfs613>
without -l option, =0 will put the pin low, =1 will put it high
<rfs613>
and with -l, the opposite will be true
<Xogium>
you know, that makes more sense to me
<Xogium>
the without -l thing
<Xogium>
let me quicky try something
<Xogium>
*quickly
<Xogium>
yeah there's something bad
<Xogium>
when I make a soft reboot, the gpio according to gpioget 5 12 returns 0
<Xogium>
if I then set it to 1, then consult gpioget after, it returns 1. Nothing weird till now
<rfs613>
and writing to eeprom works, or is blocked?
<Xogium>
if I then set it to 0, then check with gpioget again, no matter what I do, it is stuck to 1 until I soft reboot again
<Xogium>
I cannot check on this though as I've tried something like
<rfs613>
that is indeed odd
<Xogium>
gpioset -b -m time -s 5 5 12=0
<Xogium>
then a gpioget and got ebusy
<Xogium>
writing to eeprom is allowed as soon as 12=1
<Xogium>
blocked when 12=0
<rfs613>
this is with -l, or without?
<Xogium>
let me try again
<Xogium>
but the bug with 1 or 0 happens no matter if -l is passed or not
<Xogium>
okay so
<Xogium>
when booting I can confirm gpioget returns 0. Eeprom is blocked
<rfs613>
hmm but at the hardware level, 0 = GND means that writing eeprom is enabled.
<Xogium>
if I run gpioset without -l, the eeprom is still blocked, and then no matter what I do, I can't get the thing back to 0, the 1 is there until I reboot
<Xogium>
if I pass -l, same issue happens when I terminate gpioset, but the eeprom is writable and remains this way
<rfs613>
it strange. Some GPIO controllers have a register for polarity control, so they can flip the 1 to 0 (and vice versa) automatically. But that doesn't exist eveywhere, so I doubt that -l flag would make use of it
<rfs613>
maybe we should just try the sysfs interface... might shed some light...
<Xogium>
the weirdest thing is if I use -l in gpioset then look at gpioinfo *without* passing -l, I will see in there, active low
<Xogium>
if I don't use -l, it will remain active high despite now being an output
<Xogium>
yeah I'll make a kernel build with that enabled, give me a few mins
<Xogium>
it's been a long time I used sysfs though so I might be a dum dum at first ;)
<rfs613>
looks like wp-gpio was removed on purpose (but didnt' removed from Documentation it seems)
<Xogium>
... why did they do that ?
<rfs613>
seems the NVMEM system handls it
<Xogium>
huh, does it
<Xogium>
I have to define the gpio when I make the nvmem dt node ?
<rfs613>
i'm only going on what the commit message says
<Xogium>
yeah no worries
<rfs613>
wp-gpios is documented in Documentation/devicetree/bindings/nvmem/nvmem.yaml
<Xogium>
the ironic thing is I could very well define the wp for the eeprom itself as I've still go a 6.1.28 kernel
<Xogium>
unless that's been backported
<Xogium>
alright, kernel with gpio sysf, here we are
<rfs613>
now we need the magic gpio number ;-)
<Xogium>
oh dear
<rfs613>
usually from the boot messages it's possible to figure it out
<Xogium>
how do I find that one again ?
<rfs613>
can you put the dmesg into a pastebin or similar, or mail it to me?
<rfs613>
you're basically looking for gpiochip5
<Xogium>
oh I found it
<Xogium>
gpiochip80 label is gpiof
<rfs613>
usually it will start numbering at 512 or somesuch. Then for each gpio controller (as it probes through devicetree) it will *reduce* the value.
<Xogium>
yeah I remember that now
<rfs613>
so for example if a gpio controlle with 32 pins comes first, it will have address 480 to 511.
<rfs613>
the next controller, let's say it has 16 pins, would be 464 to 479.
<Xogium>
right
<rfs613>
when a controller is probed it usually prints the base value it was assigned. You can search dmesg for that.
<Xogium>
all of them here have 16 lines, only the last gpiochip128 has 8 lines
<rfs613>
ok, so we still need the base of gpiochip5....
<Xogium>
base file in gpiochip80 is 80
<Xogium>
which would make sense since we have another gpiochip which is 96 but that's gpiog
<Xogium>
I reckon this means 92 is our pf12
<Xogium>
if I remember correctly we then have to export the gpio 92 so it is active low
<Xogium>
or whatever this corresponds to in sysfs terms
<rfs613>
you export it just to make it available
<rfs613>
then there is one file for direction (change it to output)
<Xogium>
oh that's right
<rfs613>
and one for value (1 or 0)
<Xogium>
bit rusty
<Xogium>
;p
<rfs613>
has been a few years for me too :-0
<Xogium>
rfs613: this is most likely a bug in gpiolib ?
<Xogium>
setting direction to out lets me write in the eeprom. I did not touch active_low which remained at 0. Setting it to in again blocks the eeprom writing
<rfs613>
that seems correct, because the "value" will default to 0. And so as soon as you change direction to outout, the pin will go to 0, enabling writes.
<rfs613>
when you switch it back to input, the pin will go high again (due to the external pullup)
<rfs613>
i think "active_low" in the sysfs is equivalent to the -l flag on gpioset/get, it logically negates the values, so that software can pretent that 1=on and 0=off, even when the hardware differs.
<Xogium>
actually, that I use out or in, active_low is always saying 0
<rfs613>
ah yes, the docs confirm this for active_low: "Any nonzero value will invert the value attribute for both reading and writing"
<Xogium>
so what the hell is happening with gpioset then ?
<rfs613>
not sure, although you could now run gpioset commands, and see what effect they have on direction/value/active_low...
<Xogium>
that's a good idea
<Xogium>
lets see
<Xogium>
apparently no, I can't do that, at least I have to destroy the export every time... That returns ebusy
<rfs613>
ah, ownership battles, fun times
<Xogium>
yup
<Xogium>
makes it very difficult to figure out what is going on
<Xogium>
rfs613: checking gpioinfo while setting direction to output says output, active_high. When checking it with in, it is back to input
<rfs613>
i guess the fact that gpioset (might) be reseting configuration upon its exit makes it that much more difficult...
<Xogium>
so essentially, we've got a behavior that bugs in gpiolib, that is output+active_high doesn't let me write in the eeprom, but sysfs out lets me write into it despite being output+active_high according to gpioinfo
<rfs613>
note that "active_high" is not the same as the output being high or low. Rather it's an indication of the polarity.
<rfs613>
active_high is the usual software assumption, where 1=high and 0=low.
<Xogium>
right
<Xogium>
this is confusing to the point if one can honestly tell me the sysfs isn't going away any time soon despite being legacy, then I might stick to using it
<rfs613>
oh i'd say the writing is on the wall... there is some VERY ANGRY UPPERCASE SHOUTING about it in the documentation even... ;-)
<rfs613>
even with a red background behind the uppercase shouting text ;-)
<rfs613>
so probably the correct way is nvmem and its wp-gpios devicetree. Though I've not used that myself...
<Xogium>
yeah
<Xogium>
I'll see about setting this up
<rfs613>
of course, sooner or later, someone is going to have a large enough eeprom, they will want to put a filesystem on top of it. So we'll have nvmem-block device I guess ;-)
<Xogium>
hahaha
<Xogium>
maybe
<rfs613>
and then that will turn out to be not ideal, so somethign like UBI will be invented
<Xogium>
presumably given it's still raw flash of sort
smoothdev has quit [Ping timeout: 252 seconds]
smoothdev has joined #armlinux
biju has quit [Quit: Konversation terminated!]
<rfs613>
eeprom's use two transistors per bit stored. So each bit can be independently set or cleared.
<rfs613>
flash uses only one transistor per bit, so you can program it (to 0) but reset back to 1 can only be done for whole pages at a time.
<rfs613>
flash has higher density, lower cost (per bit) and is faster (because you can erase entire pages at once)
<Xogium>
that's actually a genius idea, the way eeproms are designed
<rfs613>
in the even older times, before EEPROM, we had EPROM (only one E). You could write them, but to erase them, you'd have to hold them under a UV lamp for a while.
<rfs613>
the single E meant "erasable"
<Xogium>
oh yes I vaguely remember them
<Xogium>
I used to use a versabraille 2 for school and this was cpm based, stored in eprom instead of on floppy
<rfs613>
they had little glass windows on the top, usually covered by a sticker or door.
Amit_T has quit [Quit: Leaving]
<Xogium>
time for dinner then I'll try making a nvmem cell yeepi !
<rfs613>
hehe
<Xogium>
thank you so much for your help so far with all of this, it's extremely appreciated