| --- Log opened Wed Jun 12 00:00:39 2013 | ||
| stekern | hno: looking through the Linux source, I see that the openrisc fw blob is loaded into 0x40000 | 02:56 |
|---|---|---|
| stekern | is there usually a SRAM at that address or is this a31 specific? | 02:56 |
| stekern | the datasheet says there is 32KB (@0) and 64KB (secure @0x00020000) internal srams | 03:01 |
| stekern | actually, looking at the kernel sources (platform.h) there seems to be even more srams spread out there: http://pastie.org/8035654 | 03:02 |
| stekern | anyways, reading out addresses >0x40000 in from FEL gives you the firmware blob from linux | 03:03 |
| stekern | so it seems to add up | 03:03 |
| stekern | the ar100 firmware blob, that is | 03:04 |
| hno | Did you do a soft or hard reset to get into fel? If a hard reset then I would expect the ar100 to still be uninitialized and the firmare area blank. | 06:02 |
| hno | And yes there is a whole lot more SRAM than what is said in the overview section. | 06:02 |
| stekern | I'm still using the power off, home button + 3 x power on | 06:26 |
| stekern | but even with hard reset chances are that uninitialized == what linux last wrote there, due to data remanance | 06:28 |
| stekern | it's not like I left it in power off (how completely power off that is is also questionable) for a very long time | 06:29 |
| olofk | I saw some OpenRISC-related tweets with this link http://tocos-wireless.com/jp/products/TWE-001.html | 10:42 |
| olofk | Seems to be an OpenRISC-based Zigbee thingie. | 10:42 |
| olofk | Google translate wasn't much help here and my japanese is limited to common anime phrases | 10:44 |
| stekern | looking at the datasheet one can spot the words JENNET/ZigBee PRO | 10:52 |
| stekern | which leads to jennic, which are known to have used openrisc in their zigbee chips | 10:53 |
| stekern | https://github.com/teco-kit/Jennisense/wiki/Jennicgettingstarted | 10:54 |
| stekern | fel doesn't seem to be able to properly write into the 0x40000 area | 13:50 |
| stekern | some words go in there and some don't | 13:50 |
| larks | trying to create a small system for a test, what's the diff in perf when there's a ibus and dbus vs just one bus? | 18:29 |
| stekern | larks: that depends a lot on the system, if both go to the same external bus through an arbiter, then of course none | 19:04 |
| stekern | up to on-chip ram, where the difference potentially could be twice as slow/fast | 19:05 |
| stekern | I meant to say "to the same external memory" up there | 19:05 |
| larks | it's all on-chip, just an openrisc, uart and 4kB BRAM on an FPGA | 19:10 |
| larks | The BRAM is dual ported and hooked up to another bus | 19:10 |
| larks | so I'm guess having two busses might be better then | 19:13 |
| olofk | I never get that weird timescale right. After I removed a core in a design, I suddenly have a different timescale | 20:00 |
| stekern | wow, those allwinner guys have done a pretty clever thing to work-around our braindead exception vectors | 21:10 |
| stekern | got me confused for a good while here though | 21:11 |
| stekern | they have some address decoding going on, only the 2 first words at every exception vector are actually wired to the SRAM | 21:12 |
| stekern | that's why I thought that fel can't write the SRAM at 0x40000 | 21:13 |
| stekern | actually, it seems it is only the first word at %0x100, I think the l.nop is hardwired too | 21:14 |
| stekern | so, I think the actual SRAM starts at 0x44000 | 21:19 |
| stekern | I can read and write that normally at least | 21:19 |
| stekern | bedtime again, *tomorrow* I will have the ar100 doing the infamous "Hello world!" =P | 21:24 |
| olofk | Hmm... did someone forget to include a return statement in verilog? | 21:44 |
| --- Log closed Thu Jun 13 00:00:41 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!