IRC logs for #openrisc Wednesday, 2011-12-14

Franck_fixed, see mail list01:31
joniboolofk_htc: why do you think that or1ksim.cfg belongs in the kernel???12:28
jonibodependencies are top-down, not bottom-up12:29
juliusbthat was my thinking too. I can't recally seeing qemu configs or arm simulator configs in their branches12:29
jonibothere should be an or1ksim.cfg for the a sane kernel configuration in or1ksim itself12:30
juliusbwell, not their branches, in their arch paths12:30
juliusbjonibo: that's a good point, actually!12:30
juliusbwe should have some preset defaults built in I reckon12:30
juliusbone for newlib bare metal software, one for kernel12:30
joniboyeah, or1ksim should actually default to sane defaults even without a config file12:30
juliusbcurrently it assumes you don't want any memory - a bad assumption12:30
juliusbmmm, mabye I can fix this12:30
juliusbi think that'd be extremely handy for all or1k hackers12:30
olofk_htcjonibo: I just asked because some instructions assume that the file is there12:33
olofk_htcAnd since I have always cloned your git tree, I assumed it would be included upstream12:34
joniboright... no, I removed it when pushing upstream12:35
joniboyou can always get it back, though, if you have both git repos locally12:35
olofk_htcI see your points. We should probably vad some default configs to or1ksim instead12:35
jonibofor example, assuming you have two remotes 'upstream' and 'jonas', then you can pull out the or1ksim.cfg file like this:12:36
jonibogit checkout jonas -- arch/openrisc/or1ksim.cfg12:36
jonibo(I hope that's right... off the top of my head)12:36
olofk_htcIt's ok for me. Just need to direct the noobs to a good config file :)12:36
joniboyeah, i'd throw one into or1ksim proper... I think that's the best approach... or just make ork1sim work 'sanely' without a config file, like juliusb said12:37
olofk_htcMissed that, but I agree. Especially the memory should have a sane default12:38
juliusbthe most common use cases of teh simulator are running bare-metal and linux, so I reckon a default for both of those would be good12:40
olofk_htcWhat would be the difference between those two cases?12:42
joniboFor the Linux case, you needsat least 16MB or you can't boot the statically linked busybox image that everyone's using12:43
joniboi imagine you can get by with less for a bare-metal app, but a sane default should probably represent something that you can actually purchase on the market12:43
olofk_htcBut a standard set of peripherals could be the same, I guess12:44
joniboyeah, for sure...12:44
jonibojust the minimum really12:44
olofk_htcEthernet, uart, gpio(?)...12:45
joniboreally only UART, I'd say12:46
jonibobut there's an argument to be made for including ethernet12:46
juliusbwell maybe keep it in sync with the defconfig of the kernel?12:46
joniboyeah, exactly... I think that's UART and ethernet only12:47
juliusbolofk_htc: difference wouldn't be much I guess12:47
juliusbbut memory size and peripherals would probably be it12:47
juliusbnewlib's or1ksim default is pretty basic - doesn't even rely on a UART being there12:49
juliusband I guess makes an assumption about the clock frequency12:49
Franck_Hi there12:49
juliusbFranck_: hi12:49
jonibohi Franck_12:49
olofk_htcCouldn't we just det 16MB default if that's required for busybox? It can always be overridden in the cfg12:50
jonibosaw your email12:50
joniboyou don't need to be pulling in libgcc.c12:50
jonibothere's something wrong with the search path to libgcc.a in your toolchain12:50
Franck_the kernel does it too12:50
jonibotry running GCC in verbose mode (-v argument) to see where it's trying to find the library12:50
jonibothe kernel's a special case12:50
Franck_uboot too :)12:50
joniboalso a special case :)12:50
Franck_so as barebox :)12:51
joniboyeah, you may be right, come to think of it12:51
joniboI don't know enough about barebox12:51
juliusbolofk_htc: I reckon perhaps we find a default case that will be good for both bare-metal and the kernel defconfig12:51
Franck_barebox = uboot12:51
jonibo...but it sounds like a 'bootloader' type app12:51
juliusbperhaps overspecced for bare-metal but that's fine12:51
jonibojuliusb: overspecced is fine... it's better that it runs than that you get hit by strange errors like aborting during boot12:52
juliusbya I agree12:52
olofk_htcI'm not sure we even support a board with 8MB, except for a smaller variant of ordb112:53
Franck_jonibo: so you confirm I have no choice12:53
joniboyou're using -nostdinc?12:55
joniboyeah, you've got a 'freestanding' application, so you'll need to pull in support libraries by hand12:55
joniboi.e. you've got no choice12:55
juliusbI suspected that, too12:55
Franck_I'll try to get libgcc compile in my appli12:55
Franck_or a least missing functions12:55
--- Log closed Wed Dec 14 15:20:41 2011
--- Log opened Wed Dec 14 15:21:19 2011
-!- Irssi: #openrisc: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal]15:21
-!- Irssi: Join to #openrisc was synced in 156 secs15:23
--- Log closed Wed Dec 14 15:29:08 2011
--- Log opened Wed Dec 14 15:29:22 2011
-!- Irssi: #openrisc: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal]15:29
-!- Irssi: Join to #openrisc was synced in 22 secs15:29
TartarusHey all22:27
TartarusAnyone around with a board that can confirm USB works in U-Boot still?22:28
TartarusAnd preferably that can also build u-boot if I point at a github or so :)22:28
stekernTartarus: It worked last I tested, what is the issue?22:29
Tartarusstekern: The changes to make it work on openrisc broke ARM, and I've patched things so ARM works again22:30
TartarusAnd I hope, didn't break OR22:30
stekernah, Tom Rini?22:31
stekerndidn't make the connection, Stefan here22:32
TartarusYes, hi :)22:32
stekernI'll be happy to test your changes22:32
Tartarusk, thanks22:32
Tartaruskicking github now22:32
Tartarus(and work proxy, sigh)22:33
TartarusSigh, here's the patch stekern:
stekerngreat, thanks, I'll just set up the board with usb and test it22:37
Tartarusstekern: FYI there's also #u-boot where some of the other custodians hang out22:39
stekernah, I'll join (although I'm just a wannabe custodian so far ;))22:41
Tartarusheh, well now that /next is open maybe Wolfgang will merge the OR code22:42
TartarusAnd he's in there so you can ask him :)22:42
stekernright after breaking ARM is probably the right moment asking for favors? :P22:43
stekernI'm getting a compile error in usb.c:38423:04
stekernbreaking out a ep_wMaxPacketSize = get_unaligned_le16(..) and then doing the le16_to_cpus on that fixes that23:06
stekernyou're missing an & there too, but just adding that didn't remove all errors23:07
TartarusEr, what's the compiler error, first?23:08
stekernotherwise all looks good, I've got USB up and running without any bus errors with your patch applied and mine reverted23:08
TartarusAh, we can back out yours as well, OK23:09
TartarusI hadn't, just built on top :)23:09
TartarusSo, lemme spin up a v2 quick23:09
stekernoh, the error vanished in my screen backlog23:10
stekernw8 I'll bring it back23:10
* Tartarus assumes an ICE23:11
Tartarusis what you have now?23:14
TartarusI need to step away for a few, but if so, Tested-by: here and I'll put that in the patch once I figure out how to fix the checkpatch warnings23:18
TartarusDer, I thought I tried that and had a warning, but I don't23:19
stekernbut yes, you can add; Tested-by: Stefan Kristiansson <> on it23:21
stekernthanks for cleaning up the mess btw23:23

Generated by 2.15.2 by Marius Gedminas - find it at!