<Jia>
hi, I think I find the lm32-gcc bug, but I still some time to find the resean and fix it.
kilae has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
elldekaa has joined #milkymist
rejon has joined #milkymist
<Fallenou>
wolfspraul: (Linux kernel effort) Reasonably speaking, It would be nice to fix at least every situation that crashes the SoC on FPGA before starting to add MMU support to lm32 Linux
<Fallenou>
but since I'm not so much reasonable, I may start the Linux kernel effort before that, and fix MMU bugs on the fly
<Fallenou>
I spent the week studying Linux kernel "starting" code (head.S start.S etc) of OpenRISC and lm32
<Fallenou>
and reading a bit about Linux virtual memory
<Fallenou>
It's not very funny to fix bugs that most of the time are "software bugs" in my bios test code, which in the end will be of no use at all
<Fallenou>
I would better debug on real use case on Linux
elldekaa has quit [Ping timeout: 240 seconds]
kilae_ has joined #milkymist
kilae has quit [Ping timeout: 255 seconds]
elldekaa has joined #milkymist
<Fallenou>
I have set up a compile box using a (free) OVH VKS (Virtual KimSufi). I installed lm32 toolchain and successfully compiled linux-milkymist-nommu. I didn't try to boot it yet, it will be a surprise :)
elldekaa has quit [Remote host closed the connection]
<wolfspraul>
Fallenou: oh, nice!
<wolfspraul>
I didn't know it's that advanced already, that's great
<Fallenou>
maybe it's a bad move, I don't know (starting linux kernel hack)
<Fallenou>
but I'm kind of bored to try to understand why it behaves nicely in simulation and why it crashes in some situations on FPGA
<Fallenou>
so I want to move on :)
<wolfspraul>
understand
<Fallenou>
we will see, anyway if it's not stable enough I will be forced to go back to mmu debug
<Fallenou>
if it works, well, it's stable enough :)
<wpwrak>
hmm. as far as debugging is concerned, going straight to linux while the synthetic tests are still failing sounds like a pretty bad move.
<wpwrak>
however, there would be value in actually trying to make it fit into the real system. e.g., you may find that there are some operations you haven't anticipated or that are inconvenient in their present state. so that would be functionality (things like permissions and such) and also interfaces (e.g., how you update the TLBs)
<wpwrak>
regarding the BIOS tests, if PIC causes you a lot of trouble, why not just force compilation with a specific absolute address ?
<Fallenou>
I don't think PIC causes troubles
<Fallenou>
I did instruction modification at runtime and it worked fine in simulation
<wpwrak>
hmm. maybe you need something that lets you debug at a lower level.
<wpwrak>
how about making a LED bar that plugs into the extension header ?
<wpwrak>
then you could synthesize a controller with a latch of set/clear lines, which would let you set leds with very little overhead. i.e., you could set leds from within the verilog.
<wpwrak>
that way, you could find out at what point the system derails
<wpwrak>
if you have some sort of multi-channel monitor (any kind of LA), you could also just connect directly to the expansion header, without needing LEDs
<Fallenou>
led or LA stuff could help indeed
<Fallenou>
I have a LA, I could just connect it to the extension header and debug with it
<wpwrak>
that sounds quite good already
<wpwrak>
particularly if it has a "continuous display". i.e., if you can see what the signals are doing without having to wait for a trigger
<wpwrak>
if it needs a trigger, you could of course just output a continuous wave on one pin, and use that
<Fallenou>
it only works with a trigger
<Fallenou>
and has very few memory
<Fallenou>
it's an open source LA
<Fallenou>
using fpga blockram as memory
<Fallenou>
so it's quite small
<wpwrak>
can you make it loop without manual intervention ? wait for trigger -> capture a few samples -> display -> wait for next trigger ...
<wpwrak>
well, if all else fails, you can still rig up a few LEDs :)
<Fallenou>
hehe
<Fallenou>
we will see, I'm not a pcb maker expert like you guys :p
<Fallenou>
remember I am a software guy
<wpwrak>
you domn'
<wpwrak>
you don't really need a pcb for a few leds :)
<Fallenou>
I don't even own a soldering machine :p
<Fallenou>
but I have leds !
<wolfspraul>
I successfully procrastinate my etching work :-)
<wolfspraul>
fpga wiring is just too much fun
<wpwrak>
i suppose you could do it with wire wrap :)
<wpwrak>
you need leds, some resistors in the 56-220 Ohm range, and connector(s). the connector(s) may be the hardest bit.
<Fallenou>
I have a few resistors but I don't remember the ohm value
<wpwrak>
fortunately, there a a lot of things that connect to 100 mil headers. and it doesn't have to be a perfect fit anyway. if you just make loose connections, you can adapt pretty much any connector that somehow fits
<wpwrak>
SMT resistors or the old type with funny color rings ?
<Fallenou>
funny color rings ;)
<wpwrak>
well, then you'll have fun decoding ;)
<Fallenou>
sure !
<wpwrak>
or if you have a voltmeter, you can just use taht
<wpwrak>
won't be very precise for relatively small values but it'll left you tell the 10 kOhm from the 100 Ohm :)
galito has joined #milkymist
galito has quit [Ping timeout: 245 seconds]
Gurty has joined #milkymist
<wpwrak>
s/left/let/
* Fallenou
is back
<mwalle>
Fallenou: is there any documentation about your mmu implementation? :)