IRC logs for #openrisc Saturday, 2014-04-26

--- Log opened Sat Apr 26 00:00:21 2014
stekernblueCmd: you mean the bootrom generator03:59
stekernthis pkg-config bug drives me crazy...06:24
stekernhuh... seems like readdir doesn't work at all in my qemu-uder environment...08:21
stekernblueCmd: look at this:
stekerncan you try running that in your qemu-user environment?08:27
stekernI bet it works since your pkg-config works... but just to be sure08:28
stekernwhat is wrong with my that makes that not work?08:28
blueCmdstekern: are yourunning the new libc?08:32
blueCmdi'm not08:33
blueCmdandit worksfor me08:33
stekernand note, it works perfectly when running under a real kernel in or1ksim08:33
blueCmdI'll try with the new libcas well08:33
blueCmdspace is not very good today08:33
stekerncould be your thumb that is weak too08:34
blueCmdI cannot install this libc anymore, apt crashes while installing it08:37
blueCmdI know i tested it before08:37
blueCmdah, I'm trying with an older one08:38
blueCmdI should delte that one, I know it's broken08:38
stekernI have had no problems with the new one08:41
stekernunless this is related ;)08:41
stekernbut I kind of doubt it is...08:42
blueCmdnope, it works with the new one as well08:43
stekernwhat kind of host are you running on?08:43
blueCmdamd64 debian08:43
blueCmd3.13.7-1 to be exact08:44
stekernx86_64 ubuntu 3.11.0-14 here08:44
blueCmdmaybe my ./configure run for qemu made something specific08:45
blueCmdsounds farfetched though08:46
blueCmdbut you can build qemu, shouldn't be hard08:46
stekern...I already tried that, hence driving me crazy...08:46
stekernnext is adding some debug prints in that I guess08:47
stekernwhere are the syscalls translated?08:49
blueCmdwhen you build they are generated in the build-directory08:52
blueCmdI don't recall the details, but it's kind of messy08:53
blueCmdthere is a list of syscalls with their declarations, and if the build system cannot find a file with an override it will generate one by smashing macros together08:53
stekernhmm... sounds like fun08:54
stekernI guess getdents64 will be used by openrisc to implement readdir()08:55
blueCmdyou can use strace you know that right?08:57
blueCmdwell, not in qemu08:57
blueCmdbut stracing on the board will show which call is used08:57
stekernright, that's a good idea08:58
stekern...but my guess was right, getdents64 it is09:00
stekernand on x86_64 getdents is used09:02
stekernsanity check, getdents is used in your setup too?09:03
blueCmdI don't know, I cannot strace :)09:03
blueCmdI don't have any hardware09:03
stekernumm, can't you strace on your amd64 machine?09:04
stekernI mean, if you compile and run my readdir, then getdents are used09:05
blueCmdqemu doesn't support ptrace09:05
blueCmdso I would have to strace qemu09:05
stekernno, I mean on your amd64 machine09:05
blueCmdstand by09:06
stekernok, so far everything makes sense then...09:10
stekernI would assume our getdents64 get translated into getdents64 though09:11
Findetonso I want to create an ext2 partition on the linux openrisc sim, how can I do it?09:54
blueCmdFindeton: how do you mean?09:59
blueCmdto create the partition you would use fdisk and mkfs.ext2, but I guess what you want is an actual partition first?09:59
blueCmdlike a block device or something to store stuff on10:00
FindetonblueCmd: yes, I mean, from what I understand the linux sim starts with a ramfs10:02
blueCmdI don't think or1ksim supports block devices currently10:03
blueCmdI would use a network block device or NFS10:04
blueCmd(or implement support for it)10:04
stekernit does10:04
Findetonstekern: so how do I do it? :p10:05
stekernpoke53281 used it, but I'm not sure if all his fixes made it to the or1ksim repo10:05
blueCmdaha, ata controller10:07
Findetonstekern: so I can create a block device and format it as ext2 and fill it with data so that when I start the linux sim I get a "proper" system?10:07
blueCmdFindeton: the bottom has an ATA block there10:08
blueCmdyou should be able to play with the values there10:08
Findetonso it's the last part, and I must add some more lines following the commets' instructions10:10
Findetonwell I'm reading my sim.cfg and it's a little bit different, it already has a device and it's type 1. There are types 0,1 and 2 but I don't know the difference, maybe this is the ramfs?10:15
blueCmdis it an ata device then?10:16
FindetonI guess a ramfs cannot be an ATA device, it would make no sense lol10:16
blueCmdcan you post your config?10:16
Findetonyeah 1 sec10:16
Findetonso it looks like I already had an ata device and I didn't even know it?10:18
Findetonoh, but it was disabled10:18
stekernhmm.. in qemu-user, errno get set to 75 (Value too large for defined data type)10:27
blueCmd"yo mama" or something10:28
blueCmdsounds like the padding issue again10:28
blueCmdbut that doesn't really make much sense10:28
stekernyeah, but this whole issue doesn't make any sense10:34
stekernI've added debug prints in qemu where the getdent64 syscall is issued, it goes through all fine and a non-zero value is returned10:35
FindetonblueCmd: I copy-pasted the wrong .cfg file, that's not the one I'm actually using lol10:36
stekernnon-zero positive value, I might add10:36
Findetonbtw, if I change the .cfg I don't need to rebuild the kernel right?10:37
blueCmdIt's not 100% the same since debian uses eglibc and not the same version, but that should be the code for readdir10:39
stekernyes, I have that file open here10:43
stekern...but errno is not set in that10:46
Findeton... so, I modify the .cfg file like this:
Findetonis that correct? do I need to create a file called "ata_device"? Do I need to rebuild the linux kernel? how do I know this worked?10:56
blueCmdFindeton: if you look at your arch/openrisc/dts/or1ksim.dts (the path might not be correct, but the filename should be or1ksim.dts)10:57
blueCmdyou need to have the ata device referenced there (unless we do autodetection for it, which I don't think we do)10:58
Findetonyes, it's on linux/arch/openrisc/boot/dts/or1ksim.dts, lets see11:01
stekernI don't know if there are dts bindings for ata devices11:05
stekernit's just a generic driver that is used11:05
Findetonat the end of that web it looks like there's a dts file mod11:07
Findetonafter a dts mod, do I need to rebuild the kernel? :p11:10
stekernah, right so there are device tree bindings11:12
stekernyes, you need to rebuild after modifying the dts file11:13
Findetonok thanks stekern11:14
Findetonbut not after only modifying the .cfg file because that's a or1ksim thing right?11:15
stekernblueCmd: where is syscall() defined in glibc?11:16
Findetonso now I have rebuilt it and booted linux, how do I know it worked?11:18
stekernnm, I found it11:30
FindetonI see now stekern12:42
Findetonjust as you said, this change was never accepted
Findetonpoke53281 is sebastian ?12:45
Findetonand when he talks about CONFIG_BLOCK=y, that's a configuration parameter during the build, in the command like itself?12:52
Findetoni think I make too many questions :'p12:52
stekernno, it's a kernel CONFIG_ knob12:53
stekernblueCmd: there has to be something that goes wrong in INLINE_SYSCALL that somehow goes wrong13:06
stekernthere has to be something that goes wrong in INLINE_SYSCALL13:07
stekernI can call getdents64 and I get the right return number back13:08
stekern(which is > 0)13:08
blueCmdstekern: I appriciate the effort you put into debugging this :)13:14
stekernthat's my current test13:14
stekernwell, it's hard to build anything with a disfunctional pkg-config13:15
blueCmdthere is a kernel thing you set in glibc to say which minimum kernel i supported13:16
stekernhmm.. is that > 3.1113:16
stekernanyway, I'll continue and bring in the stuff from INLINE_SYSCALL to see if anything falls out13:18
stekernI just don't understand what's different in our setup13:18
stekernhost setup is kind of out of the picture now, since everything at the qemu syscall border is ok13:19
blueCmdthere is some custom errno handling in glibc13:19
blueCmdthat calls a separate function and stuff IIRC13:19
stekernall errno stuff that's involved now is in INLINE_SYSCALL13:20
stekernno... imitating INLINE_SYSCALL didn't make anything fail...13:29
stekernhmm... actually... the __GETDENTS here:
stekerndoesn't evaluate to INLINE_SYSCALL(getdents6413:46
stekernas I thought13:46
blueCmda lot of arches included that file13:46
blueCmd(I didn't bindly copy all those because I wanted to know they were needed)13:47
blueCmdMaybe this one is then13:47
blueCmdlike so13:47
stekernhmm... no13:48
stekernor.. I'm not sure what you are saying13:49
blueCmdfrom your observations13:49
blueCmdwould it make sense to do:13:49
blueCmd#define __READDIR __readdir6413:49
blueCmd#define __GETDENTS __getdents6413:49
blueCmd#define DIRENT_TYPE struct dirent6413:49
stekernah, yes, I think so13:50
stekernthat's the one that is used I believe13:50
blueCmdI'll build you a with that change13:51
stekerngreat, trying to mimic that __getdents didn't look any fun ;)13:52
stekernI'll be afk for a couple of hours, but I'll check the backlog in the evening if there's a present waiting for me ;)13:52
blueCmdagain, thanks for not giving up on it - these issues are golden to have other people to help me debug :)13:53
blueCmdstekern: sorry, but I think I mixed stuff up. Do you want to use the getdents or the getdents64 syscall?14:47
blueCmdIt wasn't as easy as I thought14:47
blueCmdI'm building something that could work, but we need to look closer on this I think15:02
blueCmdno, this doesn't make sense15:12
blueCmd./sysdeps/unix/sysv/linux/readdir64.c is ofc the file used to create the readdir call15:12
blueCmdand that does those 3 defines15:12
Findetonstekern: so I applied the patch
Findetonand rebuilt the kernel15:18
Findetonbut I don't know how to proceed!15:18
FindetonI don't see a new device that I can format15:18
blueCmdFindeton: have you read dmesg and verified that the ATA shows up?15:19
Findetonno, lets see15:19
FindetonI don't see the ATA there either15:21
Findetonthat's the dmesg output15:22
Findetonand for the changes I did on the kernel, it's just the patch
FindetonMaybe I also need to create a file and add it's name to the or1ksim.cfg ?15:23
Findetonthe file being the device15:23
blueCmddid you add init = 1 to or1ksim?15:24
Findetonmmm no, lets do it15:26
blueCmdyes, follow the instructions carefully when doing these things is my recommendation15:26
FindetonI try but sometimes I do not understand the help :/15:30
Findetonfor example, it says dev_file0/1 = "<filename>"15:30
Findetondo I need to create a file myself? do I put the whole path of the file or just the name?15:31
blueCmdtry :)15:31
blueCmdit's not going to blow up if you do the wrong thing15:31
Findetonthat's a pity, it could be spectacular15:32
Findetonmm now that I'm looking, there's a 100MB "ata_file0" file on the root of linux source code now15:34
Findetonlets delete it and rebuild the kernel to know if it's created beforehand15:35
Findetonuhm there's a problem when I boot the sim: Warning: ./arch/openrisc/or1ksim.cfg: Unrecognized parameter: init at line 876; ignored.15:38
blueCmdFindeton: right, did you patch or1ksim as well?16:04
FindetonblueCmd: nope16:41
stekernhmm... blueCmd I don't know, obviously my brain isn't a good enough preprocessor, and I'm not familiar enough with glibc sources to tell... but the __GETDENTS that get used in readdir (pkg-config calls readdir, not readdir64) is the one in
stekern...because, looking at the asm output of readdir it matches that16:45
stekern...but that might be a correct thing to do, call that... not sure16:47
blueCmdFindeton: :) please, again, pleease read the instructions :P the email message contains 3 patches for a reason you know16:54
Findeton:) that's true16:55
blueCmdstekern: i'm adding some #error's in the glibc code, maybe I can catch this in the compiling stage16:55
stekernit could actually be this too:
blueCmdso the sysdep/posix/readdir.c is included without the defines16:57
stekernyes, that much I already knew16:57
stekernthe including in readdir64.c is just to reuse the code for readdir64()16:58
blueCmdah makes sense16:59
stekernand, you need to do conversion from getdents64 to getdents to be able to use it in readdir()17:00
blueCmdbut is it readdir or readdir64 that fails?17:00
stekernnow the question is that which of the two getdents are actually used of the two links I pasted17:01
stekernmy bet is on the second17:01
stekernit's readdir that fails17:02
stekernwhich gives us something interesting to test - readdir6417:02
stekern(spending time on this) yeah, well, you know what I said last week... if I give up now, the time has just been wasted ;)17:03
blueCmddanmn right!17:04
stekernbesides, I'm learning a lot, which is the only real motivation I have to poke around with openrisc17:04
blueCmdI'll #error the different ones17:04
blueCmd../sysdeps/unix/sysv/linux/generic/wordsize-32/getdents.c:33:2: error: #error "wordsize-32 getdents.c included"17:05
stekernok, so I lost the bet17:09
stekernbut good, then we know17:10
blueCmddo you want me to build with the other one?17:10
stekernwhere is that decision made?17:18
blueCmdit's the least specific17:25
blueCmd(posix, linux, wordsize-32, or1k)17:26
blueCmdby creating a or1k/getdirent.c that points to linux for example, I can make it explicitly use that17:26
Findetonhow do I config those kernel knobs? like CONFIG_ATA_SFF=y, is it done with make menuconfig?17:31
blueCmdor just edit .config17:32
Findetonlol ok17:34
Findetonso when I introduce the changes in the .config, when I rebuild the kernel it starts to ask me questions18:43
Findetonis that what CONFIG_BLOCK is supposed to do?18:43
stekernblueCmd: so, with the new info from wordsize-32, the mystery is starting to unravel. So, if d_ino or d_off in dirent are to large to fit in a 32-bit storage, then readdir will fail19:42
Findetonstekern: is it normal that once I add the config knobs when compiling the kernel it asks me lots of questions instead of compiling it by itself? :p19:44
blueCmdFindeton: you forgot the ARCH=openrisc to make19:45
blueCmdor you corrupted the .config file19:45
FindetonI probably corrupted the .config19:45
stekernblueCmd: can you try that in your qemu-user setup?19:48
blueCmdstekern: I will after this game of dot!19:48
stekernI was hoping for a 'dott*'19:49
stekernno fails20:26
stekernso, everything makes sense20:26
stekernexcept one thing, why does the printf of 64-bit values fail?20:27
stekerni.e. the dent->d_ino20:27
stekernthat's of course unrelated to the readdir problem, but interesting nonetheless20:28
blueCmd is kinda nice20:30
stekernone thing that doesn't make sense though, how did 'ls' work for me?20:32
stekernafaict ls use readdir20:32
stekernwhat is wannabuild showing?20:33
blueCmdstekern: it's showing packages that are built, needs to be updated and progress in doing so20:34
blueCmdyou can see stuff like this:
stekernah, ok. cool20:37
blueCmd we have that now as well20:38
blueCmdstekern: have you tried simply rebuilding pkg-config?20:40
blueCmdmaybe it's the ABI between app <-> libc that is broken by the padding or something20:40
FindetonblueCmd: just by adding the "CONFIG_BLOCK=y" line to the .config, linux thinks I have corrupted the file20:43
Findetonmaybe I need to insert that line in a particular place on the file?20:43
blueCmdyou shouldn't need to20:44
blueCmdit might ask you questions related to that though, if it needs to know stuff related to ATA20:44
FindetonSupport for paging of anonymous memory (swap) (SWAP) [Y/n/?]20:45
Findetonthings like that?20:45
blueCmdSwap would require block20:46
blueCmdyou don't need that though20:46
stekernblueCmd: yes, rebuilding it of course doesn't work... since readdir() fails, since my d_inos (or d_offs) are too large20:47
stekernI've hacked around it by using readdir64 now, so I've got a working pkg-config though20:49
blueCmdit's so weird though20:50
blueCmdit's only in qemu it doesn't work for you?20:51
stekernI don't know, I think it makes sense now20:51
blueCmdin that case, please recap!20:51
stekernI'll try. the readdir implementation in glibc uses '__getdents'. __getdents uses sys_getdents64 and 'converts' it to a sys_getdents call. if the data returned by sys_getdents64 is to large, the conversion will fail.21:01
stekernand by data, I mean inode numbers and offsets.21:05
stekernd_ino and d_off in that struct21:06
blueCmdso where would the bug be?21:09
stekernso, you were just lucky that it happened to work on your machine21:09
stekernit's not a bug, it's a feature ;)21:09
stekern*but*, take a look at this:
stekernnotice how the struct dirent {}; use ino_t d_ino and off_t d_off21:10
stekernso, why does (our) glibc use some compatibility layer around sys_getdents64 and turn it to a sys_getdents21:13
blueCmdI thought you said it was the other way around?21:14
blueCmd"the readdir implementation in glibc uses '__getdents'. __getdents uses sys_getdents64"21:15
blueCmdreaddir should just use getdents64 directly then21:15
stekernI think what I just said was a bit open for interpretation.21:16
stekernlook at this:
stekerndo __USE_FILE_OFFSET64 get defined?21:17
mohessaidI want to ask you something about cross compiling asterisk for openrsic 1200 using the uclibc toolchain21:18
blueCmdmohessaid: ask away21:19
mohessaidI encoutred this error in the last task in of the cross compiling process:
blueCmdstekern: that is defined if #if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 6421:20
stekern(I don't think it does, and the follow up question is, why not?)21:20
mohessaidthis error is showing up in all asterisk's version from 1.4 to 1.821:20
blueCmdstekern: I'm hunting it down!21:21
stekernand readdir should IMO just do what readdir64 does21:21
mohessaidok please21:21
mohessaidI asked them in the support forum in the asterisk-dev mailing list and in asterisk-embedded mailing list and there is no helpfull response21:22
stekernthe whole readdir64 thing looks like something that ulrich drepper came up with but then was 'dropped'21:23
stekernnot sure about that though21:23
blueCmdmohessaid: hah, that's not a helpful response from them21:26
mohessaidyes I know, I think they don't want to spend their time in compiling the toolchain from scratch and then asterisk and of course ncurses in between21:27
blueCmdyeah, you cannot ignore the command that tries to link the "asterisk" binary - that's a bad idea :)21:27
blueCmdso you need to figure out why you don't have the resolv library21:28
mohessaidof course it is, but I was in a helpless situation that let me think like that, I was trying to compile it around a month or more21:29
blueCmdstekern: ../include/features.h:309:2: error: #error "We need __USE_FILE_OFFSET64"21:31
blueCmdso far you're correct21:31
mohessaidbut what do you think about the -lresolv option mentioned by the linker, when I tried to omit it from the makefile and then execute make again some errors shows up21:31
blueCmdno, you need it21:32
blueCmdyou need to find why you don't have it21:32
blueCmdit's most likely a fault in how you set up uclibc (or possibly gcc)21:32
blueCmddoes asterisk support uclibc on other platforms?21:32
mohessaidI didn't try it but I think it support uclibc, because they mentioned in the version 12 that they are working to make it more supported to uclibc21:35
blueCmdso no, it's not supported21:37
stekernyou can enable that, then the -lresolv will not fail, but it's not going to work if asterisk use anything from it21:37
mohessaidok, I will try it21:38
blueCmdstekern: that would be the same as leaving out -lresolv right?21:40
blueCmdmohessaid: you tried that right?21:40
mohessaidso it is the same21:41
mohessaidok sorry stekern21:41
blueCmdso, what do you want really? what's the end goal?21:41
stekernoh, I didn't really expect asterisk to link against libresolv unless it used something from it, so don't be sorry21:43
mohessaidwe are building a pbx using the openrisc 1200 porcessor and we want to make asterisk run on our platform21:43
blueCmdstekern: you should sell mor1kx to them :)21:43
blueCmdmohessaid: right, would using glibc be an option?21:43
mohessaidok if the result will work on linux provided by opencores "linux from jonas"21:45
mohessaidoh thanks a lot, I will try it now21:47
mohessaidany recomendations or hints, because I will leave to try it?21:47
blueCmdmohessaid: remember that you need a compiler for "or1k-linux-gnu" and not "or1k-linux-uclibc" for it to work21:47
mohessaidthank you21:48
blueCmdmohessaid: that's the file I use to build it, it will not work for you straight off but if you get stuck you can see what options I used when building it21:48
blueCmdstekern: if we change this define it will break the ABI, right?21:49
blueCmd__USE_FILE_OFFSET64 that is21:49
stekernwhat ABI?21:51
blueCmdthe 4000 debian packages and libc21:51
blueCmdsince the struct changes21:51
stekernah, right21:52
blueCmdstekern: so actually reading the big comment in features.h these should be defined by the compiler21:59
stekernwhere's features.h22:00
blueCmd_FILE_OFFSET_BITS  is undefined22:01
blueCmd_LARGEFILE_SOURCE is defined, so that's good22:02
blueCmd#define __ILP32_OFFBIG_CFLAGS   "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" in bits/environments.h22:05
blueCmdmaybe that's how it does it22:05
mohessaidthe or1k-devel contain files to be added to linux direcotry?22:09
blueCmdmohessaid: you don't _need_ anything from there I think - it's just my development directory22:10
mohessaidah, ok22:10
blueCmdbut feel free to use it as inspiration22:10
mohessaidI will22:10
blueCmdstekern: hah, this is the most stubborn constant I have ever tried to find22:14
blueCmdI'm going to build glibc natively to see if I can get gcc to say where it was defined22:15
stekern didn't fix xmkmf22:16
blueCmddid you try with RAWCPP=..whatever.. ?22:17
stekernnot yet22:18
mohessaidblueCmd: I must build the toolchains from scratch using glibc in place of uclibc or just install it on the existing one22:31
blueCmdmohessaid: from scratch unless you want a system with two libcs22:32
mohessaidI will build it from scratch, but when I was reading the readme file, install file, I think you didn't mentioned how to build it for this toolchains like they did with uclibc in opencores22:35
blueCmdstekern: I'm giving up on finding it - if it becomes a real problem in the future we will need to look into it, it's getting very deep into the rabbit hole22:35
blueCmdmohessaid: I don't think i have a README file22:36
blueCmdmohessaid: In the makefile you have all the commands to build the toolchain, I don't use anything else - everything is in there.22:37
mohessaidAh, so the or1k-glibc just a clone of the normal glibc and the or1k-devel contain your files used to build for the toolchain22:38
blueCmdor1k-glibc is a clone + or1k patches22:39
mohessaidso the README in or1k-glibc is the original one, sorry for the confiosen22:40
mohessaidok, thanks for the illustation22:41
--- Log closed Sun Apr 27 00:00:23 2014

Generated by 2.15.2 by Marius Gedminas - find it at!