Multiple issues for Linksys NSLU2 (evbarm, armeb) NetBSD in HEAD date since June 2014

[Eddy Petrișor <eddy.petrisor+netbsd.org%gmail.com@localhost>]

Hello,

I have managed to test the patch proposed by Nick up to code as recent
as June 2014, and it also applied cleanly on latest HEAD when I tried
first, so I think is safe to be committed in CVS.

On the other hand, on code more recent than July 2014 [1] I have seen
multiple different issues preventing either successful build or
execution or more recent code.

Because the issues were not fixed very close to the moment when they
were broken and they might have piled up on each other I am unsure if
any of the errors I am seeing in the are still present in the latest
HEAD, so I am asking if somebody more knowledgeable than me can
confirm if either of the problems below should be fixed for
evbarm/armeb in HEAD, or if they can be fixed in HEAD (such as problem
1)):



1) Build failure on evbarm/armeb (confirmed in HEAD from 2015-05-19 22:45:57)

ails to build with:
In file included from
/home/eddy/usr/src/netbsd/net/src/crypto/external/bsd/openssl/lib/libcrypto/arch/arm/aes-armv4.S:35:0:
/home/eddy/usr/src/netbsd/net/src/crypto/external/bsd/openssl/dist/crypto/arm_arch.h:63:5:
error: #error "can't build universal big-endian binary"
     ^
nbmkdep: compile failed.
*** [aes-armv4.d] Error code 1



2) kernel diagnostic assertion fail (confirmed in HEAD from 2014-07-21
02:08:43 UTC+3)

init: copying out path `/sbin/init' 11
panic: kernel diagnostic assertion "*ptep == opte" failed: file
"./arm/arm32/pmap.h", line 575 0x11dd605b [*0xc000a004] != 0
Stopped in pid 1.1 (init) at    netbsd:cpu_Debugger+0x4:        bx      r14



3) Fatal kernel mode data abort: 'External Linefetch Abort (P)'
(confirmed in code from HEAD from 2014-06-15 05:27:15 UTC+3)

Fatal kernel mode data abort: 'External Linefetch Abort (P)'
trapframe: 0xc34f1e78
FSR=00000406, FAR=Invalid,  spsr=60000053
r0 =bfffefe8, r1 =00000000, r2 =c34f0000, r3 =c03bf880
r4 =c0458b18, r5 =bfffeff5, r6 =bfffefe8, r7 =00000000
r8 =00000001, r9 =00000000, r10=c054366c, r11=c34f1fac
r12=00000062, ssp=c34f1ecc, slr=c02f1d28, pc =c02f1d38

Stopped in pid 1.1 (init) at    netbsd:start_init+0x204:        mov     r0, r6



I am willing to test any provided patches, as I did with Nick's patch.


[1] This was slower than before because the power supply for my NetBSD
NSLU2 broke some 2 weeks ago, yet was somewhat working (the OS would
start eventually after resetting 5-10 times during NetBSD
initialization). Finally it died on Saturday and I bought a new one
today, so I am still bisecting to find when exactly was the next
breakage introduced (Fatal kernel mode data abort: 'External Linefetch
Abort (P)')

2015-05-19 18:16 GMT+03:00 Eddy Petrișor <eddy.petrisor+netbsd.org%gmail.com@localhost>:
> Hi Nick,
>
> This is just an update to tell you I am using the patch you provided to find
> out which is the most recent working tree which works with the just the
> patch applied.
>
> My temporary conclusion is the patch is necessary on top of latest HEAD for
> armbe systems to work, but at least another patch is needed to make the
> latest HEAD work for the Linksys NSLU2.
>
> My plan is to identify all other issues preventing me to run the latest HEAD
> on the slug, and to purpose patches, if I can do that.
>
> Pe 17 mai 2015 12:32 a.m., "Eddy Petrișor"
> <eddy.petrisor+netbsd.org%gmail.com@localhost> a scris:
>>
>> 2015-05-16 23:51 GMT+03:00 Eddy Petrișor
>> <eddy.petrisor+netbsd.org%gmail.com@localhost>:
>> > 2015-05-16 19:24 GMT+03:00 Nick Hudson <skrll%netbsd.org@localhost>:
>> >> On 05/16/15 16:57, Eddy Petrișor wrote:
>> >>>
>> >>> Pe 16 mai 2015 3:23 p.m., "Nick Hudson" <skrll%netbsd.org@localhost> a scris:
>> >>>> I think netbsd-elf.h should change - see diff. Can you test?
>> >>>
>> >>> Yes. Should I apply this over the latest HEAD?
>> >>
>> >>
>> >> yes, that's right.
>> >
>> > There are some other issues with the latest code. Probably the armeb
>> > port was broken even more meanwhile.
>> > Should I try the patch on an older version of HEAD, or will provide
>> > another patch for this issue, too?
>>
>>
>> Sorry for the previous message, I got that error on an older code.
>> Please note that to minimize the build time I have the following set
>> in by build script:
>>
>> export NOGCCERROR=yes
>> export SLOPPY_FLIST=yes
>> export MKMAN=no
>> export MKDOC=no
>> export MKINFO=no
>> export MKNLS=no
>> export MKHTML=no
>> export MKCATPAGES=no
>>
>>
>>
>> What I get on the current code is:
>>
>> [...]
>>         build/genmodes.o build/errors.o
>> ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
>> c++   -O -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions
>> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
>> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
>> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
>> -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc  -o
>> build/gengtype \
>>         build/gengtype.o build/errors.o build/gengtype-lex.o
>> build/gengtype-parse.o build/gengtype-state.o build/version.o
>> ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a
>> build/gengtype.o: In function `adjust_field_type(type*, options*)':
>> gengtype.c:(.text+0x1b66): undefined reference to `lexer_line'
>> gengtype.c:(.text+0x1b9d): undefined reference to `lexer_line'
>> gengtype.c:(.text+0x1cab): undefined reference to `lexer_line'
>> gengtype.c:(.text+0x1d64): undefined reference to `lexer_line'
>> gengtype.c:(.text+0x1ded): undefined reference to `lexer_line'
>> build/gengtype.o:gengtype.c:(.text+0x1e30): more undefined references
>> to `lexer_line' follow
>> build/gengtype-parse.o: In function `require2(int, int)':
>> gengtype-parse.c:(.text+0x1a7): undefined reference to `yylex(char
>> const**)'
>> build/gengtype-parse.o: In function `require(int)':
>> gengtype-parse.c:(.text+0x242): undefined reference to `yylex(char
>> const**)'
>> build/gengtype-parse.o: In function `string_seq()':
>> gengtype-parse.c:(.text+0x332): undefined reference to `yylex(char
>> const**)'
>> build/gengtype-parse.o: In function `consume_balanced(int, int)':
>> gengtype-parse.c:(.text+0x384): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0x41d): undefined reference to `yylex(char
>> const**)'
>> build/gengtype-parse.o:gengtype-parse.c:(.text+0x445): more undefined
>> references to `yylex(char const**)' follow
>> build/gengtype-parse.o: In function `type(options**, bool)':
>> gengtype-parse.c:(.text+0x803): undefined reference to `lexer_line'
>> gengtype-parse.c:(.text+0x823): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0x855): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0x889): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0x8cb): undefined reference to `lexer_line'
>> gengtype-parse.c:(.text+0x8e1): undefined reference to `lexer_line'
>> gengtype-parse.c:(.text+0x903): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0x93c): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0x96e): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0x9e5): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0xa53): undefined reference to `yylex(char
>> const**)'
>> build/gengtype-parse.o:gengtype-parse.c:(.text+0xa80): more undefined
>> references to `yylex(char const**)' follow
>> build/gengtype-parse.o: In function `type(options**, bool)':
>> gengtype-parse.c:(.text+0xbf9): undefined reference to `lexer_line'
>> gengtype-parse.c:(.text+0xc2d): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0xc56): undefined reference to `yylex(char
>> const**)'
>> gengtype-parse.c:(.text+0xc90): undefined reference to `lexer_line'
>> gengtype-parse.c:(.text+0xcb6): undefined reference to `lexer_line'
[..]