i2c_read_reg on phytec-som-am335x returns wrong data from EEPROM
Hello folks,
I am having trouble reading from the 4k EEPROM via I2C on the phytec-som-am335x
board. What I want to achieve is, that the code in board.c reads a value from
EEPROM, evaluates it and then adds the value as globalvar to the userland for
scripting. However if I read the data using the function from below, the
i2c_read_reg() returns with SUCCESS but the data read to the buffer is
incorrect. I use the following snippet of code to read the data within the
physom_devices_init() function within the board.c file.
struct i2c_adapter *adapter = i2c_get_adapter(0);
if(adapter)
{
struct i2c_client client;
client.adapter = adapter;
client.addr = 0x52;
char buff[32] = {0xFF};
if(i2c_read_reg(&client, 0xFE0, buff, sizeof(buff)) > 0)
{
for( ii = 0; ii < 32; ii++ )
{
printf( "%02X", buff[ii] );
}
[...]
If I compare the EEPROM access in barebox userland, I see similar problems. All
access to the EEPROM via I2C commands only work correct, if I set the "-w" (use
16bit word access) flag. In all cases the i2c_read or i2c_write functions
return 0 (success) but the read or write was not executed correctly. See the
example, where both reads should return the same data:
barebox@Phytec phyCORE AM335x:/ i2c_read -b 0 -a 0x52 -r 0xFE0 -c 32 -w
0xaa 0xff 0xaa 0xff [...] --> OK, DATA is correct
barebox@Phytec phyCORE AM335x:/ i2c_read -b 0 -a 0x52 -r 0xFE0 -c 32
0xf3 0xfd 0x54 0x23 [...] --> RETURNVALUE = 0 (SUCCESS), BUT READ DATA IS WRONG
However if I access the EEPROM using the device definition /dev/eeprom0, as
provided by the DTSI file, the usual memory commands in userland - like memset,
mw and md - all work just fine.
What am I overlooking here? How do I configure i2c_read_reg() in C-Code to do
WORD access to the EEPROM?
Any suggestion would be appreciated.
Regards, Martin
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
AW: Barebox state on am335x-phytec-phycore-som
Hello Sam, Hello Caglar,
Thanks to you both for your quick support!
With the configuration of Caglar the state framework is directly detected by
barebox. And because my setup seems to pass the DTS from barebox to the linux
kernel the dt-utils under linux can directly read/write the state - in my case
even without the need to modify the linux dts files. Only thing left now is to
configure it all together with bootchooser :-)
Thanks again and cheers,
Martin
-Ursprüngliche Nachricht-
Von: Çağlar Kilimci [mailto:ckili...@gmail.com]
Gesendet: Freitag, 21. Juli 2017 08:47
An: Sam Ravnborg
Cc: Martin Hollingsworth ;
barebox@lists.infradead.org
Betreff: Re: Barebox state on am335x-phytec-phycore-som
Hi all,
2017-07-20 18:06 GMT+03:00 Sam Ravnborg :
> Hi Martin.
>
> On Thu, Jul 20, 2017 at 01:09:54PM +0000, Martin Hollingsworth wrote:
>> Hi,
>> I am trying to enable the barebox state framework and use it to store
>> the bootchooser variables on the am335x-phytec-phycore-som board. I
>> want to do that, so that the variables can be stored in EEPROM rather
>> than in NAND (due to write/erase cycles).
I was exactly trying to do the same thing, 3-4 months ago. There is something
missing or missleading in the documentation. First of all, you need to compile
dts for both barebox and kernel. Each time I would like to make a change, I
change both barebox dts and kernel dts. These are two similar but actually two
different dts files. As an example, in am335x-phytec-phycore-som.dtsi eeprom
device name is "eeprom" but "i2c_eeprom" in kernel's dts. Secondly,
backend-storage-type and backend-stridesize have some importance. Even if they
are written optional in the documentation, I could not run without them. You
need to calculate "backend-stridesize". Lastly, backend should be like this
"backend = <&eeprom>;". Here is the barebox patch I use:
diff --git a/arch/arm/dts/am335x-phytec-phycore-som.dtsi
b/arch/arm/dts/am335x-phytec-phycore-som.dtsi
index 0b8c454..62598cd 100644
--- a/arch/arm/dts/am335x-phytec-phycore-som.dtsi
+++ b/arch/arm/dts/am335x-phytec-phycore-som.dtsi
@@ -14,6 +14,86 @@
status = "disabled";
};
};
+
+ state {
+ magic = <0x4aaef993>;
+ compatible = "barebox,state";
+ backend-type = "raw";
+ backend = <&eeprom>;
+ backend-storage-type = "direct";
+ backend-stridesize = <0xf0>;
+bootchooser {
+system1 {
+boot{
+reg = <0x0 0x10>;
+type = "string";
+default = "system1";
+};
+default_attempts {
+reg = <0x10 0x4>;
+type = "uint32";
+default = <0x03>;
+};
+default_priority {
+reg = <0x14 0x4>;
+type = "uint32";
+default = <0x10>;
+};
+remaining_attempts {
+reg = <0x18 0x4>;
+type = "uint32";
+default = <0x03>;
+};
+priority {
+reg = <0x1c 0x4>;
+type = "uint32";
+default = <0x10>;
+};
+};
+system2 {
+boot{
+reg = <0x20 0x10>;
+type = "string";
+default = "system2";
+};
+default_attempts {
+reg = <0x30 0x4>;
+type = "uint32";
+default = <0x03>;
+};
+default_priority {
+reg = <0x34 0x4>;
+type = "uint32";
+default = <0x0f>;
+};
+remaining_attempts {
+reg = <0x38 0x4>;
+type = "uint32";
+default = <0x03>;
+};
+priority {
+reg = <0x3c 0x4>;
+type = "uint32";
+default = <0x0f>;
+};
+};
+last_chosen {
+reg = <0x40 0x4>;
+type = "uint32";
+default = <0x01>;
+};
+boot_to_be {
+reg = <0x50 0x10>;
+type = "string";
+default = "none";
+};
+update_id {
+reg = <0x60 0x10>;
+type = "string";
+default = "none";
+};
+};
+ };
};
&am33xx_pinmux {
Hope, this helps.
Sincerely,
--
Çağlar Kilimci
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Barebox state on am335x-phytec-phycore-som
Hi, I am trying to enable the barebox state framework and use it to store the bootchooser variables on the am335x-phytec-phycore-som board. I want to do that, so that the variables can be stored in EEPROM rather than in NAND (due to write/erase cycles). I am following the steps from the documentation and from the mailing list from 2016 (http://lists.infradead.org/pipermail/barebox/2016-October/028312.html). However, all entries I try to add to the DTS/DTSI files fail to compile with a syntax error, even the example dtsi entry from the documentation. Has anyone running a similar configuration and could help with some advice what has to be adapted? Can anyone recommend a good example code of the barebox state placed on EEPROM? Thanks and regards, Martin Hollingsworth ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
AW: Bootchooser - remaining_attempts
Hello Caglar, I am no expert in bootchooser, but I am currently implementing it on an imx6 board using barebox 2017-3. Regarding the first issue. These are my settings, with them target A is successfully disabled after 5 attempts and never automatically enabled again. I set the "default_xxx" values within the config-board script of my barebox default-environment. I do not set the current values (like "A.remaining_attempts") within the environment. They are generated on the first execution of bootchooser and stored within the nv variables. Do you maybe accidentally overwrite the current values on startup with some script from the environment? (happened to me ^^^). Have you tried explicitly configuring global.bootchooser.reset_attempts='' as empty, instead of not defining it? <<< from: config-board <<<<<< # General bootchooser settings global.bootchooser.disable_on_zero_attempts=0 global.bootchooser.default_attempts=5 global.bootchooser.default_priority=1 global.bootchooser.reset_attempts='' global.bootchooser.reset_priorities='' global.bootchooser.retry=1 global.bootchooser.targets="A B" # Slot "A" default configuration nv bootchooser.A.boot=A nv bootchooser.A.default_attempts=5 nv bootchooser.A.default_priority=10 # Slot "B" default configuration nv bootchooser.B.boot=B nv bootchooser.B.default_attempts=1 nv bootchooser.B.default_priority=5 <<<<<<<<<<<<<<<<<<<<<<<<<<<< Regards, Martin Hollingsworth ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Barebox Environment and State placed on eMMC boot partition
Hi folks,
I am currently enabling the bootchooser framework on my system and need some
advice on where to place the bootchooser variables so that I can read and write
them from linux (marking a successful boot).
My system uses eMMC as storage and offers an extra bootloader partition
(boot0), which is 2MB and implemented completely in hardware. Currently I split
boot0 into 1MB for barebox and 1MB for bbenv. I add the partition layouts in
barebox using devfs_add_partition("mmc3.boot0", OFFSET, SIZE,
DEVFS_PARTITION_FIXED, "mmc3.barebox0-env") in the env_init() function. The
bootchooser variables are currently stored as non-volatile variables in the
bbenv.
However under linux boot0 is shown as a raw device. To read and write bbenv I
have to first dump the env from boot0 to a file using dd and the correct
offsets, import the dump using bareboxenv from dt-utils, change the values and
do the same steps backwards until overwriting env with dd again. This works,
but it feels overly complicated, error prone due to manual offsets and my gut
tells me there might be a better solution.
If I understand chapters 6.1 and 6.2 from the documentation correctly, this can
be simplified by defining the environment or state nodes within the devicetree
file (dts). However my eMMC device is not listed in the dts and is rather
detected during runtime - hence the boot partition reports under barebox as
/dev/mmc3.boot0 and under linux as /dev/mmcblk3boot0. So now I fail to define a
"device-path = " entry for Barebox Environment and a "backend =" entry for
Barebox State within the dts file as needed by the environment and/or state
framework.
Anyone have a clue what I might be overlocking here? Someone have a barebox
tutorial handy that is running on an eMMC based device?
Thanks and cheers,
Martin
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
AW: How to overwrite an ext partition on eMMC
Hi Sascha,
huge thanks, that was just the right push in the right direction. Both
suggested methods - cp and memcpy - work fine. Problem solved.
> Why don't you use the partitions from the partition table on the device?
> I would assume you use /dev/mmc3.2 for the rootfs.
I assume you are referring to using "detect -a" to find the device, which is
then registered as mmc3.0 (for first partition). As I was struggling to write
the root.ext2 onto that device I decided to try using the devfs_add_partition()
method, as all nand flash based devices I have as reference use this approach.
However I just verified, using the detected partition works as well and it is
probably the better way of doing it, as the partitions can be moved around more
easily.
In another side question you write: "I would assume you use /dev/mmc3.2 for the
rootfs". As I currently only copy the Barebox raw onto the eMMC offset 0x400
for iMX6 it is not listed as partition under /dev/. What is the standard
approach here, should the Barebox best be a FAT32 partition so it is listed?
Thanks and regards,
Martin
--
M.Eng. Martin Hollingsworth
Medical Systems Engineering
ITK Engineering AG
Im Speyerer Tal 6
D-76761 Rülzheim
Tel.: +49 7272 7703-510
Fax: +49 7272 7703-100
mailto:martin.hollingswo...@itk-engineering.de
_
ITK Engineering AG Im Speyerer Tal 6 76761 Rülzheim
Tel.: +49 7272 7703-0 Fax: +49 7272 7703-100 mailto:i...@itk-engineering.de
http://www.itk-engineering.de
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Josef Würth
Vorstand/Executive Board: Michael Englert (Vorsitzender), Dr. Helmuth Stahl
Sitz der Gesellschaft/Registered Office: 76773 Kuhardt/Pfalz
Registergericht/Registered Court: Amtsgericht Landau, HRB 30139
USt.-ID-Nr./VAT-ID-No. DE813165046
_
-Ursprüngliche Nachricht-
Von: Sascha Hauer [mailto:s.ha...@pengutronix.de]
Gesendet: Dienstag, 5. Juli 2016 08:55
An: Martin Hollingsworth
Cc: barebox@lists.infradead.org
Betreff: Re: How to overwrite an ext partition on eMMC
On Mon, Jul 04, 2016 at 12:32:04PM +, Martin Hollingsworth wrote:
> Hello folks,
> I'm a little lost when trying to overwrite an ext partition on an eMMC
> memory inside of barebox. Your help finding the mistake is
> appreciated.
>
> My Setup:
> - Custom board with iMX6, 4GB eMMC and SD card reader (similar to
> Freescale SabreSD board)
> - Using PTXdist to build barebox 2016.05.0 and linux
> - The eMMC chip offers wear levelling, so I write a filesystem
> directly to it (using ptxdist created hd.img file flashed directly)
> - The eMMC is partitioned as follows:
> 0x0, Size 1k --> partition table
> 0x400, Size 8M --> barebox and barebox_env (offset 0x400 forced by
> iMX6) 0x800400, Size 1G --> ext filesystem with rootfs and kernel
>
> With this layout so far everything works fine. Now I would like to
> implement an update mechanism, where barebox erases the complete ext
> partition and replaces it. Under linux I would use something like dd
> and let it start at 0x800400. On barebox I have to use memcpy (thanks
> to Sascha for the hint
> http://lists.infradead.org/pipermail/barebox/2011-April/003308.html )
> and this is where I get stuck.
>
> So I first add partitions so that the memory area is listed under /dev:
> devfs_add_partition("mmc3", 0x0, SZ_1K, DEVFS_PARTITION_FIXED,
> "mmc3.partable"); c("mmc3", SZ_1K, SZ_8M,
> DEVFS_PARTITION_FIXED, "mmc3.barebox"); devfs_add_partition("mmc3", (
> SZ_1K + SZ_8M ), SZ_1G, DEVFS_PARTITION_FIXED, "mmc3.rootfs");
Why don't you use the partitions from the partition table on the device?
I would assume you use /dev/mmc3.2 for the rootfs.
>
> This works for clearing the partitions data using memset:
> memset -d /dev/mmc3.rootfs 0x0 0x0 1073741824
>
> However when I try to copy the root.ext2 filesystem onto this memory area, I
> can't mount the partition afterwards:
> memcpy -s /mnt/sd/root.ext2 -d /dev/mmc3.rootfs 0 536870912
memcpy needspositional arguments. With the above
536870912 is the offset in the destination file and not the size to copy. What
you want is:
memcpy -s /mnt/sd/root.ext2 -d /dev/mmc3.rootfs 0 0 536870912
Anyway, you don't need memset/memcpy at all to accomplish your task, the
following should do it:
cp /dev/zero /dev/mmc3.rootfs
cp /mnt/sd/root.ext2 /dev/mmc3.rootfs
Also I have never seen that it's necessary to erase the remaining parts of a
partition when the new image is smaller than the partition.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.d
How to overwrite an ext partition on eMMC
Hello folks,
I'm a little lost when trying to overwrite an ext partition on an eMMC memory
inside of barebox. Your help finding the mistake is appreciated.
My Setup:
- Custom board with iMX6, 4GB eMMC and SD card reader (similar to Freescale
SabreSD board)
- Using PTXdist to build barebox 2016.05.0 and linux
- The eMMC chip offers wear levelling, so I write a filesystem directly to it
(using ptxdist created hd.img file flashed directly)
- The eMMC is partitioned as follows:
0x0, Size 1k --> partition table
0x400, Size 8M --> barebox and barebox_env (offset 0x400 forced by iMX6)
0x800400, Size 1G --> ext filesystem with rootfs and kernel
With this layout so far everything works fine. Now I would like to implement an
update mechanism, where barebox erases the complete ext partition and replaces
it. Under linux I would use something like dd and let it start at 0x800400. On
barebox I have to use memcpy (thanks to Sascha for the hint
http://lists.infradead.org/pipermail/barebox/2011-April/003308.html ) and this
is where I get stuck.
So I first add partitions so that the memory area is listed under /dev:
devfs_add_partition("mmc3", 0x0, SZ_1K, DEVFS_PARTITION_FIXED,
"mmc3.partable");
devfs_add_partition("mmc3", SZ_1K, SZ_8M, DEVFS_PARTITION_FIXED,
"mmc3.barebox");
devfs_add_partition("mmc3", ( SZ_1K + SZ_8M ), SZ_1G, DEVFS_PARTITION_FIXED,
"mmc3.rootfs");
This works for clearing the partitions data using memset:
memset -d /dev/mmc3.rootfs 0x0 0x0 1073741824
However when I try to copy the root.ext2 filesystem onto this memory area, I
can't mount the partition afterwards:
memcpy -s /mnt/sd/root.ext2 -d /dev/mmc3.rootfs 0 536870912
mount /dev/mmc3.rootfs /mnt/mmc/
mount: No such file or directory
I am questioning my approach, as I am not sure if it is correct to write an
ext2 file directly to memory. Or am I making some other basic mistake here?
Thanks for your help and cheers,
Martin
--
M.Eng. Martin Hollingsworth
Medical Systems Engineering
ITK Engineering AG
Im Speyerer Tal 6
D-76761 Rülzheim
Tel.: +49 7272 7703-510
Fax: +49 7272 7703-100
mailto:martin.hollingswo...@itk-engineering.de
_
ITK Engineering AG Im Speyerer Tal 6 76761 Rülzheim
Tel.: +49 7272 7703-0 Fax: +49 7272 7703-100 mailto:i...@itk-engineering.de
http://www.itk-engineering.de
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Josef Würth
Vorstand/Executive Board: Michael Englert (Vorsitzender), Dr. Helmuth Stahl
Sitz der Gesellschaft/Registered Office: 76773 Kuhardt/Pfalz
Registergericht/Registered Court: Amtsgericht Landau, HRB 30139
USt.-ID-Nr./VAT-ID-No. DE813165046
_
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
