From rob at landley.net Tue Mar 1 01:44:06 2016 From: rob at landley.net (Rob Landley) Date: Mon, 29 Feb 2016 19:44:06 -0600 Subject: [Aboriginal] sh4 target In-Reply-To: References: <56D4A17F.9040100@landley.net> Message-ID: <56D4F3E6.4030106@landley.net> On 02/29/2016 05:08 PM, David Halls wrote: > > The sh4 target says it needs a massive cleanup. Was the EXPERT mode fix > > taken into the mainline kernel? > > Yes, in the 4.0 kernel. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=560b8c0ed45a > > More recently I've been working with Rich Felker (musl-libc guy), who > was just made the new superh co-maintainer. > > > I'm not completely up-to-speed on open source / patent free processors. http://www.acm.org/articles/people-of-acm/2016/david-patterson > From a few mins reading I came up with this: > > - OpenRISC: from scratch RISC. Not in mainline kernel. Can one buy a > chip yet? It's in the mainline kernel since 2011. > - RISC-V (lowrisc): UCB made it freely available but no chip yet and not > in mainline kernel. Not vanilla, but there's a subrepo at https://github.com/riscv/riscv-linux > - Super-H (sh2 and sh4): Slower than the others (maybe not sh4-64?). > Kernel has support. sh2 is now patent free, sh4 should be patent free > this year or next. SuperH was done by hitachi, which spun off a company called Renesas which eventually abandoned the stuff they inherited from Hitachi once they started doing their own stuff. J-core is a new chip design that implements the superh instruction set. (Think of it as a clean-room clone.) That became possible with the superh patents expired. I haven't benched them against each other, but j-core performs pretty well. Early versions didn't have d-cache or i-cache, and had an old dram controller that didn't do burst mode. The current ones have all that plus SMP and a bunch of DSPs. Our big initial j-core presentation was covered by https://lwn.net/Articles/647636/ And there's a little bit of wikipediage at: https://en.wikipedia.org/wiki/SuperH#J_Core > I'm taking a wild guess that the above is woefully inaccurate? Oddly enough, I'm putting together a conference track on this! http://wiki.linuxplumbersconf.org/2016:open_hardware It's not officially approved yet, but there have been encouraging noises. Here's recent-ish correspondence: On 02/17/2016 08:57 PM, Paul E. McKenney wrote: > Hello, Rob, > > Great start on the Open Hardware Microconference! Thanks. > Have you reached out to the possible interested attendees, and if so, how > many of them indicated that they were interested in attending? I pointed a few people at the page, but mostly I didn't want to invite people to something that didn't exist yet. We definitely need somebody from https://en.wikipedia.org/wiki/RISC-V (they're big in this space and Berkeley's reasonably close by). That's my must-have invite. I'd also like to ask the http://opencores.org/project,amber guys why they haven't done armv3 or v4 yet (answer is almost certainly "patents" but the ensuing discussion should be very interesting). The architect of OpenRISC (and founder of opencores) seems to live in Slovenia (https://angel.co/damjan-lampret), but maybe we could get a skype video thing going for a VHDL vs Verilog discussion if he's not too deep in the CEO lifestyle these days? It would also be nice to get somebody from https://en.wikipedia.org/wiki/LEON but again, Europe. (If the ESA isn't willing to fly somebody in, we might be able to do skype again, but in both cases the timezones are against us.) We'd also like to compare the jcore's build system with http://bitvis.no/media/19094/Register_Wizard_User_Manual.pdf and https://github.com/ucb-bar/rocket-chip#-whats-in-the-rocket-chip-generator-repository so there's more maintainers to try to track down and invite or skype. (A panel on hardware build systems would be fun...) > (We don't > need them to have travel approval at this early date -- it is sufficient > that a fair fraction of them intend to request travel approval.) > > Who else are you looking to attend? Jeff and Geoff also have lists, and Jen was an early architect of jcore who probably knows more people. (Those three are mostly in canada though, again a harder travel sell. We _should_ be able to find silicon valley people, but I'm told 8 hours down "california's most boring road" is a bit of a turn-off.) > Thenx, Paul Rob From dahalls at gmail.com Tue Mar 1 07:11:58 2016 From: dahalls at gmail.com (David Halls) Date: Tue, 1 Mar 2016 07:11:58 +0000 Subject: [Aboriginal] sh4 target In-Reply-To: <56D4F3E6.4030106@landley.net> References: <56D4A17F.9040100@landley.net> <56D4F3E6.4030106@landley.net> Message-ID: > > > http://www.acm.org/articles/people-of-acm/2016/david-patterson > > Thanks Rob - it's good to know I was woefully inaccurate :) So which of these will build under Aboriginal? Will OpenRISC and RISC-V need clang? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Tue Mar 1 19:25:48 2016 From: rob at landley.net (Rob Landley) Date: Tue, 1 Mar 2016 13:25:48 -0600 Subject: [Aboriginal] sh4 target In-Reply-To: References: <56D4A17F.9040100@landley.net> <56D4F3E6.4030106@landley.net> Message-ID: <56D5ECBC.5060505@landley.net> On 03/01/2016 01:11 AM, David Halls wrote: > > http://www.acm.org/articles/people-of-acm/2016/david-patterson > > > Thanks Rob - it's good to know I was woefully inaccurate :) > > So which of these will build under Aboriginal? Will OpenRISC and RISC-V > need clang? Probably, although the GPLv3 toolchain should work as a stopgap once I get it integrated. (It's currently like eighth on my todo stack, mobbed by things this past month even _with_ the Japan trip probably pushed back to April...) Rob From dahalls at gmail.com Wed Mar 2 00:05:27 2016 From: dahalls at gmail.com (David Halls) Date: Wed, 2 Mar 2016 00:05:27 +0000 Subject: [Aboriginal] sh4 target In-Reply-To: <56D5ECBC.5060505@landley.net> References: <56D4A17F.9040100@landley.net> <56D4F3E6.4030106@landley.net> <56D5ECBC.5060505@landley.net> Message-ID: > > > So which of these will build under Aboriginal? Will OpenRISC and RISC-V > > need clang? > > Probably, although the GPLv3 toolchain should work as a stopgap once I > get it integrated. (It's currently like eighth on my todo stack, mobbed > by things this past month even _with_ the Japan trip probably pushed > back to April...) > > Personally not in a hurry for GPLv3 toolchain. I'm still managing to build a load of packages in Aboriginal with the GPLv2 toolchain (though obviously clang would be nice :) Perl, Python, Docker and QEMU are running. Hoops I'm jumping through are here: https://github.com/davedoesdev/heddle/blob/master/image_scripts/packages sh4 looks interesting, might try it with the GPLv2 toolchain after armv6l. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahalls at gmail.com Wed Mar 2 22:47:04 2016 From: dahalls at gmail.com (David Halls) Date: Wed, 2 Mar 2016 22:47:04 +0000 Subject: [Aboriginal] segv on powerpc Message-ID: (powerpc:3) /home $ cat wup.c int main(int argc, void **argv) { return 1; } (powerpc:3) /home $ gcc wup.c (powerpc:3) /home $ ./a.out a.out[77]: unhandled signal 11 at 00000000 nip b7e75120 lr b7e75118 code 30001 SEGV Also, MIPS64 seems to have an issue with mounting > 1 disk on qemu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahalls at gmail.com Thu Mar 3 20:39:16 2016 From: dahalls at gmail.com (David Halls) Date: Thu, 3 Mar 2016 20:39:16 +0000 Subject: [Aboriginal] sh4 target In-Reply-To: References: <56D4A17F.9040100@landley.net> <56D4F3E6.4030106@landley.net> <56D5ECBC.5060505@landley.net> Message-ID: > > sh4 looks interesting, might try it with the GPLv2 toolchain after armv6l. > > Builds and runs fine but when I compile anything inside the VM: (sh4:3) / $ cat wup.c int main(int argc, char **argv) { return 0; } (sh4:3) / $ gcc wup.c (sh4:3) / $ ./a.out SEGV -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Fri Mar 4 18:32:08 2016 From: rob at landley.net (Rob Landley) Date: Fri, 4 Mar 2016 12:32:08 -0600 Subject: [Aboriginal] sh4 target In-Reply-To: References: <56D4A17F.9040100@landley.net> <56D4F3E6.4030106@landley.net> <56D5ECBC.5060505@landley.net> Message-ID: <56D9D4A8.5020003@landley.net> On 03/03/2016 02:39 PM, David Halls wrote: > sh4 looks interesting, might try it with the GPLv2 toolchain after > armv6l. > > > Builds and runs fine but when I compile anything inside the VM: > > > (sh4:3) / $ cat wup.c > int main(int argc, char **argv) > { > return 0; > } > (sh4:3) / $ gcc wup.c > (sh4:3) / $ ./a.out > SEGV Yeah, I switched that target from uClibc to musl recently and only static linking is working at the moment. (Dynamic linking segfaults, tracking down why is on my todo list.) Rob From rob at landley.net Fri Mar 4 18:37:51 2016 From: rob at landley.net (Rob Landley) Date: Fri, 4 Mar 2016 12:37:51 -0600 Subject: [Aboriginal] segv on powerpc In-Reply-To: References: Message-ID: <56D9D5FF.6090200@landley.net> On 03/02/2016 04:47 PM, David Halls wrote: > (powerpc:3) /home $ cat wup.c > int main(int argc, void **argv) > { > return 1; > } > (powerpc:3) /home $ gcc wup.c > (powerpc:3) /home $ ./a.out > a.out[77]: unhandled signal 11 at 00000000 nip b7e75120 lr b7e75118 code > 30001 > SEGV Hmmm, I thought that was working. (Again, try --static and see if that works? If static doesn't work the system can't _boot_. Dynamic still needs to be fixed, but it's nice to know where the problem is...) Was that the musl or the uClibc build, by the way? > Also, MIPS64 seems to have an issue with mounting > 1 disk on qemu. Yay, mips64 is working for you! That one bit-rotted for me, although I suspect I may be having qemu version skew there. (Tracking it down is on the todo list but somebody told me the mips64 ABI I was producing was an old obsolete one, and Rich is adding mips64 support to musl so I need to migrate to musl and redo it anyway, which is why I hadn't dug into it...) Rob From dahalls at gmail.com Sat Mar 5 07:28:01 2016 From: dahalls at gmail.com (David Halls) Date: Sat, 5 Mar 2016 07:28:01 +0000 Subject: [Aboriginal] segv on powerpc In-Reply-To: <56D9D5FF.6090200@landley.net> References: <56D9D5FF.6090200@landley.net> Message-ID: > > Hmmm, I thought that was working. (Again, try --static and see if that > works? If static doesn't work the system can't _boot_. Dynamic still > needs to be fixed, but it's nice to know where the problem is...) > Yep, -static works -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Mon Mar 7 15:57:30 2016 From: rob at landley.net (Rob Landley) Date: Mon, 7 Mar 2016 09:57:30 -0600 Subject: [Aboriginal] segv on powerpc In-Reply-To: References: <56D9D5FF.6090200@landley.net> Message-ID: <56DDA4EA.1040609@landley.net> On 03/05/2016 01:28 AM, David Halls wrote: > Hmmm, I thought that was working. (Again, try --static and see if that > works? If static doesn't work the system can't _boot_. Dynamic still > needs to be fixed, but it's nice to know where the problem is...) > > > Yep, -static works Alas, dynamic linking sometimes falls through the cracks in my testing, ever since I switched the command line utilities over to static linking. The reason I did that is it gave me about 20% speedup in package ./configure stages run under qemu. (QEMU basically acts like a processor with very high icache page fetch latency. It has to translate each executable page, and each time the page is modified it has to translate it again. Linux can keep executable pages in memory, in the page cache, but things like the dynamic linker tend to get flushed out of icache, and thus out of qemu's translation cache. Possibly unmapping the executable pages in the virtual mmu flushes the translation cache? Dunno.) Is the version you're using musl or uClibc? (If musl, I need to fix it. If uClibc, I need to convert it. :) Rob From rob at landley.net Wed Mar 9 21:06:11 2016 From: rob at landley.net (Rob Landley) Date: Wed, 9 Mar 2016 15:06:11 -0600 Subject: [Aboriginal] NFS mounting with toybox (kernel patch). Message-ID: The question came up about how to mount an nfs server with toybox. I remembered from my contract with parallels in 2010 that I used to do that: http://landley.livejournal.com/49382.html So I gave it a go, and found out that the kernel guys broke the text parsing, and I needed the attached patch (tested on linux-4.4) to fix it. Background: behind the scenes the mount -o options filter out a bunch of flag values (which get passed to the mount syscall as an integer of various MS_BLAH values or-ed together) and the rest of the values are passed through as a comma separated text string. I.E. for every filesystem EXCEPT nfs, options is a text string. But for NFS it can can either be a text string or a binary blob with the first digit being a low-ascii value indicating the version number. If the first digit ISN'T a low-ascii value, it's treated as text and parsed as text, and since there's nothing the binary blob can do that the text string _can't_, there's NO REASON to ever use the binary blob. It's there for historical reasons, and it has versions because every time they added a new option they had to extend the structure with more fields at the end, where string parsing just goes ",fruitbasket=42" and you're good. I.E. NFS was historically stupid, but had a way not to be. Naturally, the util-linux mount special cases NFS and produces a binary blob, and so does busybox. Toybox doesn't because it's STUPID, and so we're using the generic codepath which has been there forever... and bit-rotted because nobody was testing it. NFS! Anyway, with that patch to the kernel and current toybox-git, I built http://unfs3.sf.net and ran this on the host: $ echo "/home/landley (no_root_squash,insecure)" > blah.cfg $ ./unfsd -d -s -p -e $PWD/blah.cfg -l 127.0.0.1 -m 9999 -n 9999 And then in qemu: $ mount -t nfs -o ro,port=9999,mountport=9999,nolock,v3,udp \ 10.0.2.2:/home/landley /mnt And it worked. (The reason for specifying all that -m9999 stuff is telling it to use a high port number so I don't have to run the nfs server as root on the host. I'm aware there's a built-in kernel NFS server. I'm also aware there used to be a built-in kernel httpd, and they're equally bad ideas. No really, http://www.linuxjournal.com/article/4132 and it died because it was a BAD IDEA. There aren't built-in kernel SMB or DNS servers, v9fs doesn't have an in-kernel server, it's REALLY STUPID that NFS does and I'm not messing with it. Hence testing against unfs3.) If somebody wants to send the kernel patch to linux-kernel, feel free to add my signed-off-by. I'm still under the weather and really not up to dealing with... them... right now. Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: linux-fixnfs.patch Type: text/x-patch Size: 1184 bytes Desc: not available URL: From dahalls at gmail.com Wed Mar 9 23:19:24 2016 From: dahalls at gmail.com (David Halls) Date: Wed, 9 Mar 2016 23:19:24 +0000 Subject: [Aboriginal] segv on powerpc In-Reply-To: <56DDA4EA.1040609@landley.net> References: <56D9D5FF.6090200@landley.net> <56DDA4EA.1040609@landley.net> Message-ID: Standard aboriginal-1.4.5/sources/targets/powerpc (so musl). On 7 March 2016 at 15:57, Rob Landley wrote: > On 03/05/2016 01:28 AM, David Halls wrote: > > Hmmm, I thought that was working. (Again, try --static and see if > that > > works? If static doesn't work the system can't _boot_. Dynamic still > > needs to be fixed, but it's nice to know where the problem is...) > > > > > > Yep, -static works > > Alas, dynamic linking sometimes falls through the cracks in my testing, > ever since I switched the command line utilities over to static linking. > > The reason I did that is it gave me about 20% speedup in package > ./configure stages run under qemu. (QEMU basically acts like a processor > with very high icache page fetch latency. It has to translate each > executable page, and each time the page is modified it has to translate > it again. Linux can keep executable pages in memory, in the page cache, > but things like the dynamic linker tend to get flushed out of icache, > and thus out of qemu's translation cache. Possibly unmapping the > executable pages in the virtual mmu flushes the translation cache? Dunno.) > > Is the version you're using musl or uClibc? (If musl, I need to fix it. > If uClibc, I need to convert it. :) > > Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Tue Mar 29 03:58:25 2016 From: rob at landley.net (Rob Landley) Date: Mon, 28 Mar 2016 22:58:25 -0500 Subject: [Aboriginal] FYI I'm speaking in Chicago this weekend, San Diego next week. Message-ID: <56F9FD61.2050509@landley.net> On Thursday I get on a plane to go to http://flourishconf.com/2016/ in Chicago, and then on Sunday I get on a plane from there to go to http://events.linuxfoundation.org/events/embedded-linux-conference in San Diego. I'm giving two talks at each conference if anybody wants to say hi. (Then I get on a plane to go to Tokyo for 3 weeks...) Rob