I think we're getting closer to the truth now. Reading the source code and especially this section is interesting: #ifdef CONFIG_W1_SLAVE_DS2433_CRC <http://sbexr.rabexc.org/latest/sources/0f/5e84f0288ea608.html#00b1600900b16024> /* can only write full blocks in cached mode */ if ((off <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cd008000cd00f> & W1_PAGE_MASK <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001f0090001f017>) || (count <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cd014000cd01b> & W1_PAGE_MASK <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001f0090001f017>)) { dev_err <http://sbexr.rabexc.org/latest/sources/1c/d25b2fb3f904be.html#000670090006802b>(&sl->dev, "invalid offset/count off=%d cnt=%zd\n", (int)off, count); return -EINVAL <http://sbexr.rabexc.org/latest/sources/7f/c1319580667ad5.html#0001a0090001a011>; } /* make sure the block CRCs are valid */ for (idx <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011> = 0; idx <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011> < count <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cd014000cd01b>; idx <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011> += W1_PAGE_SIZE <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001d0090001d017>) { if (crc16 <http://sbexr.rabexc.org/latest/sources/0d/c2946195028c93.html#0001400100014037> (CRC16_INIT <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001200900012015>, &buf <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000cc028000cc02e> [idx <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#000d0002000d0011>], W1_PAGE_SIZE <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001d0090001d017>) != CRC16_VALID <http://sbexr.rabexc.org/latest/sources/2d/f15386f9fe4f5a.html#0001300900013016>) { dev_err <http://sbexr.rabexc.org/latest/sources/1c/d25b2fb3f904be.html#000670090006802b>(&sl->dev, "bad CRC at offset %d\n", (int)off); return -EINVAL <http://sbexr.rabexc.org/latest/sources/7f/c1319580667ad5.html#0001a0090001a011> ; } }
If I try to run these commands: echo "12345678901234567890123456789012" > /sys/bus/w1/devices/23-000002eddd9b/eeprom echo "1234567890123456789012345678901" > /sys/bus/w1/devices/23-000002eddd9b/eeprom dmesg | tail [80808.027040] w1_slave_driver 23-000002eddd9b: invalid offset/count off=0 cnt=33 [80829.659168] w1_slave_driver 23-000002eddd9b: bad CRC at offset 0 I removed some output from my terminal and focused on these lines. The errors found using dmesg looks to come from this section in the driver. If I send 33 bytes I get the invalid offset/count error and with 32 bytes I pass this section and get crc error. Now I have to try to manually calculating the crc and see where it takes me. onsdag 30 september 2020 kl. 13:16:09 UTC+2 skrev Sven Norinder: > Maybe kernel must have crc enabled for 2433 writes? > Last line implies something about writes. > > config W1_SLAVE_DS2433 > tristate "4kb EEPROM family support (DS2433)" > help > Say Y here if you want to use a 1-wire > 4kb EEPROM family device (DS2433). > > config W1_SLAVE_DS2433_CRC > bool "Protect DS2433 data with a CRC16" > depends on W1_SLAVE_DS2433 > select CRC16 > help > Say Y here to protect DS2433 data with a CRC16. > Each block has 30 bytes of data and a two byte CRC16. > Full block writes are only allowed if the CRC is valid. > > /Sven > > onsdag 30 september 2020 kl. 10:56:55 UTC+2 skrev Johan Lind: > >> Well, I have an i2c memory on the same board and to read and write to >> that I can use the following commands: >> write >> cat data.eeprom > /sys/bus/i2c/devices/2-0057/eeprom >> read >> cat /sys/bus/i2c/devices/2-0057/eeprom | hexdump >> >> I did try your suggestion of using dd but I could not get it to work. >> root@beaglebone:/home/debian# dd if=/dev/zero >> of=/sys/bus/w1/devices/23-000002eddd9b/eeprom bs=32 >> dd: error writing '/sys/bus/w1/devices/23-000002eddd9b/eeprom': Invalid >> argument >> 1+0 records in >> 0+0 records out >> 0 bytes copied, 0.0159578 s, 0.0 kB/s >> root@beaglebone:/home/debian# >> >> As the eeprom is written to contain data on another device, so I thought >> it would be enough to use /dev/zero as input. >> Reading out data show no change of content (as expected consider the >> output from dd) >> cat /sys/bus/w1/devices/23-000002eddd9b/eeprom | hexdump >> 0000000 00ff 55aa 00ff 55aa 00ff 55aa 00ff 55aa >> onsdag 30 september 2020 kl. 07:15:53 UTC+2 skrev Sven Norinder: >> >>> The eeprom probably is a device, not a filesystem. >>> Use dd instead. >>> /Sven >>> >>> tisdag 29 september 2020 kl. 17:59:14 UTC+2 skrev Johan Lind: >>> >>>> I tried with only a short (6 bytes) string but still the same behaviour. >>>> >>>> >>>> tisdag 29 september 2020 kl. 17:45:47 UTC+2 skrev >>>> robert.sty...@gmail.com: >>>> >>>>> I suggest trying to write less than 32 bytes (the dmesg implies >>>>> something wrong with offset or count) -- create a file of less than 32 >>>>> bytes and copy to eeprom >>>>> cd ~ >>>>> echo "1234567890" > file10 >>>>> cp -T file10 /sys/bus/w1/devices/23-000002eddd9b/eeprom >>>>> >>>>> In the data sheet you need a much smaller R[PU] to write than read >>>>> https://datasheets.maximintegrated.com/en/ds/DS2433.pdf >>>>> >>>>> On Tuesday, 29 September 2020 at 16:03:48 UTC+1 RobertCNelson wrote: >>>>> >>>>>> On Tue, Sep 29, 2020 at 9:55 AM 'Johan Lind' via BeagleBoard >>>>>> <beagl...@googlegroups.com> wrote: >>>>>> > >>>>>> > Yes, it does still show eeprom >>>>>> > >>>>>> > debian@beaglebone:~$ ls /sys/bus/w1/devices/23-000002eddd9b >>>>>> > driver eeprom id name power subsystem uevent >>>>>> > debian@beaglebone:~$ ls /sys/bus/w1/devices/ >>>>>> > 23-000002eddd9b w1_bus_master1 >>>>>> > debian@beaglebone:~$ >>>>>> > debian@beaglebone:~$ ls -al /sys/bus/w1/devices/23-000002eddd9b/ >>>>>> > total 0 >>>>>> > drwxrwxr-x 3 root gpio 0 Sep 29 14:00 . >>>>>> > drwxrwxr-x 4 root gpio 0 Sep 29 14:00 .. >>>>>> > lrwxrwxrwx 1 root gpio 0 Sep 29 14:00 driver -> >>>>>> ../../../bus/w1/drivers/w1_slave_driver >>>>>> > -rw-rw-r-- 1 root gpio 512 Sep 29 14:07 eeprom >>>>>> >>>>>> Side note, you don't' have to be root, the "gpio" group is the >>>>>> default >>>>>> for debian.. >>>>>> >>>>>> > -r--r--r-- 1 root gpio 4096 Sep 29 14:00 id >>>>>> > -r--r--r-- 1 root gpio 4096 Sep 29 14:00 name >>>>>> > drwxrwxr-x 2 root gpio 0 Sep 29 14:00 power >>>>>> > lrwxrwxrwx 1 root gpio 0 Sep 29 14:00 subsystem -> ../../../bus/w1 >>>>>> > -rw-rw-r-- 1 root gpio 4096 Sep 29 14:00 uevent >>>>>> > debian@beaglebone:~$ >>>>>> >>>>>> not sure why you can't write... >>>>>> >>>>>> Regards, >>>>>> >>>>>> -- >>>>>> Robert Nelson >>>>>> https://rcn-ee.com/ >>>>>> >>>>> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7b1e341d-8f26-4b44-90c9-3e160964f8a5n%40googlegroups.com.
