IRC logs for #openrisc Friday, 2015-03-27

--- Log opened Fri Mar 27 00:00:39 2015
poke53281olofk: great07:59
poke53281olofk: http://pastie.org/1005682408:01
poke53281This works for me08:01
shentinoI think you guys should make a very simple 64-bit arch :)08:18
shentinowith separate TLBs for user and supervisor mode08:19
stekernshentino: another (slightly simpler) aproach would be to allow locking down a TLB entry with a fixed mapping for supervisor mode08:26
shentinothe goal is to allow usermode code a full 64-bit virtual address space without having to save room for a supervisor :P08:28
shentinooh yeah, specifying whether a tlb entry is for user or supervisor works too08:28
shentinowas one of my other thoughts08:28
shentinoalong with bulk load/save of the entire tlb08:29
stekernthat's slightly orthogonal to locking down, but that'd be an idea too08:29
shentinothe basic idea is to have user and supervisor in separate address space08:29
shentinoso that supervisor is truly invisible to user except via syscalls08:29
shentinoexplain locking down a tlb entry08:30
stekernthat it can't be replaced08:32
shentinois this the same meaning as pinned?08:32
stekernbut it doesn't solve the problem you're explaining08:32
stekernyes08:32
* shentino nods08:32
shentinomy idea is that usermode should have all 64 bits :)08:33
stekernsince you still have to reserve virtual memory space for it08:33
shentinoaye08:33
stekernyeahg, I understand08:33
shentinothat's why my idea has separate tlbs for user and supervisor08:33
shentinooh yeah, and page tables suck08:33
stekernbut you'd get pretty far with just one/few supervisor tlb entries08:39
stekernumm, no, because it of course has to be able to access the userspace too08:41
stekernshentino: how will supervisor mode know when to use the "userspace" virtual address space?08:44
shentinooh, you mean for like accessing userspace parameters?08:45
shentinoI guess an instruction prefix08:45
shentinolike ES: does for x8608:45
shentinoor a dedicated instruction to read from userspace08:46
shentinostill debating08:46
shentinoI actually have a writeup of my dream CPU08:46
stekernyeah, seperate load/store insns was my first thought08:46
shentinospeaking of which, at first I thought that the only memory instructions should be store/load with general register08:47
shentinothen I got to thinking...spinlocks and locked writes08:47
stekernyou could even let supervisor mode run completely untranslated then08:49
stekernnot sure if that's a good idea in practice, but at least theoretically it'd be possible08:49
shentinoyou mean force supervisor mode to use physical memory?08:49
shentinoinstead of virtual memory?08:50
stekernforce or let, your pick ;)08:50
shentinoI disagree.  Supervisor may want to catch null pointer bugs08:50
shentinohowever, you could have a single 64-bit wide identity tlb entry08:50
stekernmmm, hence the "practical" clause08:50
shentinowhich does the same thing08:50
shentinoin fact, when my cpu boots, the TLB is primed with one entry that covers the entire 64-bit virtual space with an identity map to physical memory :)08:51
shentinobut yeah, I want to be able to keep supervisor in vaddr to catch bugs.  Also, if I dare, letting supervisor memory be paged :)08:51
shentinoif a buggy ass system like windows can swap out kernel code/data, why not us?08:52
shentinobut yeah, I've been working on a cpu architecture that emphasizes simplicity08:53
shentinowould you like a peek sometime?08:53
stekernsure08:56
Me1234As I said here http://juliusbaxter.net/openrisc-irc/%23openrisc.2015-03-24.log.html#t18:23 ethernet does not work with master connected to SDRAM. How can I fix that.10:25
_franck__Me1234: this board has ethernet support: https://github.com/openrisc/orpsoc-cores/blob/master/systems/neek/rtl/verilog/orpsoc_top.v10:29
_franck__you can take a look at it10:29
Me1234_frank__: I looked here to do it : https://github.com/mczerski/orpsoc-cores/blob/master/systems/de0_nano_expansion/rtl/verilog/orpsoc_top.v10:37
Me1234_franck__: Now I connected the PHY to the board, but did not connect the master interface. Now I have: http://pastie.org/1005714411:09
Me1234_franck__: My PHY is KSZ8051MLL11:10
stekernwhat is "master interface"?11:10
Me1234stekern: Ethmac's master interface (ethmac - ram).11:11
Me1234With master interface connected it hangs for a while in bootrom an then jumps to 0x20011:12
Me1234I tried with wb_intercon and bypassing it.11:12
Me1234Are ~2cm wires OK for MII? I have soldered to SCSI connector (The eval board uses it) and to headers, then connected the headers to de0_nano11:32
Me1234Do KSZ8031 KSZ8051 have common drivers?11:35
Me1234If I disconnet the PHY, It boots11:36
stekern2cm wires for mdio should be ok either case11:48
olofkMe1234: Do you mean that Linux boots fine when the expansion board is disconnected?12:39
Me1234olofk: Yes.12:41
Me1234olofk: Keep in mind that master is disconnected. But I think that isnot the cause12:41
Me1234.12:41
olofkThat's very weird. I can't think of anything that would cause that to happen12:41
olofkI didn't understand the last part12:42
olofkI mean, does it work when the eth wb master interface is connected to RAM and the expansion board is unplugged?12:43
stekernwell, if you look at the log, you'll see that the mdio read complains about something12:43
olofkI think the line "sp + 436: 0xc039fea8" from the log looks strange. Shouldn't that be 0xc039fda8?12:45
stekernolofk: someone might take you seriously M)12:48
olofk:)12:48
olofkSorry12:48
stekernspeaking of phy's, the designers of ksz8863 must have had a shortage of their medicine12:50
stekernit's a switch chip with two built-in phys, and you can access the phy registers from MDIO or SPI12:50
stekernbut the layout of the registers from the SPI and MDIO pov is completely different12:51
stekernso to get the information from 'basic control' you have to read 3 different registers12:51
stekernand the bit positions are not remotely the same12:52
Me1234olofk: With master interface it does not boot at all. It executes bootrom for a while, then goes to 0x200.12:54
_franck__Me1234: can you show us your top file ?12:59
Me1234Top file here http://pastebin.com/ag92nXnN . Here the master interface is connected.13:04
olofkI see it13:06
olofkYou have declared all signals as wires without specifying their width13:06
olofkTry this http://pastebin.com/wEjsw3uF13:07
Me1234Now it boots with master connected, but same errors as here http://juliusbaxter.net/openrisc-irc/%23openrisc.2015-03-27.log.html#t11:09 when I connect the PHY. Now I will test without PHY.13:26
Me1234Also bootrom has stopped working13:26
Me1234Does not boot without PHY.13:27
olofkMe1234: The warnings about the mdio interface might have something to do with it13:30
olofkSeems weird that the kernel should crash just because it fails to communicate over mdio, but maybe13:31
Me1234olofk: Do you think the assignments are wrong?13:46
Me1234olofk: This board also has a lot of jumpers: PHYAD0 PHYAD1 PHYAD2 DUPLEX CONFIG2 B-CAST_OFF PME_EN ISO CONFIG0 CONFIG1 NWAYEN SPEED.13:49
olofkHard to tell13:49
Me1234I do no know what do they mean13:49
Me1234All jumpers are open13:49
olofkThe phyad* ones are probably for the phy mdio address13:50
stekernthen the internal pull-ups/pull-downs of the chip will presumable be used13:50
olofkThinking the same13:50
stekernphyad0 usually have a pull-up, so you'll get address 113:52
stekernthe config pins are for setting MII/RMII mode13:52
Me1234What does "(default)" mean in the datasheet http://www.micrel.com/_PDF/Ethernet/datasheets/ksz8051mll.pdf page 1313:57
Me1234?13:57
stekernthat it is the default14:00
stekernbut the only thing related to the mdio communication is the phyad14:00
stekernwhat is at address c01e57d4 in the kernel?14:03
olofkIt could be interesting to disconnect all pins to the ethernet board except for mdc/mdio14:04
Me1234stekern: c01e57d4 is in allocate_partition14:18
Me1234olofk: With mdc/mdio and power connected it does not boot. If linux loaded with GDB it moves to 0x003a805c and stops there (?).14:19
olofkThat's a badass mdio interface14:20
Me1234olofk: some hardware problems 1.7V on PHY board. Will try to diagnose it.14:24
wallentostekern: I am slightly confused with the arch spec mmu part and the mor1kx implementation15:02
wallentoare you thereƟ15:02
wallentofigure 8-3 for some reason generates the physical address with 35 bit: {pte[31:10],vaddr[12:0]}15:05
wallentothat would mean I need to truncate on the msb or not to get the 32 bit address: {pte[28:10],vaddr[12:0]}15:06
wallentobut all verilog code truncates on the LSB: {pte[31:13],vaddr[12:0]}15:06
wallentoI like the latter more, but is there a good reason for the 35 bit? If not, should we change the spec accordingly?15:07
stekernwallento: i'm here, but on foot15:08
wallentookay, maybe you can have a look at it on the weekend15:09
wallentothanks!15:09
stekernI had something i'd like to look up for the 1.2 rev regarding mmu too15:09
wallentookay, I will start a thread on the mailing list15:09
stekernyeah, I'll check things out in the weekend15:09
wallentoperfect, have a nice day!15:16
stekernwallento: I don't see the pte[31:10] anywhere in the spec16:29
stekernat least not in figure 8-316:30
stekernah, now I see16:33
stekernOT: I just finished off a song: https://soundcloud.com/stefan-kristiansson/metastable-flatline16:57
ysionneaustekern: very good!17:49
ysionneauthanks!17:49
olofkstekern: Like the song. I'm getting a loungy hacker group intro feeling18:57
olofkI tried to automate some stuff in TCL with Altera's system console. I'm not doing that again.19:17
olofkHow about redoing the OpenRISC arch spec in asciidoc or similar? Someone did that for the or1200 spec, right?19:35
olofkMe1234: Did you find out what was wrong with your ethernet board?19:41
olofk1.7V sounds very much like some signal can't decide on whether it wants to be 3.3V or GND19:42
Me1234olofk: No. But 1.7V was when I connected it through additional wires to connect only mdio bus. Now I connected it normally, It is 3.3V.19:47
Me1234olofk: DTS bindig taken from or1ksim, I mean for ethernet. Is it OK? I found that Documentation/devicetree/bindings/net/mdio-* in linux documantation. Does MDIO bus need separate binding19:49
Me1234?19:49
olofkSolving the mdio problem that show up in the kernel log would still be your first task. I think you should remove the pin assignments for the other signals to make sure that they don't interfere19:50
olofkAll mdio transactions are handled through the ethoc driver, so you only need to add that to your dts19:51
Me1234Aren't unassigned pins routed to a random pin? Or remove from orpsoc_top.v file?19:51
olofkYes, they are, so remove the from the top-level19:51
olofkThe code I did for a Cyclone IV-based OpenRISC SoC with a Micrel phy is released now btw, if you can find out any more clues from that19:52
olofkhttps://github.com/myriadrf/STREAM19:52
olofkKernel config and dts are here https://github.com/myriadrf/STREAM/tree/master/stream_openrisc_soc/src/stream/data19:53
Me1234olofk: With only MDIO connected even timerled example does not work.20:11
olofkMe1234: Can you try measure the lines with an oscilloscope or multimeter? Or perhaps only connect one at a time? There is something really weird going on here20:31
olofkDoes it work when you connect the expansion board without connecting any signals at all from the FPGA?20:31
--- Log closed Sat Mar 28 00:00:41 2015

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