Re: [LEDE-DEV] [PATCH] uqmi: Fix for big endian arch

[Oskari Lemmelä]

Hi,

Here is better fix for endianness issue.

Tested on both ar71xx (big) and sunxi (little).


Use memcpy instead of pointer casting

Signed-off-by: Oskari Lemmelä 
---
 data/gen-code.pl | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/data/gen-code.pl b/data/gen-code.pl
index f45d28a..1af143c 100755
--- a/data/gen-code.pl
+++ b/data/gen-code.pl
@@ -13,22 +13,22 @@ my $varsize_field;
 my %tlv_get = (
gint8 => "*(int8_t *) get_next(1)",
guint8 => "*(uint8_t *) get_next(1)",
-   gint16 => "le16_to_cpu(*(uint16_t *) get_next(2))",
-   guint16 => "le16_to_cpu(*(uint16_t *) get_next(2))",
-   gint32 => "le32_to_cpu(*(uint32_t *) get_next(4))",
-   guint32 => "le32_to_cpu(*(uint32_t *) get_next(4))",
-   gint64 => "le64_to_cpu(*(uint64_t *) get_next(8))",
-   guint64 => "le64_to_cpu(*(uint64_t *) get_next(8))",
-	gfloat => "({ uint32_t data = le32_to_cpu(*(uint32_t *) get_next(4)); 
float _val; memcpy(&_val, &data, sizeof(_val)); _val; })"
+	gint16 => "({ uint16_t var; memcpy(&var, get_next(2), 2); 
le16_to_cpu(var); })",
+	guint16 => "({ uint16_t var; memcpy(&var, get_next(2), 2); 
le16_to_cpu(var); })",
+	gint32 => "({ uint32_t var; memcpy(&var, get_next(4), 4); 
le32_to_cpu(var); })",
+	guint32 => "({ uint32_t var; memcpy(&var, get_next(4), 4); 
le32_to_cpu(var); })",
+	gint64 => "({ uint64_t var; memcpy(&var, get_next(8), 8); 
le64_to_cpu(var); })",
+	guint64 => "({ uint64_t var; memcpy(&var, get_next(8), 8); 
le64_to_cpu(var); })",
+	gfloat => "({ float var; memcpy(&var, get_next(4), 4); 
le32_to_cpu(var); })"

 );

 my %tlv_get_be = (
-   gint16 => "be16_to_cpu(*(uint16_t *) get_next(2))",
-   guint16 => "be16_to_cpu(*(uint16_t *) get_next(2))",
-   gint32 => "be32_to_cpu(*(uint32_t *) get_next(4))",
-   guint32 => "be32_to_cpu(*(uint32_t *) get_next(4))",
-   gint64 => "be64_to_cpu(*(uint64_t *) get_next(8))",
-   guint64 => "be64_to_cpu(*(uint64_t *) get_next(8))",
+	gint16 => "({ uint16_t var; memcpy(&var, get_next(2), 2); 
be16_to_cpu(var); })",
+	guint16 => "({ uint16_t var; memcpy(&var, get_next(2), 2); 
be16_to_cpu(var); })",
+	gint32 => "({ uint32_t var; memcpy(&var, get_next(4), 4); 
be32_to_cpu(var); })",
+	guint32 => "({ uint32_t var; memcpy(&var, get_next(4), 4); 
be32_to_cpu(var); })",
+	gint64 => "({ uint64_t var; memcpy(&var, get_next(8), 8); 
be64_to_cpu(var); })",
+	guint64 => "({ uint64_t var; memcpy(&var, get_next(8), 8); 
be64_to_cpu(var); })",

 );

 sub gen_tlv_parse_field() {
--
2.7.4


On 04/01/2018 05:22 PM, Oskari Lemmela wrote:

leXX_to_cpu function messes up get_next value in big endian arch.

Signed-off-by: Oskari Lemmelä 
---
  data/gen-code.pl | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/data/gen-code.pl b/data/gen-code.pl
index f45d28a..cf46b67 100755
--- a/data/gen-code.pl
+++ b/data/gen-code.pl
@@ -13,12 +13,12 @@ my $varsize_field;
  my %tlv_get = (
gint8 => "*(int8_t *) get_next(1)",
guint8 => "*(uint8_t *) get_next(1)",
-   gint16 => "le16_to_cpu(*(uint16_t *) get_next(2))",
-   guint16 => "le16_to_cpu(*(uint16_t *) get_next(2))",
-   gint32 => "le32_to_cpu(*(uint32_t *) get_next(4))",
-   guint32 => "le32_to_cpu(*(uint32_t *) get_next(4))",
-   gint64 => "le64_to_cpu(*(uint64_t *) get_next(8))",
-   guint64 => "le64_to_cpu(*(uint64_t *) get_next(8))",
+   gint16 => "({ int16_t value = *(int16_t *) get_next(2); int16_t _val = 
le16_to_cpu(value); _val;})",
+   guint16 => "({ uint16_t value = *(uint16_t *) get_next(2); uint16_t _val = 
le16_to_cpu(value); _val;})",
+   gint32 => "({ int32_t value = *(int32_t *) get_next(4); int32_t _val = 
le32_to_cpu(value); _val;})",
+   guint32 => "({ uint32_t value = *(uint32_t *) get_next(4); uint32_t _val = 
le32_to_cpu(value); _val;})",
+   gint64 => "({ int64_t value = *(int64_t *) get_next(8); int64_t _val = 
le64_to_cpu(value); _val;})",
+   guint64 => "({ uint64_t value = *(uint64_t *) get_next(8); uint64_t _val = 
le64_to_cpu(value); _val;})",
gfloat => "({ uint32_t data = le32_to_cpu(*(uint32_t *) get_next(4)); float _val; 
memcpy(&_val, &data, sizeof(_val)); _val; })"
  );
  



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Bump tools/mtd-utils

[Hauke Mehrtens]

On 04/05/2018 11:58 AM, Syrone Wong wrote:
> Hi,
> 
> I closed my PR due to
> https://github.com/openwrt/openwrt/commit/56d0dd56e9c6efa79d03b6417dc0ae5449343001.
> I tried to understand patches in tools/mtd-utils but failed. I
> appreciate if anyone keeps going.
> 
> 
> Best Regards,
> Syrone Wong
> 
> 
> On Thu, Apr 5, 2018 at 4:59 PM, Koen Vandeputte
>  wrote:
>> Hi Syrone,
>>
>> Following your patch to update mtd-utils in packages, currently staged in
>> Hauke's tree:
>> Are you also planning to upgrade mtd-utils within tools/ too?
>>
>> I'm asking to avoid double effort on this.
>>
>>
>> Some background info:
>>
>> Reason for me to update this is trying to fix a ubi issue in imx6:
>>
>> - Build OpenWrt master
>> - Use Imagebuilder to add/alter some files (ex: some files in /etc/config)
>> - Flash this image
>>
>> --> When the board boots for the first time, all is ok and UBI initializes
>> properly.
>> --> On the 2nd boot, nearly all files that got added/altered during the
>> imagebuild phase are now corrupted.
>>
>> Repro rate: 100%
>>
>> Looking at the mtd-utils log, a lot got changed regarding ubi since 1.5.2 ..
>>
>>
>>
>> Thanks,
>>
>> Koen
Hi,

I had a closer look at the jffs2 changes and I think they are only used
by the mtd-utils in tools/ and we only added the to packages to keep
them in sync. The jffs2 tools are not packaged into the package.
I did this change becasue I saw some compile warnings when looking at
the patches which bring it to version 2.0.1.

My patch to 130-lzma_jffs2.patch is more or less unrelated to the to the
bump to the version 2.0.1, I would support if also the version in tools
gets to this new version.

Probably the patches should be synced between the two mtd-utils versions.

Hauke

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev