| --- Log opened Thu Jul 04 00:00:11 2013 | ||
| hno | stekern, the mystery tightens.. earlycon=uart,mmio,0x90000000,115200 console=ttyS0,115200 works.. but I don't see how that's different from console=uart... | 00:57 |
|---|---|---|
| hno | found it. It is a software error. Last digit of the baud rate is lost somewhere. | 01:15 |
| hno | now just need to find where it's misplaced. | 01:16 |
| hno | It's lost very early. | 01:16 |
| hno | Kernel command line: console=uart,mmio,0x90000000,115200 | 01:16 |
| hno | Early serial console at MMIO 0x90000000 (options '11520') | 01:16 |
| hno | Aha! Now I feel silly. The change have been staring at me all day and I haven't reacted. | 01:17 |
| hno | Even logged in the very first lines of kernel output. | 01:36 |
| hno | Kernel command line: console=uart,mmio,0x90000000,115200 | 01:42 |
| hno | Early serial console at MMIO 0x90000000 (options '11520') | 01:42 |
| hno | https://patchwork.kernel.org/patch/2821521/ | 01:54 |
| stekern | hno, nice work tracking it down! | 02:18 |
| stekern | that explains why it works in or1ksim, it doesn't care about the baudrate | 02:20 |
| stekern | still a bit confused regarding verilated model, I thought the baudrate matters there, have to double check | 02:21 |
| stekern | I guess you don't need to run the verilated model, but in case you are still interested: | 02:22 |
| stekern | first install systemc libraries and verilator: http://opencores.org/or1k/ORPSoC#Cycle-accurate_simulator | 02:23 |
| stekern | when that's done, all you need to do is run 'make prepare-vlt', 'ln -sf /path/to/vmlinux.vmem' and '../vlt/Vorpsoc_top' in the sim/run/ directory of orpsocv2 | 02:25 |
| stekern | that should have been 'ln -sf /path/to/vmlinux.vmem sram.vmem' | 02:26 |
| stekern | yeah, verilated model cares about the baudrate all right, but the orpsoc that is used for the simulation defines PRESCALER_PRESET_HARD and thus hardcodes the baud rate to 115200 | 02:40 |
| stekern | hmm, openocds usb-blaster driver doesn't seem to want to acknowledge sockit | 08:55 |
| stekern | maybe the low level chip isn't an ftdi anymore, have to take close look when I'm close to the board | 09:13 |
| stekern | because it fails when it tries to set the baudrate | 09:16 |
| stekern | olofk: I *know* you just sit on your board waiting for me to get gray hairs over this stuff, so you can jump in when the fun starts ;) | 09:21 |
| stekern | poke53282: not sure if you heard, but I got native gcc working a while back | 09:29 |
| -!- Netsplit *.net <-> *.split quits: andresjk, Logxen, hle_, poke53281 | 09:32 | |
| stekern | yup, no ftdi device, there is an cypress CY7C68013A-56BAXC there | 09:35 |
| olofk | stekern: Generating SoCs won't be part of the ORPSoC scope. It was initially, but I will stick with generating IP-Xact models (and the Altera equivalent if that's useful) and let tools such as Quartus, Kactus2 and Vivado take care of the system level. | 10:54 |
| olofk | It won't be dependent on those tools, though. It's just that I won't spend time on auto generating top-level connections. Just provide the means for other tools to do that | 10:55 |
| olofk | stekern: And I think I will have plenty of time to play with SoCKit soon. In addition to having a baby, I bought a house two days ago. I heard that those two things really help you free up some spare time to work on side projects :) | 10:57 |
| olofk | Didn't know that you got native GCC working either. That's really cool. Last thing I heard, there were some bison or flex problems | 10:58 |
| _franck_ | stekern: it is an embedded USB Blaster *II* | 11:38 |
| _franck_ | another good project to come: make an opensources driver for this adapter..... | 11:39 |
| olofk | _franck_: Isn't there already a driver in OpenOCD? | 11:58 |
| _franck_ | it for USB Blaster based on FTDI chips | 12:01 |
| _franck_ | or my be this new one uses the same protocol | 12:01 |
| stekern | _franck_: yeah, I suspect the "blaster" protocol is the same, so it's probably a matter of getting the data to the chip on a different manner | 13:03 |
| stekern | I'll indulge myself in some usb sniffing excercises | 13:04 |
| stekern | olofk: native gcc is working, self-hosting (i.e. compiling a native gcc with a native gcc) is not, but that's because of uclibc, not gcc | 14:33 |
| stekern | _franck_: weren't you going to the workshop too, or has it already been? | 14:34 |
| _franck_ | yes I did attend the workshop | 14:44 |
| _franck_ | that wasn't that good, the only question I asked let the guy without voice for a moment :) | 14:44 |
| stekern | so you're now a proud member of the sockittens | 14:44 |
| _franck_ | yep ! | 14:45 |
| _franck_ | I'm waiting for you to do the dirty job ;) | 14:45 |
| stekern | yeah, I'm not overly impressed with the workshop here neither, but I mostly went to get the goodie bag ;) | 14:46 |
| stekern | dirty jobs, just the way I like'em ;) | 14:48 |
| stekern | I didn't know wireshark can parse usb packages, that's handy | 14:49 |
| _franck_ | I did see that was on the interfaces choice but I never tried it | 14:49 |
| poke53282 | nice stekern. Did you use the gcc on https://github.com/openrisc/or1k-gcc | 18:53 |
| poke53282 | jor1k got a nice article on the hungarian unix portal http://en.wikipedia.org/wiki/Hungarian_Unix_Portal | 18:56 |
| poke53282 | Here is the link: http://hup.hu/cikkek/20130627/jor1k_javascript-ben_irt_linuxot_futatto_openrisc_1000_emulator | 18:57 |
| stekern | poke53282 yes, but it needs a (genric) patch that I've applied here: https://github.com/openrisc/or1k-gcc/tree/or1k-native | 19:18 |
| stekern | and cool news about the article! (not that I understand what the article says, but that's not so important in this context) | 19:20 |
| poke53282 | Ok, thanks. I will try it on my emulator. Just for fun. | 19:32 |
| poke53282 | I have also managed to compile and start a X-server for a few seconds before it crashes. | 19:33 |
| poke53282 | Wayland is not possible to compile. Too many errors. directfb still crashes. | 19:34 |
| poke53282 | I don't like software which are hardware dependent and don't provide a (slow) independent path. | 19:35 |
| stekern | wow, X-server would be nice ;) | 19:36 |
| poke53282 | Next I will implement a touch screen controller. | 19:36 |
| stekern | I've tried compiling apache, but it fails with bison | 19:36 |
| stekern | maybe I should try lighttpd | 19:37 |
| stekern | but the point with compiling apache was more to see if it would be possible than to get a web server | 19:38 |
| poke53282 | I am working on X. But more than xeyes, xclock and twm did not work. | 19:38 |
| stekern | lots to do still | 19:38 |
| stekern | ah, but you got that much working still | 19:38 |
| stekern | impressive | 19:39 |
| poke53282 | What I realized is actually that we need something like "Linux from Scratch" for or1k | 19:39 |
| poke53282 | I mainly followed the commands provided by the documentation. | 19:39 |
| stekern | yeah, and completion of eglibc would nice | 19:40 |
| stekern | +be | 19:40 |
| hno | stekern, I use busybox web server.. almost works. | 19:43 |
| poke53282 | At the moment I am fine with uClibc. But eglibc would be nice of course. | 19:44 |
| poke53282 | Trying to compile wayland I realized that also libffi is missing support for or1k. | 19:44 |
| poke53282 | But the big X11 did compile quiet well. | 19:45 |
| stekern | ah, yes, the missing libffi is something we'll need to address too | 19:45 |
| hno | I do have an automated busybox based root build. Need to patch openrisc uClibc a bit for current busybox.. (the upstream uClibc snapshot it's based on is borked) | 19:45 |
| poke53282 | So far I had to patch the .config file. But that is standard. | 19:46 |
| poke53282 | of uClibc I mean | 19:46 |
| stekern | hno: don't be shy to share it ;) | 19:46 |
| poke53282 | Linux still don't compile with the newest cross compiled gcc. | 19:47 |
| poke53282 | The final linking fails. | 19:47 |
| stekern | it does with or1k-elf-gcc | 19:47 |
| stekern | but that's a bit of a workaround | 19:48 |
| hno | stekern, it's a cherry-pick of 139b8f0c673fed465d27f99c98568e5d5e1b9b72 from upstream. | 19:49 |
| poke53282 | Ok, I don't have or1k-elf-gcc in my toolchain. How did you get it? | 19:50 |
| hno | stekern, is also included in the master-next branch. | 19:50 |
| stekern | we had a discussion about that a while ago: http://juliusbaxter.net/openrisc-irc/%23openrisc.2013-04-04.log.html | 19:50 |
| stekern | hno: master-next of what tree? git.openrisc.net? | 19:51 |
| hno | git://git.openrisc.net/jonas/uClibc | 19:52 |
| stekern | ah, ok, then I think it should be in here too: https://github.com/openrisc/uClibc-or1k | 19:52 |
| stekern | I based that on master-next iirc | 19:53 |
| poke53282 | Ok, thats it. I will never use Bugzilla again but will write my problems directly into this chat. | 19:53 |
| stekern | poke53282: you build for the or1k-elf target instead of or1k-linux-uclibc target | 19:54 |
| poke53282 | Jonibo wrote in the chat exactly what I realized in my bugzilla entry 6 month? ago. | 19:54 |
| stekern | poke53282: http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Newlib_toolchain_.28or1k-elf.29 | 19:57 |
| poke53282 | @stekern: Seems so. But I have never realized the real difference between or1k-elf- and or1k-linux-. | 19:57 |
| stekern | one is for baremetal (or1k-elf) and one is for linux userspace (or1k-linux-uclibc) | 19:58 |
| stekern | so different libc | 19:59 |
| stekern | basically | 20:00 |
| poke53282 | Ok, I understand. But it seems still like a workaround. I have looked up other architectures. They have directly implemented mul and div code in the kernel. | 20:00 |
| poke53282 | At the moment we rely on libgcc to link it into the kernel. | 20:01 |
| stekern | yeah, it's a workaround, and a hassle to have different toolchains to compile the kernel and userspace | 20:01 |
| poke53282 | Well, better than nothing. I tried to fix it myself but the libgcc code is so terrible for each architecture. Who is writing these. I didn't find an implementation that was similar to one of the others. | 20:03 |
| hno | stekern, yes that also have it. | 20:04 |
| stekern | dunno, but you can't really copy the libgcc code straight into the kernel neither | 20:04 |
| poke53282 | Ok, but thanks stekern. I will give it a try. | 20:06 |
| poke53282 | When I have a more or less working version of X with mouse support I will send a message in this chat. | 20:07 |
| stekern | that'll be terrific! =P | 20:07 |
| poke53282 | The first X11 running directly in a Web-Browser :) | 20:07 |
| poke53282 | s/directly/emulated/ | 20:08 |
| stekern | haha, yeah, that's awesome | 20:08 |
| hno | stekern, is the github openrisc uClibc maintained by anyone? The page you just linked refers to jonas repository. | 20:08 |
| hno | Ah, developmen version part of the page refers to the github one. | 20:10 |
| stekern | yes, it's part "of that package" so to say | 20:13 |
| hno | a bit condusing to have multiple "official" repositories for the same thing in the same project. | 20:15 |
| stekern | mmm | 20:16 |
| poke53282 | .... rebuilding toolchain .... | 20:16 |
| stekern | there are reasons for the spreadage of repos, but that's a long story | 20:19 |
| stekern | included in that story are also the reasons why we have several mailing lists for the same topic, which is even more confusing... | 20:21 |
| poke53282 | I can completely understand your confusion. I am confused as well. | 20:25 |
| poke53282 | forks, branches, copies.... | 20:26 |
| poke53282 | But this is how the system works. At least it is documented within git. | 20:27 |
| hno | stekern, it signals a strong sense of fragmentation... branches etc is one thing, but... | 20:27 |
| poke53282 | Most of the repositories on https://github.com/openrisc/ are forks. | 20:29 |
| hno | what github says is a fork or master do not mean much. | 20:31 |
| hno | when done "right" a project repository is normally starting as a fork of some personal repo. | 20:32 |
| stekern | hno: yes, I know, but as I said, there is a story behind it, Most of it can be read in the mailing list archives (take your pick of the two...) if you're interested ;) | 20:47 |
| stekern | but to make a long story short, some developers wanted to use git instead svn and traditional mailing lists instead of forums... and here we are | 20:50 |
| --- Log closed Fri Jul 05 00:00:13 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!