| --- Log opened Thu May 23 00:00:11 2013 | ||
| midwinter | Hi there | 01:40 |
|---|---|---|
| midwinter | I'm just reading up on OpenRisc for the first time.... would anyone happen to know an approximate minimum size (say in gates or slices) of an FPGA to get an OpenRisc core to boot linux? | 01:41 |
| midwinter | The largest FPGA that I can find in a solderable TQFP (ie. non-BGA) package is a Xilinx Spartan 6 XC6SLX9 that has about 10k slices | 01:53 |
| stekern | midwinter: I think you should be able to fit it onto that | 02:20 |
| midwinter | stekern: thanks. A lot of the boards I'm seeing for the OpenRisc have 20k slices, which makes me a little nervous, but I can't find anything larger than 9k in a solderable package | 02:22 |
| stekern | you probably can't fit much more than an openrisc core, uart and a memory controller | 02:26 |
| midwinter | I was hoping to write a camera controller in there too, but it should *ideally* be just some clocks and FIFOs hitting the SDRAM | 02:28 |
| midwinter | Will any of the OR cores work for linux, or do you have to use the OR1200 specifically? | 02:30 |
| stekern | mor1kx-cappuccino and or1200 are the ones that have MMUs (= can boot linux) | 02:31 |
| midwinter | wonderful, thanks for your help | 02:36 |
| midwinter | I'm working on the next model of a handheld device for my open source science tricorder project (www.tricorderproject.org), and I'm having trouble balancing the design requirements with a conventional microcontroller or microprocessor | 02:41 |
| midwinter | I've often used PICs, but they're often quite slow for display related things in that they don't have enough memory to do double-buffering | 02:41 |
| midwinter | in one design, I used an ARM9 to run linux, and it had 32meg of SDRAM, which was wonderful -- you didn't have to worry about agressive optimization just to display a bitmap | 02:42 |
| midwinter | but it was complicated and power hungry, and now all those chips are in BGAs largely | 02:42 |
| midwinter | so I was thinking of trying out an FPGA this time, that has the option of running linux. I've only done a little bit of FPGA-based projects before, so it'd be a neat learning project. | 02:43 |
| midwinter | but only if it has a good chance of working, of course | 02:43 |
| stekern | oh, there seems like there is a chance that this: https://cubieboard.myshopify.com/products/usd-breakout-board might work on the onda table to get access to UART0 and JTAG | 06:47 |
| stekern | at least if the sd-card slot is connected to SDC0_xxx | 06:48 |
| stekern | hno: have I understood it correctly, that in FEL boot, you're basically just able to read write the SRAM? | 06:53 |
| stekern | and the tool that it seems like you wrote does exactly that? | 06:53 |
| stekern | so if I'm not completely out in the woods, I believe I should be able to load some code for ar100 and a baremetal arm program to kick it alive using that tool | 06:59 |
| stekern | and then use the uart pins from the SD-card slot to get some input/output to it | 07:00 |
| stekern | that almost sounds too simple to be true | 07:00 |
| olofk_ | jtagconfig says No JTAG hardware available. What to do? :) | 07:02 |
| olofk_ | Do I need kernel drivers? | 07:02 |
| stekern | umm, no | 07:07 |
| stekern | I have this: | 07:07 |
| stekern | cat /etc/udev/rules.d/60-usbblaster.rules | 07:07 |
| stekern | ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666" | 07:07 |
| olofk_ | The udev rule is added, but still no luck. | 07:08 |
| stekern | is jtagd running? | 07:09 |
| olofk_ | Now it is :) | 07:09 |
| olofk_ | But still no luck. Should I expect something to turn up in /dev? | 07:09 |
| stekern | what does lsusb say? | 07:10 |
| olofk_ | lsusb can find it | 07:10 |
| olofk_ | Bus 001 Device 011: ID 09fb:6810 Altera | 07:10 |
| olofk_ | Do I need to run something as root? | 07:10 |
| stekern | and you did put that PID in your udev rules? | 07:11 |
| stekern | (it differs from mine) | 07:11 |
| olofk_ | Works as root. That's good enough | 07:12 |
| olofk_ | Yeah, 6810 is in my udev rule | 07:12 |
| olofk_ | thanks | 07:13 |
| olofk_ | Now I can resume the workshop :) | 07:13 |
| stekern | I think you should be able to use it as non-root if you kill jtagd and start it as your user | 07:14 |
| stekern | or something like that | 07:14 |
| olofk_ | I'll try that later when I get home | 07:14 |
| stekern | yeah, concentrate on the workshop now so you know what to teach me before mine ;) | 07:15 |
| olofk_ | It turns out that I'm a parody of a linux user. I have to start the workshop by recompiling the kernel :) | 07:16 |
| stekern | haha | 07:17 |
| stekern | if it wouldn't be SDC0 that is routed to the card slot, I think I still should be able to do some UART bitbanging | 07:29 |
| hno | stekern, yes. But you likely need to enable some clocks for the AR100 too. | 07:45 |
| hno | and it's almost certainly SDC0 that is routed to the sdcard slot. It's the reference and intended design and no one steers from it (except.. well another story) | 07:49 |
| hno | I would start with simple bitbanging to indicate any sign of life. The UARTs requires a bit of preparation to use (clock, clock gate, baud rate) | 07:51 |
| stekern | hno: yeah, I agree, toggling the pins is probably a good starting point | 08:03 |
| stekern | (enable clocks) true, but I think I should get all that info from how it's done in the kernel | 08:04 |
| hno | If there is something you don't find just ask and I'll dig it out for you. | 08:07 |
| hno | and the SoC is very similar to earlier generations. | 08:07 |
| stekern | don't worry, I probably will =P | 08:40 |
| stekern | hno: I think you are right about SDC0, if I read this (slightly confusing) code right: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/lib/board.c;h=5bd528e4ad49ca305eb176db3520309c2d5c72a7;hb=refs/heads/allwinner-sunxi-a31#l475 | 09:45 |
| stekern | the value -1 that I find in the extracted config from the firmware I'm running on the tablet should mean SDC0 | 09:47 |
| stekern | http://pastebin.com/2gCmgQqz# | 09:47 |
| stekern | line 30 | 09:47 |
| hno | stekern, yes, but line 768 is the right one. And it's SDC0 in SoC port PF as usual. Even dedicated SD-detect pin connected so you have an easy GPIO input to play with too. | 09:51 |
| stekern | ah, yes, there you get the info without reading the u-boot code, hadn't got that far, just searched for the "storage_type" string | 09:54 |
| olofk_ | Everytinh is working fine at the workshop. +1 for linux support | 11:53 |
| andresjk | the user app and ocspi driver interfacing is done by api or systemfile? I cannot see any ioctl within the .c of the driver so I guess is by API. The spi header don't have the prototypes of the functions implemented. Anyone knows where they are? | 16:52 |
| andresjk | Nevertheless, it does compile after some minor changes in the spi_opencores.c | 16:53 |
| -!- olofk_ is now known as olofk | 20:53 | |
| olofk | stekern: I did something incredibly stupid at the workshop. The ARM stuff required to be locked to a NIC, and since I was using a tethered android phone, that was what it chose to use | 20:55 |
| olofk | So now I need to have the damn phone connected in tether mode everytime I want to use the ARM debugger, which is a major pain since that uses one of the only two USB ports on my computer | 20:56 |
| --- Log closed Fri May 24 00:00:12 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!