awk problem on pistachio (24kc+24kf)

Daniel Golle daniel at makrotopia.org
Fri Nov 5 06:24:16 PDT 2021


On Tue, Nov 02, 2021 at 11:49:02PM +0100, Hauke Mehrtens wrote:
> Hi,
> 
> On pistachio sysupgrade in master fails and I got down to a problem with
> awk. This command returns different results on pistachio compared to other
> targets:
>    echo "mtd2: 00002000 00001000 \"uEnv\"" | awk -F: '{print $1}'
> 
> When I execute this on an lantiq/xrx200 or mt7622 device I get this:
>    mtd2
> 
> When I execute this command on pistachio in master I get this:
>    mtd2: 00002000 00001000 "uEnv"

So the separator doesn't match. Maybe another integer bitwidth issue,
ie. comparing char aka. uint8 with uint16 or uint32 having their upper
bits not zero'd because only the first 8 bit of the register were
loaded, leaving old value in the remaining 8 or 24 bits?

Another interesting thing would be to try moving the position of the
':' as any variation in the result would be a clear hint towards
MIPS unaligned access being the problem...

There are also hints on kernel mailing lists that Ingenic
implementation of MIPS interAptiv somehow differs in how cpu cache has
to be dealt with in combination with some memory access instructions
(I didn't get into the details and can't find it again atm)

Does this also happen when using `cut -d: -f1` instead of the `awk`
call (not that this would solve anything, but if it happens also when
using `cut` it would be easier to debug as `cut` is much less complex
than `awk`, both are busybox applets).

> 
> This is part of the find_mtd_index() function used for sysupgrade.
> 
> The pistachio target is MIPS 32 little Endian with hardware floating point
> activated. This target is not much used, nobody complained that it did not
> boot for multiple months, but I am interested why it fails.

Unfortunately my pistachio board got stolen from my car 2 years ago
(among with tons of other equipment I had boxed up there).

> I also see this problem with OpenWrt master from August 2020 which was still
> on the board.

So at least this is not due to recent GCC or musl updates...
(that doesn't make it better though)



More information about the openwrt-devel mailing list