awk problem on pistachio (24kc+24kf)

[Hauke Mehrtens]

On 11/5/21 2:24 PM, Daniel Golle wrote:
> 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...

Moving the position of the ":" did not help.

> 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)

I tried this on the InterAptiv core used by Maxlinear in MIPS BE mode 
with an OpenWrt 19.07 user space and do not see the problem there.

When I build OpenWrt without floating point and use it on the pistachio 
it still fails.

> 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).

With cut I do not see the problem:

root at OpenWrt:/# echo "mtd2: 00002000 00001000 \"uEnv\"" | cut -d: -f1
mtd2

>> 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)

This could be a CPU problem. I will just ignore this problem for now and 
take care of other stuff as pistachio is not used much.

Hauke