| --- Log opened Fri Mar 27 00:00:39 2015 | ||
| poke53281 | olofk: great | 07:59 |
|---|---|---|
| poke53281 | olofk: http://pastie.org/10056824 | 08:01 |
| poke53281 | This works for me | 08:01 |
| shentino | I think you guys should make a very simple 64-bit arch :) | 08:18 |
| shentino | with separate TLBs for user and supervisor mode | 08:19 |
| stekern | shentino: another (slightly simpler) aproach would be to allow locking down a TLB entry with a fixed mapping for supervisor mode | 08:26 |
| shentino | the goal is to allow usermode code a full 64-bit virtual address space without having to save room for a supervisor :P | 08:28 |
| shentino | oh yeah, specifying whether a tlb entry is for user or supervisor works too | 08:28 |
| shentino | was one of my other thoughts | 08:28 |
| shentino | along with bulk load/save of the entire tlb | 08:29 |
| stekern | that's slightly orthogonal to locking down, but that'd be an idea too | 08:29 |
| shentino | the basic idea is to have user and supervisor in separate address space | 08:29 |
| shentino | so that supervisor is truly invisible to user except via syscalls | 08:29 |
| shentino | explain locking down a tlb entry | 08:30 |
| stekern | that it can't be replaced | 08:32 |
| shentino | is this the same meaning as pinned? | 08:32 |
| stekern | but it doesn't solve the problem you're explaining | 08:32 |
| stekern | yes | 08:32 |
| * shentino nods | 08:32 | |
| shentino | my idea is that usermode should have all 64 bits :) | 08:33 |
| stekern | since you still have to reserve virtual memory space for it | 08:33 |
| shentino | aye | 08:33 |
| stekern | yeahg, I understand | 08:33 |
| shentino | that's why my idea has separate tlbs for user and supervisor | 08:33 |
| shentino | oh yeah, and page tables suck | 08:33 |
| stekern | but you'd get pretty far with just one/few supervisor tlb entries | 08:39 |
| stekern | umm, no, because it of course has to be able to access the userspace too | 08:41 |
| stekern | shentino: how will supervisor mode know when to use the "userspace" virtual address space? | 08:44 |
| shentino | oh, you mean for like accessing userspace parameters? | 08:45 |
| shentino | I guess an instruction prefix | 08:45 |
| shentino | like ES: does for x86 | 08:45 |
| shentino | or a dedicated instruction to read from userspace | 08:46 |
| shentino | still debating | 08:46 |
| shentino | I actually have a writeup of my dream CPU | 08:46 |
| stekern | yeah, seperate load/store insns was my first thought | 08:46 |
| shentino | speaking of which, at first I thought that the only memory instructions should be store/load with general register | 08:47 |
| shentino | then I got to thinking...spinlocks and locked writes | 08:47 |
| stekern | you could even let supervisor mode run completely untranslated then | 08:49 |
| stekern | not sure if that's a good idea in practice, but at least theoretically it'd be possible | 08:49 |
| shentino | you mean force supervisor mode to use physical memory? | 08:49 |
| shentino | instead of virtual memory? | 08:50 |
| stekern | force or let, your pick ;) | 08:50 |
| shentino | I disagree. Supervisor may want to catch null pointer bugs | 08:50 |
| shentino | however, you could have a single 64-bit wide identity tlb entry | 08:50 |
| stekern | mmm, hence the "practical" clause | 08:50 |
| shentino | which does the same thing | 08:50 |
| shentino | in 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 |
| shentino | but 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 |
| shentino | if a buggy ass system like windows can swap out kernel code/data, why not us? | 08:52 |
| shentino | but yeah, I've been working on a cpu architecture that emphasizes simplicity | 08:53 |
| shentino | would you like a peek sometime? | 08:53 |
| stekern | sure | 08:56 |
| Me1234 | As 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.v | 10:29 |
| _franck__ | you can take a look at it | 10: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.v | 10:37 |
| Me1234 | _franck__: Now I connected the PHY to the board, but did not connect the master interface. Now I have: http://pastie.org/10057144 | 11:09 |
| Me1234 | _franck__: My PHY is KSZ8051MLL | 11:10 |
| stekern | what is "master interface"? | 11:10 |
| Me1234 | stekern: Ethmac's master interface (ethmac - ram). | 11:11 |
| Me1234 | With master interface connected it hangs for a while in bootrom an then jumps to 0x200 | 11:12 |
| Me1234 | I tried with wb_intercon and bypassing it. | 11:12 |
| Me1234 | Are ~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_nano | 11:32 |
| Me1234 | Do KSZ8031 KSZ8051 have common drivers? | 11:35 |
| Me1234 | If I disconnet the PHY, It boots | 11:36 |
| stekern | 2cm wires for mdio should be ok either case | 11:48 |
| olofk | Me1234: Do you mean that Linux boots fine when the expansion board is disconnected? | 12:39 |
| Me1234 | olofk: Yes. | 12:41 |
| Me1234 | olofk: Keep in mind that master is disconnected. But I think that isnot the cause | 12:41 |
| Me1234 | . | 12:41 |
| olofk | That's very weird. I can't think of anything that would cause that to happen | 12:41 |
| olofk | I didn't understand the last part | 12:42 |
| olofk | I mean, does it work when the eth wb master interface is connected to RAM and the expansion board is unplugged? | 12:43 |
| stekern | well, if you look at the log, you'll see that the mdio read complains about something | 12:43 |
| olofk | I think the line "sp + 436: 0xc039fea8" from the log looks strange. Shouldn't that be 0xc039fda8? | 12:45 |
| stekern | olofk: someone might take you seriously M) | 12:48 |
| olofk | :) | 12:48 |
| olofk | Sorry | 12:48 |
| stekern | speaking of phy's, the designers of ksz8863 must have had a shortage of their medicine | 12:50 |
| stekern | it's a switch chip with two built-in phys, and you can access the phy registers from MDIO or SPI | 12:50 |
| stekern | but the layout of the registers from the SPI and MDIO pov is completely different | 12:51 |
| stekern | so to get the information from 'basic control' you have to read 3 different registers | 12:51 |
| stekern | and the bit positions are not remotely the same | 12:52 |
| Me1234 | olofk: 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 |
| Me1234 | Top file here http://pastebin.com/ag92nXnN . Here the master interface is connected. | 13:04 |
| olofk | I see it | 13:06 |
| olofk | You have declared all signals as wires without specifying their width | 13:06 |
| olofk | Try this http://pastebin.com/wEjsw3uF | 13:07 |
| Me1234 | Now 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 |
| Me1234 | Also bootrom has stopped working | 13:26 |
| Me1234 | Does not boot without PHY. | 13:27 |
| olofk | Me1234: The warnings about the mdio interface might have something to do with it | 13:30 |
| olofk | Seems weird that the kernel should crash just because it fails to communicate over mdio, but maybe | 13:31 |
| Me1234 | olofk: Do you think the assignments are wrong? | 13:46 |
| Me1234 | olofk: 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 |
| olofk | Hard to tell | 13:49 |
| Me1234 | I do no know what do they mean | 13:49 |
| Me1234 | All jumpers are open | 13:49 |
| olofk | The phyad* ones are probably for the phy mdio address | 13:50 |
| stekern | then the internal pull-ups/pull-downs of the chip will presumable be used | 13:50 |
| olofk | Thinking the same | 13:50 |
| stekern | phyad0 usually have a pull-up, so you'll get address 1 | 13:52 |
| stekern | the config pins are for setting MII/RMII mode | 13:52 |
| Me1234 | What does "(default)" mean in the datasheet http://www.micrel.com/_PDF/Ethernet/datasheets/ksz8051mll.pdf page 13 | 13:57 |
| Me1234 | ? | 13:57 |
| stekern | that it is the default | 14:00 |
| stekern | but the only thing related to the mdio communication is the phyad | 14:00 |
| stekern | what is at address c01e57d4 in the kernel? | 14:03 |
| olofk | It could be interesting to disconnect all pins to the ethernet board except for mdc/mdio | 14:04 |
| Me1234 | stekern: c01e57d4 is in allocate_partition | 14:18 |
| Me1234 | olofk: With mdc/mdio and power connected it does not boot. If linux loaded with GDB it moves to 0x003a805c and stops there (?). | 14:19 |
| olofk | That's a badass mdio interface | 14:20 |
| Me1234 | olofk: some hardware problems 1.7V on PHY board. Will try to diagnose it. | 14:24 |
| wallento | stekern: I am slightly confused with the arch spec mmu part and the mor1kx implementation | 15:02 |
| wallento | are you thereß | 15:02 |
| wallento | figure 8-3 for some reason generates the physical address with 35 bit: {pte[31:10],vaddr[12:0]} | 15:05 |
| wallento | that 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 |
| wallento | but all verilog code truncates on the LSB: {pte[31:13],vaddr[12:0]} | 15:06 |
| wallento | I like the latter more, but is there a good reason for the 35 bit? If not, should we change the spec accordingly? | 15:07 |
| stekern | wallento: i'm here, but on foot | 15:08 |
| wallento | okay, maybe you can have a look at it on the weekend | 15:09 |
| wallento | thanks! | 15:09 |
| stekern | I had something i'd like to look up for the 1.2 rev regarding mmu too | 15:09 |
| wallento | okay, I will start a thread on the mailing list | 15:09 |
| stekern | yeah, I'll check things out in the weekend | 15:09 |
| wallento | perfect, have a nice day! | 15:16 |
| stekern | wallento: I don't see the pte[31:10] anywhere in the spec | 16:29 |
| stekern | at least not in figure 8-3 | 16:30 |
| stekern | ah, now I see | 16:33 |
| stekern | OT: I just finished off a song: https://soundcloud.com/stefan-kristiansson/metastable-flatline | 16:57 |
| ysionneau | stekern: very good! | 17:49 |
| ysionneau | thanks! | 17:49 |
| olofk | stekern: Like the song. I'm getting a loungy hacker group intro feeling | 18:57 |
| olofk | I tried to automate some stuff in TCL with Altera's system console. I'm not doing that again. | 19:17 |
| olofk | How about redoing the OpenRISC arch spec in asciidoc or similar? Someone did that for the or1200 spec, right? | 19:35 |
| olofk | Me1234: Did you find out what was wrong with your ethernet board? | 19:41 |
| olofk | 1.7V sounds very much like some signal can't decide on whether it wants to be 3.3V or GND | 19:42 |
| Me1234 | olofk: 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 |
| Me1234 | olofk: 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 binding | 19:49 |
| Me1234 | ? | 19:49 |
| olofk | Solving 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 interfere | 19:50 |
| olofk | All mdio transactions are handled through the ethoc driver, so you only need to add that to your dts | 19:51 |
| Me1234 | Aren't unassigned pins routed to a random pin? Or remove from orpsoc_top.v file? | 19:51 |
| olofk | Yes, they are, so remove the from the top-level | 19:51 |
| olofk | The 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 that | 19:52 |
| olofk | https://github.com/myriadrf/STREAM | 19:52 |
| olofk | Kernel config and dts are here https://github.com/myriadrf/STREAM/tree/master/stream_openrisc_soc/src/stream/data | 19:53 |
| Me1234 | olofk: With only MDIO connected even timerled example does not work. | 20:11 |
| olofk | Me1234: 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 here | 20:31 |
| olofk | Does 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!