| --- Log opened Tue Mar 31 00:00:45 2015 | ||
| stekern | olofk: what? did you give up on the bootloader? | 02:24 |
|---|---|---|
| olofk | stekern: Naah. I just tried to crowd source it | 05:52 |
| wallento | the binutils build is broken due to upstream changes | 07:51 |
| wallento | something with bfd, zlib and reloc | 07:51 |
| wallento | adding --with-system-zlib solves the issue | 07:55 |
| wallento | seems a new thing | 07:56 |
| Hesham | Hi bandvig: I was trying to run u-boot on Atlys yesterday, but it didn't work, even when I copied bootrom.v from orpsocv2 to work with fusesoc instead of the current infinite loop. Any hints? | 09:40 |
| olofk | wallento: That sucks. Is this with the binutils from git master? | 10:31 |
| bandvig | Hesham: 1st of all read the https://github.com/openrisc/orpsoc-cores/issues/79 and check in your wb_intercon.v that ROM uses addresses from 0xf0000100 to 0xf00001ff at least. | 10:34 |
| bandvig | Other potentially useful tricks: | 10:44 |
| bandvig | (1) Compiling anything with NewLIB toolchain use -mboard=atlys in compiler's command line. Perhaps, to add the option you need to modify appropriate Makefile. | 10:46 |
| Hesham | bandvig: Thanks. I modified two files according to the issue you indicated. It's synthesizing now. Hopefully this would work. | 10:51 |
| bandvig | (2) After Uboot is compiled: (2a) convert it to bin by or1k-elf-objcopy; (2b) modify the bin by adding size of the bin into begin of it by bin2binsizeword (a tool also from orpsocv2); (2c) load the modified bin into Atlys onboard SPI flash starting exactly from 0x1c0000 (the address is hardcoded in BOOTROM) | 10:56 |
| wallento | olofk: yes, thats upstream for like four days | 11:02 |
| bandvig | Hesham: Check the section "Fixing the bootrom code" from http://www.rte.se/blog/blogg-modesty-corex/writing-application-program/2.5 Pay attention that you should include bootrom.v into appropriate place of rom.v and comment any other ROM variants in rom.v | 11:05 |
| olofk | wallento: Good thing I changed the build instructions to use the tar balls instead :) | 11:05 |
| wallento | yes, already saw that | 11:05 |
| wallento | I changed the instructions on the newlib port site | 11:05 |
| wallento | reminder to ourselves: update build instructions when changing tarball :) | 11:06 |
| bandvig | Hesham: btw, on the link I entioned above you are able to check your bootrom.v. | 11:11 |
| Hesham | bandvig: All steps are followed as indicated thanks. I replaced the existing fusesoc/rom.v and replaced it by the orpsocv2/bootrom.v one with the hard-coded boot loader. | 11:13 |
| Hesham | bandvig: This is the line for generating the mcs file promgen -spi -p mcs -w -o orpsoc.mcs -s 16384 -u 0 orpsoc_spiboot.bit -data_file up 1c0000 u-boot-bsw.bin | 11:16 |
| Hesham | Where should BOOTROM definition exist? In rom.v? | 11:16 |
| bandvig | Hesham: I'm not sure tha I understand your question. Have you read the section "Fixing the bootrom code" from http://www.rte.se/blog/blogg-modesty-corex/writing-application-program/2.5 ? | 11:20 |
| Hesham | Yes. The bootloader should copy from flash memory starting with address 1c0000 right? | 11:24 |
| bandvig | Right | 11:25 |
| Hesham | This should be SPI_BASE? | 11:25 |
| Hesham | Nope. So where is this 1c0000 address defined in the code? No such address at the generated bootrom.v | 11:27 |
| bandvig | I don't remember exactly. Either in appropriate board.h or in bootrom.s in source tree of orpsocv2. And 1c0000 isn't SPI_BASE. It is initial address for uboot image inside flash. Pay attention on your promgen command line. | 11:30 |
| Hesham | Thanks I got it. | 11:34 |
| shentino | This project | 11:39 |
| shentino | sounds like a riscy proposition | 11:39 |
| Hesham | Good u-boot is working now. But I can't type commands. | 12:59 |
| bandvig | Hesham: !!! It was almost impossible !!! ))) | 13:20 |
| bandvig | Hesham: I mean the way to the success was trickly a lot ))) | 13:22 |
| Hesham | bandvig: Yeah. The problem was that the bootrom code wasn't getting the correct 1c0000 address. Thanks for your help. | 13:22 |
| Hesham | Indeed | 13:22 |
| Hesham | Do you have any idea why I can't type command to u-boot? | 13:23 |
| Hesham | From both putty and minicom | 13:23 |
| bandvig | Unfortunately, no ideas :( | 13:24 |
| Hesham | It was working fine with orpsocv2 | 13:25 |
| Hesham | Anyway, it's one step closer. | 13:25 |
| bandvig | I'm working under cygwin for compile and run toolchain. And I use TerraTerm (a terminal for Windows). | 13:28 |
| Hesham | Ah, I'm not using windows. I'll have to figure out what's wrong. | 13:32 |
| olofk | Hesham: We did a rewrite of newlib a while ago. I'm not sure that support for writing to the UART was ever fixed :( wallento, any updates? | 19:00 |
| Hesham | olofk: Support for hardware UART or what? IIRC it was working fine on or1ksim, RTEMS is using UART just fine too and it runs on both QEMU and or1ksim | 19:13 |
| Hesham | I tried to run RTEMS/hello.exe on Atlys a while ago (imitating u-boot), but this failed to output anything | 19:14 |
| stekern | rtems and newlib/libgloss uart drivers aren't related, no? | 19:15 |
| Hesham | Nope, RTEMS doesn't use any libgloss stuff | 19:15 |
| Hesham | only newlib | 19:15 |
| Hesham | But the implementation is almost the same. | 19:16 |
| olofk | Hesham: Ah sorry. s/newlib/libgloss | 19:16 |
| --- Log closed Wed Apr 01 00:00:46 2015 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!