IRC logs for #openrisc Wednesday, 2013-06-12

--- Log opened Wed Jun 12 00:00:39 2013
stekernhno: looking through the Linux source, I see that the openrisc fw blob is loaded into 0x4000002:56
stekernis there usually a SRAM at that address or is this a31 specific?02:56
stekernthe datasheet says there is 32KB (@0) and 64KB (secure @0x00020000) internal srams03:01
stekernactually, looking at the kernel sources (platform.h) there seems to be even more srams spread out there: http://pastie.org/803565403:02
stekernanyways, reading out addresses >0x40000 in from FEL gives you the firmware blob from linux03:03
stekernso it seems to add up03:03
stekernthe ar100 firmware blob, that is03:04
hnoDid 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
hnoAnd yes there is a whole lot more SRAM than what is said in the overview section.06:02
stekernI'm still using the power off, home button + 3 x power on06:26
stekernbut even with hard reset chances are that uninitialized == what linux last wrote there, due to data remanance06:28
stekernit's not like I left it in power off (how completely power off that is is also questionable) for a very long time06:29
olofkI saw some OpenRISC-related tweets with this link http://tocos-wireless.com/jp/products/TWE-001.html10:42
olofkSeems to be an OpenRISC-based Zigbee thingie.10:42
olofkGoogle translate wasn't much help here and my japanese is limited to common anime phrases10:44
stekernlooking at the datasheet one can spot the words JENNET/ZigBee PRO10:52
stekernwhich leads to jennic, which are known to have used openrisc in their zigbee chips10:53
stekernhttps://github.com/teco-kit/Jennisense/wiki/Jennicgettingstarted10:54
stekernfel doesn't seem to be able to properly write into the 0x40000 area13:50
stekernsome words go in there and some don't13:50
larkstrying 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
stekernlarks: that depends a lot on the system, if both go to the same external bus through an arbiter, then of course none19:04
stekernup to on-chip ram, where the difference potentially could be twice as slow/fast19:05
stekernI meant to say "to the same external memory" up there19:05
larksit's all on-chip, just an openrisc, uart and 4kB BRAM on an FPGA19:10
larksThe BRAM is dual ported and hooked up to another bus19:10
larksso I'm guess having two busses might be better then19:13
olofkI never get that weird timescale right. After I removed a core in a design, I suddenly have a different timescale20:00
stekernwow, those allwinner guys have done a pretty clever thing to work-around our braindead exception vectors21:10
stekerngot me confused for a good while here though21:11
stekernthey have some address decoding going on, only the 2 first words at every exception vector are actually wired to the SRAM21:12
stekernthat's why I thought that fel can't write the SRAM at 0x4000021:13
stekernactually, it seems it is only the first word at %0x100, I think the l.nop is hardwired too21:14
stekernso, I think the actual SRAM starts at 0x4400021:19
stekernI can read and write that normally at least21:19
stekernbedtime again, *tomorrow* I will have the ar100 doing the infamous "Hello world!" =P21:24
olofkHmm... 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!