| 00:12.02 | *** join/#edev flyhorse|linux (~flyhorse|@116.4.160.72) |
| 00:13.49 | *** join/#edev miltonm (~miltonm@71.22.91.79) |
| 00:27.11 | *** join/#edev mdm2 (~miltonm@71.22.91.79) |
| 00:51.09 | *** join/#edev djerome (~djerome@ip24-251-158-189.ph.ph.cox.net) |
| 01:08.35 | *** join/#edev miltonm (~miltonm@71.22.91.79) |
| 01:17.32 | wmat | rhett: are you sure you have RTC support in your kernel? |
| 01:28.37 | rhett | wmat, there are 2 custom rtc kernel modules, and they're in /dev/misc/hi_rtc and /dev/misc/hh_rtc |
| 01:28.48 | rhett | I mean, the devices are there, and the kernel modules are loaded |
| 01:33.06 | wmat | rhett: try symlinking one to /dev/rtc |
| 02:04.04 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 02:24.15 | rhett | wmat, I did that it it said it's unable to read it |
| 02:24.28 | rhett | not the same "can't access" error though |
| 03:02.11 | *** join/#edev kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 03:13.44 | *** join/#edev kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 03:16.38 | *** join/#edev miltonm (~miltonm@71.22.91.29) |
| 03:45.29 | *** join/#edev kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 03:47.05 | *** join/#edev kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 03:54.24 | *** join/#edev djerome (~djerome@ip24-251-158-189.ph.ph.cox.net) |
| 05:22.52 | *** join/#edev mbuf (~mbuf@118.102.130.6) |
| 06:23.46 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 06:30.16 | *** join/#edev calculus (~calculus@gentoo/user/calculus) |
| 08:19.35 | *** join/#edev linac (~lin@122.90.137.121) |
| 09:03.37 | *** join/#edev SandGorgon (~OmNomNomO@122.160.41.129) |
| 09:04.06 | *** join/#edev SandGorgon_ (~OmNomNomO@122.160.41.129) |
| 09:33.35 | *** join/#edev cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 10:06.13 | *** join/#edev mne (~mne@unaffiliated/mne) |
| 10:13.50 | mne | Hi guys. On the AT91 platform with a linux kernel I have a UART related question: I'm planning to use RTS/CTS hardware flow control. Hence a sender may only transmit data if CTS is high. But how do I know that in a userspace application ? Do I need to use ioctls on the serial port file descriptor and only write to the port if CTS is high ? Or can I use poll() with POLLOUT on the serial port fd ? |
| 10:23.42 | SpeedEvil | it's handled in hte driver |
| 10:24.05 | SpeedEvil | It will block if you write to it with flow control setup, but CTS high |
| 10:24.25 | mne | the hte driver ? |
| 10:24.33 | SpeedEvil | The normal serial driver |
| 10:24.36 | mne | ah, ok |
| 10:25.07 | mne | So I could just endlessly write to the serial port and it will automatically block if CTS indicates that the other side is not ready ? |
| 10:25.22 | mne | Does that mean that I can also use poll() with POLLOUT on the serial port fd ? |
| 10:25.46 | SpeedEvil | yes |
| 10:25.51 | mne | cool, thanks |
| 10:25.51 | SpeedEvil | to the first |
| 10:25.57 | SpeedEvil | I've never actually used poll |
| 10:25.57 | mne | ok |
| 10:26.16 | mne | I'll just try it out then. |
| 10:29.22 | *** join/#edev devilsadvocate (~devilsadv@202.3.77.11) |
| 10:35.04 | *** join/#edev SpeedEvil (1000@tor/regular/SpeedEvil) |
| 10:36.11 | *** join/#edev SpeedEvil (1000@tor/regular/SpeedEvil) |
| 10:41.05 | mne | Hmm, is it also possible to set up the polarity (i.e. high or low active) for the CTS/RTS pins ? Usually RTS seems to be low active, thus if it outputs a low level it indicates that it is ready to receive new data. For this reason the CTS input has to be low active as well. However, CTS pin of the device I would like to talk to is high active. Thus it starts to send if CTS is high (and not low). Can I configure in software that the RTS output pin should be inver |
| 10:41.06 | mne | ted ? |
| 10:42.17 | *** join/#edev pirho (debian-tor@gateway/tor-sasl/pirho) |
| 11:29.27 | *** join/#edev krushia (~krushia@h69-131-86-88.cntcnh.dsl.dynamic.tds.net) |
| 11:33.47 | *** join/#edev sYskk (~a@unaffiliated/syskk) |
| 11:35.36 | *** join/#edev n17ikh (~n17ikh@host-69-59-126-212.nctv.com) |
| 11:44.24 | *** join/#edev pirho (debian-tor@gateway/tor-sasl/pirho) |
| 13:08.15 | *** join/#edev rasker (~Rehan@79-70-71-5.dynamic.dsl.as9105.com) |
| 13:09.01 | *** part/#edev rasker (~Rehan@79-70-71-5.dynamic.dsl.as9105.com) |
| 13:10.55 | *** join/#edev cbx (~cbx___@unaffiliated/cbx) |
| 13:22.50 | *** join/#edev GPSFan (~kenm@64.92.145.112) |
| 13:22.51 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:40.58 | *** join/#edev devilsadvocate (~devilsadv@202.3.77.11) |
| 13:56.36 | *** join/#edev jnd (~jenda@unaffiliated/jnd) |
| 14:06.14 | *** join/#edev n17ikh (~n17ikh@host-69-59-126-212.nctv.com) |
| 14:09.58 | *** join/#edev sjhill (~sjhill@home.bethel-hill.org) |
| 14:09.58 | *** mode/#edev [+o sjhill] by ChanServ |
| 14:39.21 | *** join/#edev djerome (~djerome@ip24-251-158-189.ph.ph.cox.net) |
| 14:46.35 | *** join/#edev SandGorgon (~OmNomNomO@122.162.124.26) |
| 14:52.48 | *** join/#edev kergoth (~kergoth@ip24-251-170-95.ph.ph.cox.net) |
| 14:55.27 | *** join/#edev kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 15:06.45 | *** join/#edev kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 15:14.19 | *** join/#edev kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 15:40.58 | *** join/#edev prpplague (~danders@nat/ti/x-ijrjqqskzismtsar) |
| 15:45.13 | *** join/#edev Crofton (~balister@pool-96-240-168-177.ronkva.east.verizon.net) |
| 15:58.39 | prpplague | kergoth: you around this morning? |
| 15:58.47 | prpplague | sjhill: hey bud, got the package! |
| 15:58.49 | kergoth | <PROTECTED> |
| 15:58.53 | prpplague | sjhill: thanks |
| 15:59.20 | prpplague | kergoth: hey just doing some OE tinkering and wanted a quick feedback |
| 15:59.46 | *** join/#edev bsdfox__ (~h36sa@c-98-238-213-113.hsd1.ca.comcast.net) |
| 16:00.09 | prpplague | kergoth: i was tinkering with a build where i can bitbake a package, lets say foo, and it would generate foo-clean-r37, and then the foo-r37 |
| 16:00.33 | kergoth | you'll need to elaborate |
| 16:00.34 | prpplague | kergoth: then when i am done hacking around on foo-37 , i can issue a bitbake command to do a diff and generate a patch |
| 16:00.43 | kergoth | ah.. hmm |
| 16:01.30 | prpplague | kergoth: i'm spending alot of time hacking around on packages and feels very clumsy having three or four terminals open moving between items |
| 16:01.36 | kergoth | the issue there is, if you use two different recipes, the recipes have different workdirs, buried deep in the tmpdir. one recipe can't get to another recipe's files without hardcoding paths, or putting the pristine source tree somewhere common. |
| 16:02.09 | kergoth | also seems like itd be easier to just make a recipe that points at a local source tree, use git or something, generate the patches as you go, rather than working in the unpacked tree in tmp |
| 16:02.11 | prpplague | kergoth: ahh |
| 16:02.23 | prpplague | kergoth: i follow |
| 16:02.23 | kergoth | or quilt, or whatever |
| 16:03.19 | prpplague | kergoth: ok thanks |
| 16:03.20 | kergoth | if you create a recipe and put it inside the source tree for your code, make it inherit srctree, it'll build in there and bypass the fetch/unpack/patch process. could always do that for now and convert to a regular recipe later |
| 16:03.39 | kergoth | alternatively, keep the recipe separate from the source tree, inherit srctree, and set S to the path to the tree |
| 16:04.04 | kergoth | its up to you, but this might be easier |
| 16:04.12 | *** join/#edev NullMoogleCable (~fake@cpe-67-253-160-190.rochester.res.rr.com) |
| 16:04.26 | prpplague | kergoth: most of the time i'm hacking on the source of an existing bb recipe |
| 16:04.28 | kergoth | if you do want to try to do it the way you proposed, you'd just have to deploy the unpacked, patched tree into a common area, like staging, and do your diff from there |
| 16:04.40 | prpplague | kergoth: ahh |
| 16:05.06 | kergoth | well, OE uses quilt for its patches, you could drop into a devshell, make your changes, create a new patch with quilt, whatever, drop out, then bitbake -c configure -f whatever to force it to rebuilt with your changes |
| 16:05.12 | prpplague | kergoth: well i'll probably just a do a few shell scripts for now |
| 16:05.15 | kergoth | if you really want to work in there |
| 16:06.02 | prpplague | kergoth: i'll let the idea fester for awhile until i come up with something better |
| 16:06.06 | prpplague | kergoth: thanks |
| 16:06.36 | kergoth | quilt already gives you the ability to generate the diffs from changes you make to the tree, seems unnecessary to reinvent the patch generation |
| 16:07.36 | prpplague | kergoth: i guess i might not be using quilth correctly then |
| 16:08.12 | kergoth | bitbake -c devshell foo; quilt new somepatch; quilt edit afile anotherfile; quilt refresh; -- copy the patch out of the source tree up to where the recipe is -- |
| 16:08.33 | kergoth | but you can pull off what you suggested, don't mean to imply that it's not possible, just that there are alternatives :) |
| 16:09.05 | prpplague | kergoth: yea that is kind of why i asked to make sure i wasn't reinventing the wheel, plus due to my lack of overall understanding of OE |
| 16:10.59 | prpplague | kergoth: ok i follow you on the quilt now |
| 16:11.43 | prpplague | kergoth: a little different procedure from what i was thinking |
| 16:18.40 | prpplague | kergoth: hehe, need setup devshell so that it sets the title of the terminal window to the recipe name |
| 16:29.54 | *** mode/#edev [+o prpplague] by ChanServ |
| 16:38.19 | prpplague | kergoth: doh, devshell not working so well for my kernel hacking |
| 16:38.27 | kergoth | how so? |
| 16:39.28 | prpplague | kergoth: looks like some ld flags aren't being set properly |
| 16:39.48 | prpplague | kergoth: a base bitake linux works, but if i devshell in and do a make it fails |
| 16:39.56 | kergoth | that's because bitbake isnt' running make. |
| 16:39.57 | kergoth | i |
| 16:40.05 | kergoth | it passes the arguments in EXTRA_OEMAKE |
| 16:40.18 | prpplague | kergoth: ahh |
| 16:40.28 | prpplague | kergoth: i follow |
| 16:40.57 | kergoth | which is why i said to run bitbake -c configure -f linux; bitbake linux to force it to rebuilt. the alternative is to bitbake -c compile linux once, then from within the devshell, re-run the shell script bitbake emitted to compile it. ../temp/run.do_compile.* |
| 16:41.09 | kergoth | i can see wanting to avoid buliding it with bitbake everyt ime :) |
| 16:41.58 | prpplague | kergoth: yea i've been doing bitbake --force -c compile linux |
| 17:00.31 | kergoth_ | prpplague: http://kergoth.pastey.net/134951 could be of use, you can copy the patched tree out of tmpdir and redirect the recipe to use it without touching the recipe itself |
| 17:00.45 | prpplague | looks |
| 17:01.12 | kergoth_ | (assumes you're running the commands in the build dir / TOPDIR) |
| 17:02.18 | prpplague | kergoth: ahh interesting, i'll give that a try |
| 17:03.02 | kergoth_ | the amend.inc thing lets you "amend" metadata changes to a recipe out of band, useful for local changes where you don't want to copy the recipe itself around |
| 17:06.35 | prpplague | ahh nice |
| 17:06.43 | prpplague | kergoth_: lots to learn |
| 17:07.01 | prpplague | kergoth_: having to do alot more OE for the tincantools products |
| 17:27.37 | sjhill | prpplague: you're very welcome |
| 18:11.17 | *** join/#edev alex4nder (~alexander@173-129-253-159.pools.spcsdns.net) |
| 18:11.32 | alex4nder | hey |
| 18:17.41 | *** join/#edev SandGorgon (~OmNomNomO@122.162.124.26) |
| 18:42.00 | *** join/#edev Omegamoon (~egoe@demolitionman.xs4all.nl) |
| 18:49.25 | *** join/#edev florian (~fuchs@Maemo/community/contributor/florian) |
| 18:54.42 | *** join/#edev ZeZu (~null@in-67-236-122-199.dhcp.embarqhsd.net) |
| 18:58.48 | *** join/#edev kergoth_ (~clarson@ip24-251-170-95.ph.ph.cox.net) |
| 19:03.37 | *** join/#edev alex4nder (~alexander@173-129-253-159.pools.spcsdns.net) |
| 19:19.01 | *** join/#edev roxfan (dunno@133.136-246-81.adsl-dyn.isp.belgacom.be) |
| 20:08.04 | *** join/#edev n17ikh (~n17ikh@host-69-59-126-212.nctv.com) |
| 20:34.46 | *** join/#edev zazenrasta (~zaz@adsl-074-244-082-076.sip.asm.bellsouth.net) |
| 20:35.10 | *** join/#edev alex4nder (~alexander@68-29-44-205.pools.spcsdns.net) |
| 21:00.38 | *** join/#edev roxfan (dunno@133.136-246-81.adsl-dyn.isp.belgacom.be) |
| 21:05.39 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 21:08.30 | *** join/#edev alex4nder (~alexander@68-29-44-205.pools.spcsdns.net) |
| 21:14.11 | *** join/#edev SpeedEvil (~user@tor/regular/SpeedEvil) |
| 21:15.32 | *** part/#edev Omegamoon (~egoe@demolitionman.xs4all.nl) |
| 21:39.36 | *** join/#edev penguinece (~penguinec@2610:48:100:8da:213:20ff:fe0a:7c8f) |
| 21:43.13 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 22:54.37 | *** join/#edev dieter|work (~dieter@dslb-088-066-206-011.pools.arcor-ip.net) |
| 22:57.49 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |
| 23:16.00 | *** join/#edev NullMoogleCable (~fake@cpe-67-253-160-190.rochester.res.rr.com) |
| 23:18.57 | *** join/#edev sYskk (~a@modemcable125.170-81-70.mc.videotron.ca) |
| 23:18.59 | *** join/#edev sYskk (~a@unaffiliated/syskk) |
| 23:19.36 | *** join/#edev n17ikh (~n17ikh@host-69-59-126-212.nctv.com) |
| 23:36.40 | *** join/#edev JoeLlama (~snork@unaffiliated/joellama) |