#milkymist IRC log for Sunday, 2013-01-06

Fallenouwpwrak: half mmu design related talks took place on mailing list, the other half here on IRC :/12:59
wpwraknice balance :)13:12
Fallenouwell, approximately :p13:13
Fallenoumwalle: pong me when you get on irc, I'm trying to get a simulation working with your mmu branch :)13:14
Fallenoudoes anybody here have experience in NetBSD kernel dev ?13:15
Fallenoudoes someone have a comment about "porting NetBSD kernel on the MMU-enabled Milkymist SoC" instead of porting Linux ?13:16
FallenouNetBSD seems rather clean, at least the user space part13:16
Fallenouand it supports a *lot* of architectures13:17
FallenouSo I assume it's easier to add a new architecture to NetBSD, since a lot of people did it13:17
Fallenouand it seems to be one of the design "goal" of NetBSD, being able to port it to a lot of systems13:18
Fallenouso I assume it must be well organized for porting, with documentation13:18
Fallenouone thing in favor of Linux is that there is already a mmu-less Linux port to lm3213:20
larscand Linux supports more architectures than NetBSD13:23
Fallenouoh really ?13:24
larscyes13:25
larsc~3013:25
Fallenoudo you count all arm soc ?13:26
larscnetbsd has like ten or so13:26
larscno13:26
Fallenouftp://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/13:26
Fallenouhttp://www.netbsd.org/releases/formal-6/NetBSD-6.0.1.html13:27
Fallenoudown the page " System supported by NetBSD 6.01"13:27
larsccount the cpu archs13:28
FallenouIndeed there is a lot of "systems" which are MIPS13:30
Fallenouand a few ppc13:30
larscand a few arm13:31
Fallenouso not a good idea ?13:31
larscI think it easier to port a new platform to Linux, but my opinion is probably biased13:32
Fallenouanyway in a marketing point of view, Linux is better13:33
Fallenou"nobody" cares about NetBSD I guess13:33
Padawan-Fallenou: I would love to see NetBSD running on the MMU-enabled Milkymist SoC instead of Linux. :-)14:39
Fallenouoh, one in favor !14:48
Fallenoulet's have a poll then :p14:49
larscwell if you think it is a nice exercise, I'd say just do it14:49
Fallenouwell it could be a lot of fun, but I guess I should stay realistic about this14:51
Fallenoutaking into account the little amount of day/night time I can spend on such a project14:51
Padawan-Fallenou: NetBSD is *very* well documented.14:53
FallenouI guess even if NetBSD looks very well documented and very clean, maybe I will stay on Linux14:53
Padawan-And people are very competent on exotic architectures. They write good code, mostly.14:53
Padawan-Like in OpenBSD, btw. You find the same kind of people.14:53
FallenouPadawan-: the thing is, lm32 is already supported by Linux14:53
FallenouI don't know if the code is good quality though14:54
Padawan-So if you're going after elegant way of doing things, try to port OpenBSD or NetBSD on it, for instance.14:54
Fallenouthe cool thing is that we could then say about Milkymist SoC "Of course it runs NetBSD"14:55
Fallenou;)14:55
Padawan-Yes. ;-)14:55
Fallenoufamily meeting, be back later !15:00
hozerbut I want OpenBSD on milkymist, it has Theo security! ;)17:07
hozeractually, one thing I liked about OpenBSD (several years ago) was that it had kerberos and arla afs client installed in the base system17:08
hozerit occurs to me that the reason Linux has been a success is because of the requirement for GPL drivers17:09
hozerand if we're running on GPL *hardware*, there's no such reason why linux would be any better than bsd17:09
hozeralso, what about http://en.wikipedia.org/wiki/DragonFly_BSD17:13
larscI don't think GPL drivers are reason for Linux's success17:24
hozerwhy17:33
hozerWhy did Google choose linux over *Bsd for android17:34
larscwell certainly not because of the license17:35
hozerI'd argue it's because if you want to make some embedded system run linux, you are compelled to release the drivers and book code, and this leads to more embedded systems using that OS17:35
hozers/book/boot/17:35
larscthere were and are quite a few companies who kept their Linux derivatives closed for years17:36
hozerwho, do you have evidence?17:37
hozerThere are also a couple of high-profile companies that got caught on the wrong side of a license agreement and ended up creating the basis for OpenWRT17:38
larscwhat actually got a lot of them to contribute to upstream was the realisation that it is actually beneficial for them to do this17:38
hozerright, but the first step to getting them to contribute to upstream is the understanding that all their competitors are *compelled* by the software license to distribute any changes they make17:39
hozerthis is not the case in *BSD17:39
larscwell, the license doesn't force you to contribute to upstream17:39
hozerno but contributing to upstream in BSD gives your competitor an advantage17:40
larscyou can still do your yearly codedump with a million lines patch17:40
larscand be compliant with the license17:40
hozersure17:40
larscwhy you want to contribute to upstream is because you don't have to rebase your patches for each new kernel release17:41
hozerright17:41
hozerand contributing to upstream provides a competitive advantage with GPL code17:41
larscbut from your point of view not with a BSD style license?17:42
hozercontributing to upstream on BSD can be a competitive disadvantage just as much as it helps17:42
larschow?17:43
hozerright, because the competitor that decided to just suck in everyone else's changes, change 5 lines, and market it as ... oh say IOS ...17:43
larscand?17:43
hozerwell, by contributing to upstream without the GPL protection, you just handed a bunch of stuff over to someone who doesn't give back17:44
larscthey don't give back their 5 lines17:44
larscwhich nobody wants anyway17:44
hozerbut here's the problem..17:44
hozerUnless you start reverse-engineering the iPod, you have no idea if it was 5 lines, or 500017:45
hozerand even then, those lines are clearly Apple's property17:45
hozerif it was GPL, then those 5, or 5000 lines benefit the community commons17:45
hozereven if it was a million line coredump17:45
larscthis presumes that somebody would want to go through that patch and pick out the goodies17:46
hozerwell, the fact is someone bothers to reverse-engineer the iPod.17:47
hozerso if there was a good reason, then someone would definitely go through that million line coredump17:48
larscbut that someone is not another company which contributed code to the BSD kernel17:48
larscor Linux kernel17:48
hozersome bored student, or someone who bought the hardware that million line coredump runs on17:48
larscyea, but you argued that this creates a competetive advantage17:49
hozeryes, because the coredump requirement creates a level playing field17:50
hozerso you can coredump, and be stupid, and some student will reverse engineer your stuff17:50
hozer(or not coredump, like apple, and some students will reverse engineer it regardless)17:50
hozeror contribute to upstream source and reduce your development time the next time around17:50
larscwhich benefits you, not your competitor17:52
hozeryes, but **only if** there's that 'level playing field coredump' requirement17:52
larscno17:52
Action: lekernel votes for BSD17:52
hozerSo then why don't Apple and Microsoft release the source for their mobile OSes17:53
Fallenou=)17:53
hozerwell, let me know when I can buy a BSD phone17:53
larschozer: why should they?17:53
Fallenouwell you can17:53
lekernelbuy an iPhone17:53
lekernel:)17:53
FallenouI met a french guy who was running NetBSD on a lot of devices17:54
hozerno, BSD phone with full source that I can recompile17:54
Fallenoua tablet17:54
Fallenouand I think his phone was running netbsd17:54
lekernelfunctionality > freedom17:54
larscapple is their own upstream17:54
lekernelsorry17:54
hozerso I expect I'll get a functional BSD phone after I've built an open-source hardware platform17:54
larscsame for microsoft17:54
hozerright17:55
hozerGoogle could have hired people and written their own OS, or ripped off NetBSD, but they decided to leverage the linux upstream17:55
larscbut not because of the GPL17:55
hozeroh?17:55
hozerWhat makes you think google would have released the OS kernel if there wasn't a requirement for it?17:56
hozeror all the phone vendors?17:56
lekernelbtw http://mickey.lucifier.net/ expressed interest in porting BSD to LM32 - you may want to ping him ...17:56
larschozer: If they had written their own OS they probably wouldn't have done so17:57
larscMost of the android changes were out of upstream for a long time17:57
hozeranyway, let's get BSD on lm32/milkymist. All of this nonsense goes away if you have GPL hardware ;)17:58
larscand quite a bit of it still is17:58
sb0so, you think the MMU is ready for attempting to port a serious OS?18:22
Fallenouwell, it seems so but I didn't run any test since Michael's 50+ patches18:27
FallenouI tried yesterday to run one but the simulation failed18:28
FallenouOnce I can see a few test passing I think we can start working on OS side18:28
FallenouBut I assume Michael does not push tests that don't pass :)18:31
sb0iirc we can run at 200MHz in the kintex-7. then it becomes interesting for a large OS...18:33
FallenouI guess kintex is crazy expensive ?18:34
Fallenoubut yes 200 MHz could be nice :)18:34
Fallenoumwalle: are you using a patched iverilog? Mine is 0.9.2 official debian squeeze package18:47
Fallenouhum hum just got iverilog to segfault19:27
Fallenounice19:27
Fallenouit seems pc_a is cycling through 0, 1, 2, 319:34
Fallenoufirst it's fetched from testbench SRAM19:35
Fallenouand then only from I cache19:35
Fallenouso no more wishbone transaction afterward19:35
sb0it's expensive, but not crazy expensive19:37
Fallenouit cannot be ordered from Farnell :x19:38
Fallenouhum maybe digi-key19:39
Fallenouit seems entry price is $13219:40
Fallenoufor IC FPGA 70K KINTEX-7 484FBGA19:41
Fallenouhum it seems there is a branch to address 019:46
Fallenoubranch_target_m == 0x019:46
Fallenouwith branch_taken_m == 119:46
Fallenouaouch ok, it's my fault, I compiled with rtems toolchain ...19:48
FallenouI got crap in my generated binary19:48
Fallenoufirst instruction is : ret (from rtems_provides_crt0 function)19:49
Fallenoudoes not help :)19:49
Fallenou*brb*19:50
Fallenouso I needed to add -nostdlib flag to linker in the Makefile to use rtems toolchain correctly with no crap in the output20:29
Fallenouyeah, tests are running and outputing understandable things :)20:30
FallenouI can see a lot of "FAILED" though :x20:30
wpwrakyou may want to check the binary for additional undesirables. depends on what your linker script does and what output format you choose20:35
Fallenoufirst output format is .o then linked to a .elf and then objcopy'd using -O verilog to .vh file20:37
FallenouI added -lgcc to linker just in case20:37
Action: Fallenou really does not want to regenerate a bare-metal elf toolchain20:39
FallenouI had a quick look at the generated code, at least the first instructions are correct.20:40
Fallenouall exception vectors are in place20:40
Fallenouand then there is the main, it seems ok20:40
mwallewhoa, what a backlog :)21:31
mwallebbl, dexter :)21:31
sb0Fallenou, tried clang/lllvm?21:31
sb0mwalle, the patch is in the second email from Fallenou  (with same subject)21:34
Fallenousb0: for lm32? nop21:34
sb0Fallenou, build instructions are in milkymist-ng readme21:35
sb0if you want to give it a try21:35
Fallenouoh cool21:35
sb0some stuff is still missing and the generated code quality isn't quite good yet, but it should be fine for simple/low-perf apps21:35
FallenouI may give it a try21:35
sb0it doesn't build atm, I'm fixing it21:36
sb0moment ...21:36
Fallenoufor simple unit testing it could be great21:36
Fallenou22:31 < mwalle> whoa, what a backlog :) < yes a lot of talk these days :) welcome back!21:36
Fallenoumwalle: about my previous complaints about not being able to simulate your mmu and mmu-cleanup branches, forget about it, I found the problem (which is solved in the patch I sent btw)21:40
sb0where is the mmu-aware lm32 source?21:41
Fallenoumost up to date is there: https://github.com/mwalle/milkymist/tree/mmu21:41
Fallenouit contains what I previously commited in my github account + a lot of commits from Michael21:42
Action: Fallenou is going to bed21:43
Fallenoutomorrow is the first day of work since december the 27th :)21:44
Fallenouit will be hard =)21:44
FallenouI had a lot of fun during my holidays thanks to sb0 :p21:45
Fallenougn8!21:45
mwallesb0: github.com/milkymist/lm32 << there should be the up2date code22:49
mwallei guess i should delete the other repos22:49
sb0yeh22:49
sb0all your mmu commits are there?22:51
sb0in milkymist/lm3222:51
mwallesb0: not the history, because i've rewrote it while cleaning up the patches22:52
GitHub65[milkymist] mwalle pushed 1 new commit to mmu: https://github.com/mwalle/milkymist/commit/453a05f4ff306a01170e912f49e1dfb5a7105e4a23:00
GitHub65milkymist/mmu 453a05f Michael Walle: replace README with EOD notice...23:00
GitHub96[milkymist] mwalle force-pushed mmu from 453a05f to 9621b8a: https://github.com/mwalle/milkymist/commits/mmu23:02
GitHub96milkymist/mmu 9621b8a Michael Walle: replace README with EOD notice...23:02
mwallesb0: lets keep repo for historical reasons and put a big fat warning to it23:02
GitHub173[milkymist] mwalle deleted mmu-cleanup at f863a1e: https://github.com/mwalle/milkymist/commit/f863a1e23:03
GitHub148[milkymist] mwalle deleted lm32-simulation at 25d87a3: https://github.com/mwalle/milkymist/commit/25d87a323:04
GitHub160[llvm-lm32] sbourdeauducq pushed 1 new commit to master: http://git.io/woNFzQ23:16
GitHub160llvm-lm32/master f32da14 Sebastien Bourdeauducq: Target/LM32/CMakeLists: remove deleted LM32ELFWriterInfo.cpp23:16
mwallelekernel: does your recent commit fix the llvm/lm32?23:18
--- Mon Jan 7 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!