<larsc>
I don't think GPL drivers are reason for Linux's success
<hozer>
why
<hozer>
Why did Google choose linux over *Bsd for android
<larsc>
well certainly not because of the license
<hozer>
I'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 OS
<hozer>
s/book/boot/
<larsc>
there were and are quite a few companies who kept their Linux derivatives closed for years
<hozer>
who, do you have evidence?
<hozer>
There 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 OpenWRT
<larsc>
what actually got a lot of them to contribute to upstream was the realisation that it is actually beneficial for them to do this
<hozer>
right, 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 make
<hozer>
this is not the case in *BSD
<larsc>
well, the license doesn't force you to contribute to upstream
<hozer>
no but contributing to upstream in BSD gives your competitor an advantage
<larsc>
you can still do your yearly codedump with a million lines patch
<larsc>
and be compliant with the license
<hozer>
sure
<larsc>
why you want to contribute to upstream is because you don't have to rebase your patches for each new kernel release
<hozer>
right
<hozer>
and contributing to upstream provides a competitive advantage with GPL code
<larsc>
but from your point of view not with a BSD style license?
<hozer>
contributing to upstream on BSD can be a competitive disadvantage just as much as it helps
<larsc>
how?
<hozer>
right, because the competitor that decided to just suck in everyone else's changes, change 5 lines, and market it as ... oh say IOS ...
<larsc>
and?
<hozer>
well, by contributing to upstream without the GPL protection, you just handed a bunch of stuff over to someone who doesn't give back
<larsc>
they don't give back their 5 lines
<larsc>
which nobody wants anyway
<hozer>
but here's the problem..
<hozer>
Unless you start reverse-engineering the iPod, you have no idea if it was 5 lines, or 5000
<hozer>
and even then, those lines are clearly Apple's property
<hozer>
if it was GPL, then those 5, or 5000 lines benefit the community commons
<hozer>
even if it was a million line coredump
<larsc>
this presumes that somebody would want to go through that patch and pick out the goodies
<hozer>
well, the fact is someone bothers to reverse-engineer the iPod.
<hozer>
so if there was a good reason, then someone would definitely go through that million line coredump
<larsc>
but that someone is not another company which contributed code to the BSD kernel
<larsc>
or Linux kernel
<hozer>
some bored student, or someone who bought the hardware that million line coredump runs on
<larsc>
yea, but you argued that this creates a competetive advantage
<hozer>
yes, because the coredump requirement creates a level playing field
<hozer>
so you can coredump, and be stupid, and some student will reverse engineer your stuff
<hozer>
(or not coredump, like apple, and some students will reverse engineer it regardless)
<hozer>
or contribute to upstream source and reduce your development time the next time around
<larsc>
which benefits you, not your competitor
<hozer>
yes, but **only if** there's that 'level playing field coredump' requirement
<larsc>
no
* lekernel
votes for BSD
<hozer>
So then why don't Apple and Microsoft release the source for their mobile OSes
<Fallenou>
=)
<hozer>
well, let me know when I can buy a BSD phone
<larsc>
hozer: why should they?
<Fallenou>
well you can
<lekernel>
buy an iPhone
<lekernel>
:)
<Fallenou>
I met a french guy who was running NetBSD on a lot of devices
<hozer>
no, BSD phone with full source that I can recompile
<Fallenou>
a tablet
<Fallenou>
and I think his phone was running netbsd
<lekernel>
functionality > freedom
<larsc>
apple is their own upstream
<lekernel>
sorry
<hozer>
so I expect I'll get a functional BSD phone after I've built an open-source hardware platform
<larsc>
same for microsoft
<hozer>
right
<hozer>
Google could have hired people and written their own OS, or ripped off NetBSD, but they decided to leverage the linux upstream
<larsc>
but not because of the GPL
<hozer>
oh?
<hozer>
What makes you think google would have released the OS kernel if there wasn't a requirement for it?
<hozer>
or all the phone vendors?
<lekernel>
btw http://mickey.lucifier.net/ expressed interest in porting BSD to LM32 - you may want to ping him ...
<larsc>
hozer: If they had written their own OS they probably wouldn't have done so
<larsc>
Most of the android changes were out of upstream for a long time
<larsc>
and quite a bit of it still is
<hozer>
anyway, let's get BSD on lm32/milkymist. All of this nonsense goes away if you have GPL hardware ;)
lekernel has quit [Quit: Leaving]
lekernel has joined #milkymist
sb0 has joined #milkymist
<sb0>
so, you think the MMU is ready for attempting to port a serious OS?
<Fallenou>
well, it seems so but I didn't run any test since Michael's 50+ patches
<Fallenou>
I tried yesterday to run one but the simulation failed
<Fallenou>
Once I can see a few test passing I think we can start working on OS side
<Fallenou>
But I assume Michael does not push tests that don't pass :)
<sb0>
iirc we can run at 200MHz in the kintex-7. then it becomes interesting for a large OS...
<Fallenou>
I guess kintex is crazy expensive ?
<Fallenou>
but yes 200 MHz could be nice :)
<Fallenou>
mwalle: are you using a patched iverilog? Mine is 0.9.2 official debian squeeze package
<Fallenou>
hum hum just got iverilog to segfault
<Fallenou>
nice
<Fallenou>
it seems pc_a is cycling through 0, 1, 2, 3
<Fallenou>
first it's fetched from testbench SRAM
<Fallenou>
and then only from I cache
<Fallenou>
so no more wishbone transaction afterward
sb0 has quit [Quit: Leaving]
sb0 has joined #milkymist
<sb0>
it's expensive, but not crazy expensive
<Fallenou>
it cannot be ordered from Farnell :x
<Fallenou>
hum maybe digi-key
<Fallenou>
it seems entry price is $132
<Fallenou>
for IC FPGA 70K KINTEX-7 484FBGA
<Fallenou>
hum it seems there is a branch to address 0
<Fallenou>
branch_target_m == 0x0
<Fallenou>
with branch_taken_m == 1
<Fallenou>
aouch ok, it's my fault, I compiled with rtems toolchain ...
<Fallenou>
I got crap in my generated binary
<Fallenou>
first instruction is : ret (from rtems_provides_crt0 function)
<Fallenou>
does not help :)
<Fallenou>
*brb*
azonenberg has quit [Read error: Operation timed out]
<Fallenou>
so I needed to add -nostdlib flag to linker in the Makefile to use rtems toolchain correctly with no crap in the output
<Fallenou>
yeah, tests are running and outputing understandable things :)
<Fallenou>
I can see a lot of "FAILED" though :x
<wpwrak>
you may want to check the binary for additional undesirables. depends on what your linker script does and what output format you choose
<Fallenou>
first output format is .o then linked to a .elf and then objcopy'd using -O verilog to .vh file
<Fallenou>
I added -lgcc to linker just in case
* Fallenou
really does not want to regenerate a bare-metal elf toolchain
<Fallenou>
I had a quick look at the generated code, at least the first instructions are correct.
<Fallenou>
all exception vectors are in place
<Fallenou>
and then there is the main, it seems ok
<mwalle>
whoa, what a backlog :)
<mwalle>
bbl, dexter :)
<sb0>
Fallenou, tried clang/lllvm?
<sb0>
mwalle, the patch is in the second email from Fallenou (with same subject)
<Fallenou>
sb0: for lm32? nop
<sb0>
Fallenou, build instructions are in milkymist-ng readme
<sb0>
if you want to give it a try
<Fallenou>
oh cool
<sb0>
some stuff is still missing and the generated code quality isn't quite good yet, but it should be fine for simple/low-perf apps
<Fallenou>
I may give it a try
<sb0>
it doesn't build atm, I'm fixing it
<sb0>
moment ...
<Fallenou>
for simple unit testing it could be great
<Fallenou>
22:31 < mwalle> whoa, what a backlog :) < yes a lot of talk these days :) welcome back!
<Fallenou>
mwalle: 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)