lekernel changed the topic of #m-labs to: Mixxeo, Migen, MiSoC & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
xiangfu has joined #m-labs
xiangfu has quit [Remote host closed the connection]
kristianpaul has quit [Remote host closed the connection]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
xiangfu has joined #m-labs
sh4rm4 has quit [Ping timeout: 252 seconds]
sh4rm4 has joined #m-labs
mumptai has joined #m-labs
<ysionneau> mwalle: hey :) What's the difference between hardware and software breakpoints?
<ysionneau> by reading a bit the gdbstub it seems at least one kind of breakpoint is implemented by using the "BP<n>" CSR regs
<ysionneau> since it's hardware assisted I would say this is the "hardware breakpoint"
<ysionneau> but how does software breakpoint work ?
<larsc> insert a break instruction
<larsc> hardware breakpoint is where you have a register where you can specify the address you want to break on
<ysionneau> ah ok
<ysionneau> indeed software breakpoints are less handy then :)
<ysionneau> you have to recompile etc
<larsc> I think gdb can do that at runtime
<larsc> and relocates the instruction that was replaced
<ysionneau> wo
<larsc> 'Parameter C_START_WIDTH bound to: 320000'b000...' ok...
<ysionneau> ah but, I think I was using software breakpoints
<ysionneau> since I was using "break" in gdb and not "hbreak"
<ysionneau> I should retry with hbreak
mumptai has quit [Ping timeout: 240 seconds]
nicksydney has quit [Remote host closed the connection]
nicksydney has joined #m-labs
mumptai has joined #m-labs
<ysionneau> mwalle: could you reproduce the "single stepping with IE=1 IP=4 IM=4 and no exception is raised" bug with the kernel I sent you ?
sh4rm4 has quit [Ping timeout: 252 seconds]
<ysionneau> win 29
xiangfu has quit [Ping timeout: 246 seconds]
xiangfu has joined #m-labs
xiangfu has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 252 seconds]
mumptai has quit [Read error: Connection reset by peer]
<GitHub149> [NetBSD] fallen pushed 1 new commit to master: http://git.io/k8-P8A
<GitHub149> NetBSD/master a8cfe1f Yann Sionneau: clock driver: now calls hardclock callback for time accounting
<GitHub182> [NetBSD] fallen force-pushed master from a8cfe1f to 2e29367: http://git.io/gXHqXA
<GitHub182> NetBSD/master 2e29367 Yann: clock driver: now calls hardclock callback for time accounting
sh4rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 252 seconds]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 252 seconds]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sb0 has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
sb0 has quit [Ping timeout: 240 seconds]
sb0 has joined #m-labs
bvernoux has joined #m-labs
sb0 has quit [Ping timeout: 240 seconds]
mumptai has joined #m-labs
sb0 has joined #m-labs
* ysionneau trying to add breakpoint at 0x40000000 with "hbreak" this time
<ysionneau> it says "Hardware assisted breakpoint 1 at 0x40000000" , maybe it will work better :)
<ysionneau> hum I get
<ysionneau> Program received signal SIGTRAP, Trace/breakpoint trap.
<ysionneau> 0x00000000 in ?? ()
<ysionneau> not what I wanted :(
<ysionneau> now I put a breakpoint in the "boot_helper" routine of the BIOS, which basically does the final jump by flushing Icache and doing "call r5"
<ysionneau> I think I'm starting to understand, there is an issue in the shifting of the address bits somewhere
<ysionneau> 0x864238 ==> pc = 0x42380000
<larsc> the good hold, shift address instruction, for extra long jumps
<ysionneau> :)
<ysionneau> sb0: any news on the recent gcc "fixes" for lm32 ?
<ysionneau> ok my bad, I modified gdbstub to add support for PSW and TLB regs and I did a mistake
<ysionneau> by using original gdb stub I can break on boot_helper and then singler step up to PC == 0x40000000
<ysionneau> ah, I understand why I can see garbage at 0x40000000 instead of my netbsd kernel :)
<ysionneau> I uploaded an ELF ... instead of a binary
<ysionneau> which means there is another chance netbsd would "boot" on the m1 *finger crossed*
<ysionneau> I got "@� " to print ^^"
<ysionneau> it's stuck in the low level uart printing routine, but by single stepping it "works" and print
<ysionneau> while (!(UART_STAT_THRE & *uart_stat)); is an infinite loop if I don't hit Ctrl+C in gdb and single step
<ysionneau> *uart_stat is always 0
gric_ has quit [Remote host closed the connection]
<ysionneau> uart_stat is declared as (volatile unsigned int *)(and anyway it works in qemu)
<ysionneau> ah maybe I'm accessing it through virtual address and maybe it gets cached...
<ysionneau> ah yes it's at 0x60000008
<ysionneau> let's just flush cache in the while loop for now (please don't shout :D)
<stekern> ysionneau: do you have a "non-cached" bit in your tlbs?
<ysionneau> I have but I don't think it's really implemented
<stekern> not implemented, on the sw side or hw side?
<ysionneau> ah, it *is* implemented
<ysionneau> in the hw
<ysionneau> but I am not using it at all in the sw side
<ysionneau> but I will :)
<stekern> =)
<ysionneau> let's try again and see what it spits out
<ysionneau> so far with singlestepping I had "msgbu"
<ysionneau> which is promsing :)
<ysionneau> +i
<ysionneau> YES
<ysionneau> http://pastebin.com/5X10ampa <= \o/
<ysionneau> running on real HW :)
<ysionneau> well, still some bug when enabling irq, but cool to see it almost boots :)
<ysionneau> by comparison, this is with Qemu : http://pastebin.com/bFZNgcSb
<stekern> nice!
<stekern> you should use asciinema to record it, it's more interesting to watch than pastebins ;)
<stekern> https://asciinema.org/a/8162 as an example
<ysionneau> ah yes indeed :)
<ysionneau> I must say I'm sorry for calling gdb names, gdb on m1 seems to work really well, when the cpu is not trying to execute ELF header :)
<bvernoux> ysionneau: if you want to debug boot stuff code a good hint is maybe to use a good free simulator like Lauterbach one's
<ysionneau> simulator ?
<ysionneau> I have qemu for simulation
<ysionneau> I have lauterbach at the office for MIPS
<ysionneau> it works nicely indeed (I use it for jtag)
<ysionneau> stekern: https://asciinema.org/a/8288 not so easy to watch since most of the time is waiting and the boot is done in the blink of an eye and flooded by IRQ errors ^^
<ysionneau> after fixing irq stuff it will be nicer
<ysionneau> bvernoux: I don't think they have jtag probes or simulators for lm32, do they ?
<bvernoux> they have
gric has joined #m-labs
<bvernoux> they just support all chipset existing
<bvernoux> mainly instruction set
<bvernoux> and a basic timer
<larsc> right ;)
<bvernoux> also irq work
<bvernoux> but nothing specific to the core
gric has quit [Client Quit]
<bvernoux> there is even code trace and code coverage in simulator without any limitation (except size 16Millions traces)
<ysionneau> I think qemu is really good "enough" for my use case
<ysionneau> plus it supports MMU
gric has joined #m-labs
gric has quit [Client Quit]
<ysionneau> and I could also run lm32 in iverilog or Isim
<ysionneau> but it's slow
<bvernoux> yes maybe qemu is better
gric has joined #m-labs
<bvernoux> for MMU stuff
<bvernoux> whats the exact version of the MCU ?
<ysionneau> LatticeMico32 , with cache, MMU, HW breakpoints, no jtag
<ysionneau> there is no real version number I presume
<bvernoux> ha ok it is a soft core
<ysionneau> yes
<ysionneau> err 3.8
<bvernoux> I was thinking it was a LM3S ;)
<ysionneau> ah, don't know it :)
<bvernoux> TI Stellaris M3 MCU
<ysionneau> ah cortex m3
<sb0> ysionneau, gcc svn seems to work now, as long as you don't try to use floating point
<bvernoux> what's the max freq you can obtain with soft core with lm32 ?
<sb0> it can compile the linux kernel, though I don't know if it works or not (it's broken even with 4.5 with which it used to work, idk why)
<ysionneau> sb0: maybe send the toolchain to someone who manages to get linux working
<sb0> the same problem exists with 4.5
<sb0> other software like BIOS etc. work fine with gcc svn
<ysionneau> cool !
<ysionneau> who is maitaining lm32 uclinux ? larsc ?
<sb0> bvernoux, 83MHz in slowtan6
<ysionneau> larsc: you are not able to boot linux built with 4.5 anymore? (lm32)
<ysionneau> we had it to run at 88 MHz IIRC
<sb0> with all options enabled. if you build a minimal core it's higher than that
<ysionneau> or was it on ML401
<bvernoux> sb0: ha ok not so bad fr a soft core and how many cycle per instruction it like ARM/PPC about 1 or 2 cycles on common instructions ?
<sb0> over 100MHz
<sb0> iirc
<sb0> it's pipelined with 1 cycle for most instructions (but jumps cost more)
<bvernoux> would have been great with ARM instructions set ;)
<bvernoux> anyway we are always re-enventing the wheel
<ysionneau> well the ARM wheel is closed source
<bvernoux> Reinventing
<bvernoux> instruction set is not closed
<ysionneau> so it's not a wheel you can use/improve
<ysionneau> ah, yes
<bvernoux> like x86 when amd have copied them ;)
<ysionneau> is the arm instruction set worth it?
<bvernoux> anyway LM32 is more like a PPC wiht 32reg
<ysionneau> compared to MIPS or LM32 RISC stuff?
<bvernoux> better than ARM which have less GPR
<larsc> ysionneau: I think 4.5 worked fine
<larsc> 4.6 did not iirc
<bvernoux> anyway very nice stuff
<bvernoux> and VHDL code is verilog very nice
<ysionneau> larsc: sb0 is saying that he cannot get current linux to boot by compiling it on 4.5 anymore :o
<larsc> yea, I have no idea why not
<bvernoux> it miss peripherals
<ysionneau> maybe you do something different than he does
<ysionneau> maybe you should try his 4.6 toolchain :)
<bvernoux> like integrated internal bus with access to spi, i2c and GPIO
<ysionneau> going to sleep !
<ysionneau> nice talking to you all
<ysionneau> and nice to meet you bvernoux
<bvernoux> nice to meet you too
<bvernoux> have good rest
nicksydney has quit [Ping timeout: 255 seconds]
nicksydney_ has joined #m-labs
felix__ has joined #m-labs
felix_ has quit [Ping timeout: 264 seconds]
felix__ is now known as felix_
<bvernoux> bye
bvernoux has quit [Quit: Leaving]
nicksydney has joined #m-labs
nicksydney_ has quit [Read error: Connection reset by peer]
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 255 seconds]
mumptai has quit [Ping timeout: 240 seconds]