| 00:10.34 | ds2 | wonder if it is frowned upon to design blue LED drivers under the assumption that a 3.3V PS will light up a 3.218V Vf blue LED ;) |
| 00:15.47 | joe_bleau | With no current limiting? |
| 00:25.40 | roxfan | http://tinyurl.com/6nzafm nice price |
| 00:29.19 | joe_bleau | 400k (marketing) gates. For $40. Not bad at all. |
| 00:29.59 | joe_bleau | Lots of flash, too. |
| 00:32.01 | prpplague | decides to take the evening off and watch some movies |
| 00:53.22 | sunrunner20 | solder wik lol |
| 00:53.25 | sunrunner20 | *wick |
| 00:53.32 | sunrunner20 | makes nice patch wire sometimes |
| 01:01.19 | joe_bleau | What would be a good way to remove SOIC-8 devices from boards? I'd like to save the devices, and the PWBs are disposable. |
| 01:01.43 | g1powermac | prpplague's favorite method, heat gun |
| 01:02.17 | joe_bleau | Yeah, that's what I'm thinking too. I'm scared it might be a bit too brutal. |
| 01:02.38 | g1powermac | could do the toaster oven method too |
| 01:02.53 | joe_bleau | Sounds slow. |
| 01:03.09 | g1powermac | not really, once you heat it up, all the parts will fall off in one shot |
| 01:03.21 | joe_bleau | I've got hundreds of boards. |
| 01:03.39 | g1powermac | hmm, use your stove :-) |
| 01:04.11 | joe_bleau | Hmm. We could build jigs to hold the boards upside down. |
| 01:04.25 | joe_bleau | Wonder if the surface tension would hold the parts on, or if they'd drop off. |
| 01:04.33 | g1powermac | not sure |
| 01:04.48 | g1powermac | if so, a quick knock should make them drop |
| 01:13.25 | Madsy | There was this book which is concidered "the book" when it comes to explaining hardware components and layouts, but I can't remember the title. |
| 01:13.37 | joe_bleau | Art of Electronics? |
| 01:13.43 | Madsy | The more I learn about hardware design, the more I know that I don't know. |
| 01:13.46 | Madsy | Probably, thanks. |
| 01:15.12 | Madsy | Indeed, it was it. |
| 01:15.20 | Madsy | I remember the publishing year. |
| 01:16.00 | joe_bleau | 3rd edition, due any day now. (Or so they've been saying for roughly 8 years now!) |
| 01:16.23 | Madsy | What bothers me, is that there are a lot of books on hardware *design*, but not books which explains embedded components which makes a whole embedded system. |
| 01:17.26 | Madsy | I mean, I can't even grasp how the memory layout is done on my SoC. Different parts are mapped to different physical addresses, and there is also memory banking involved. |
| 01:18.29 | Madsy | The documentation doesn't even specify on which address the second cpu is RESET fron either. I assume the physical memory is split in half :) |
| 01:18.34 | Madsy | from* |
| 01:24.54 | roxfan | usually there are CS (chip select) signals that select which chip corresponds to which address |
| 01:25.32 | ds2 | yep, it is all about the CS's |
| 01:25.33 | roxfan | e.g. CS1 is connected to the chip that holds memory starting at 0x0 etc |
| 01:25.46 | ds2 | study an older "SoC" like the 80188's |
| 01:28.00 | *** join/#edev Ian_Daniher (n=it@69.61.230.246) |
| 01:28.38 | roxfan | and reset address is usually fixed for a given architecture... if you were reading a datasheet you might look for a more general doc |
| 01:33.22 | Madsy | roxfan: According to the ARMARM, it is always address zero. |
| 01:33.31 | Madsy | From that die's point of view. |
| 01:33.44 | roxfan | yes, arms start at 0 |
| 01:34.39 | roxfan | so you need to figure out where's 0 in your system... usually it's either the chip connected to the first CS or some kind of internal flash |
| 01:34.52 | Madsy | However, that's even more confusing. They can't have exception vectors in the same address space. |
| 01:35.23 | roxfan | hmm? |
| 01:37.21 | Madsy | This is how it works: The SoC copies 512 bytes from the NAND and into memory using DMA after a RESET. Then it proceeds. The second CPU is idle until the main CPU awakes it via the Dual CPU I/F |
| 01:37.57 | Madsy | As the MMU on the main CPU is disabled during reset, I assume it really starts fetching instructions at the physical address zero. |
| 01:38.05 | roxfan | sounds complicated |
| 01:38.11 | Madsy | I.e flat address mapping. |
| 01:38.43 | roxfan | does it copy those 512 bytes from 0 or to 0? |
| 01:38.50 | Madsy | But God knows what the second CPU conciders to be its reset vector address. |
| 01:39.20 | Madsy | To 0 |
| 01:39.27 | roxfan | hmm |
| 01:39.44 | Madsy | From flash memory to SD ram |
| 01:40.13 | ds2 | it doesn't have to start at zero; it depends on the implementor |
| 01:40.29 | roxfan | well, second cpu either has its own cs pins or uses shared memory |
| 01:40.31 | ds2 | and CS may not even be involved if you are booting off USB or NAND |
| 01:40.50 | roxfan | then the boot code probably has to figure out which cpu it's running from |
| 01:41.07 | roxfan | *in the latter case |
| 01:41.14 | *** join/#edev pea (n=pea@adsl-68-23-85-172.dsl.dytnoh.ameritech.net) |
| 01:41.22 | ds2 | yes and some implementation have an internal ROM that figures out a lot of that before transfering to your startup code |
| 01:41.58 | Madsy | roxfan: What does shared memory imply exactly? The Dual CPU I/F interface does enable the CPUs to communicate via 32 hardware registers. |
| 01:42.37 | Madsy | When they are written to, an interrupt is fired to the interrupt controller, which alerts the CPU which need to read the register. |
| 01:43.09 | roxfan | they might've been connected to the same memory chips at the same addresses |
| 01:43.25 | roxfan | but sounds like in your case they're pretty much separate |
| 01:43.38 | roxfan | or not? |
| 01:44.02 | Madsy | Here's the SoC documentation in question: http://www.mechcore.net/files/docs/MP2520F_Manual_Eng_V1.0.pdf |
| 01:44.14 | Madsy | Well, not exactly. The main CPU is an ARM920T which has an MMU |
| 01:44.25 | Madsy | The second is an ARM940T which has an MPU |
| 01:44.52 | ds2 | aren't arm9's before ARM had official MP support? |
| 01:45.58 | Madsy | The Dual CPU I/F interface transforms the upper eight bits of the ARM940T's physical address whenever it accesses 'external resources' |
| 01:46.27 | Madsy | Whether that means only peripherals or memory in general, I don't know. |
| 01:46.54 | Madsy | Sounds to me that they mean "everything else that is not on the die" |
| 01:46.55 | roxfan | hmm looks like they do use shared memory |
| 01:47.35 | Madsy | roxfan: Yes, the 32 hardware registers. |
| 01:47.46 | roxfan | no i mean besides that |
| 01:47.58 | roxfan | e.g both can access the sdram |
| 01:48.04 | Madsy | Aha. |
| 01:48.33 | Madsy | But in that case, how can they have a different point of view, on what "address zero" is? |
| 01:49.17 | Madsy | Is this because of the memory bank switching mentioned on page 79? |
| 01:51.47 | roxfan | hmm interesting |
| 01:52.27 | Madsy | I hope you see my issue :-) |
| 01:53.15 | Madsy | 1.) I don't understand the bank switching on page 79, and I don't know the ARM940T RESET vector address |
| 01:55.42 | roxfan | well i guess after reset you're supposed to set the 940BANK value to e.g. 0xF |
| 01:56.27 | roxfan | then when you reset the 940 it will try to fetch the address 0 but because of banking it will actually go to 0x0F000000 |
| 01:56.58 | roxfan | sort of a poor man's mmu i guess |
| 01:58.31 | Madsy | Aha, that makes sense. But I still don't quite understand the formula. ARMCPU Address[31:24] seems ambiguous to me. Which CPU do they refer to? |
| 02:00.32 | roxfan | the 940 cpu i guess... and i think that's forumula for the addend, not the final address |
| 02:00.51 | Madsy | Indeed. You can see it get ANDed at the end. |
| 02:01.03 | Madsy | So the formula is only for the high eight bits |
| 02:01.23 | roxfan | i.e. physaddr = cpu_addr + 940BANK<<24 |
| 02:01.48 | Madsy | You mean | instead of + I assume? |
| 02:01.54 | Madsy | If we think in C |
| 02:02.01 | roxfan | no, plus |
| 02:02.23 | Madsy | Oh. |
| 02:02.32 | Madsy | Better look out for those overflows then |
| 02:03.01 | roxfan | e.g. for 940BANK=1 you'll get 0xC1000000 -> 0xC2000000 |
| 02:03.05 | roxfan | or something |
| 02:04.04 | Madsy | So in the event that the 940T wants to access hardware registers in flat memory space, all I need is to subtract the 940BANK value from the "real" hardware register address? |
| 02:04.21 | roxfan | looks like it |
| 02:04.36 | roxfan | don't you have any sample code? |
| 02:04.53 | Madsy | Thanks for your time. You really saved my day :) |
| 02:05.03 | Madsy | Or night. It's 4 AM here |
| 02:05.57 | roxfan | here too :) |
| 02:06.13 | Madsy | I'm going to skim through the Linux and bootstrap source tomorrow. The svn had troubles lately. |
| 02:35.52 | joe_bleau | Just read the logs: good work on the didj hacking! |
| 02:37.05 | *** join/#edev Ian_Daniher (n=it@69.61.230.246) |
| 02:37.16 | *** join/#edev Ian_Daniher_ (n=it@69.61.230.246) |
| 02:49.02 | *** join/#edev dijenerate (n=dijenera@72.22.130.200) |
| 03:24.26 | *** join/#edev chouimat (n=dieu@r2351064.cidc.net) |
| 04:39.23 | *** join/#edev DrZimmerman (n=theo@77-56-241-196.dclient.hispeed.ch) |
| 04:44.59 | *** join/#edev mbuf (n=shakthim@61.16.248.242) |
| 04:56.16 | *** join/#edev harpal (n=harpal@122.169.108.195) |
| 05:20.37 | *** join/#edev chouimat (n=dieu@r2351064.cidc.net) |
| 05:40.10 | *** join/#edev redblue (i=star@ppp109.108-253-207.mtl.mt.videotron.ca) |
| 06:01.58 | *** join/#edev drath (i=vmaster@p5B07D239.dip.t-dialin.net) |
| 06:48.32 | *** join/#edev magnetron (n=magnetro@unaffiliated/magnetron) |
| 07:08.57 | *** join/#edev [AD]Turbo (n=turbo@host141-131-dynamic.57-82-r.retail.telecomitalia.it) |
| 07:09.48 | *** join/#edev hw__ (n=hw@p578b3905.dip0.t-ipconnect.de) |
| 07:14.10 | [AD]Turbo | hola |
| 07:18.50 | *** join/#edev chouimat (n=dieu@r2351064.cidc.net) |
| 08:00.44 | *** join/#edev lyakh (n=lyakh@p57BD2D77.dip0.t-ipconnect.de) |
| 08:58.02 | *** join/#edev Ei5GTB_ (n=Paul@212.2.180.40) |
| 09:02.43 | *** join/#edev wmat (n=btraynor@gromit.mixdown.ca) [NETSPLIT VICTIM] |
| 09:03.30 | *** join/#edev RobotGuy-AFK (n=robotguy@dsl093-038-072.pdx1.dsl.speakeasy.net) [NETSPLIT VICTIM] |
| 09:14.18 | *** join/#edev ChanServ (ChanServ@services.) |
| 09:14.18 | *** join/#edev dijenerate (n=dijenera@72.22.130.200) |
| 09:14.18 | *** join/#edev Ian_Daniher_ (n=it@69.61.230.246) [NETSPLIT VICTIM] |
| 09:14.18 | *** join/#edev roxfan (n=dunno@236.4-200-80.adsl-dyn.isp.belgacom.be) [NETSPLIT VICTIM] |
| 09:14.18 | *** join/#edev Chocobo (n=swinchen@strongbad.eece.maine.edu) |
| 09:14.18 | *** join/#edev agaffney (n=agaffney@gentoo/developer/pdpc.active.agaffney) [NETSPLIT VICTIM] |
| 09:14.18 | *** join/#edev key2 (n=key2@gob75-7-82-247-113-230.fbx.proxad.net) |
| 09:14.18 | *** join/#edev _trine (n=trine@38.100.90.3) |
| 09:14.18 | *** join/#edev dfarnsworth (n=dfarnswo@65.200.49.156) [NETSPLIT VICTIM] |
| 09:14.18 | *** mode/#edev [+o ChanServ] by irc.freenode.net |
| 09:16.51 | *** join/#edev EI5GTB (n=Paul@212.2.180.40) |
| 09:16.51 | *** join/#edev methril|away (n=Methril@213.27.233.98) |
| 09:18.05 | *** join/#edev samuelr (n=samuelr@dsl093-061-094.pit1.dsl.speakeasy.net) |
| 10:36.32 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 10:47.02 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 10:59.08 | *** join/#edev Redhatter (n=vk4fsjl@2001:388:f000:0:0:0:0:279) |
| 12:09.39 | *** join/#edev magnetron (n=magnetro@unaffiliated/magnetron) |
| 12:37.24 | *** join/#edev sunrunner20 (n=jamesdoe@pool-70-104-23-70.dllstx.fios.verizon.net) |
| 12:56.28 | *** join/#edev GPSFan (n=kenm@12.10.255.246) |
| 12:56.28 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:04.59 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 13:06.32 | *** join/#edev MothaWork (n=monmotha@mail.forwardengineering.com) |
| 13:52.58 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 14:07.16 | *** join/#edev DrZimmerman (n=theo@77-56-241-196.dclient.hispeed.ch) |
| 14:07.38 | prpplague | dying to find out whats going on with leapfrog GPL compliance |
| 14:13.18 | prpplague | http://www.hackaday.com/2008/08/31/apollo-guidance-computer-clone/ |
| 14:13.26 | prpplague | i'd love to do one of those with the hammer |
| 14:13.43 | prpplague | be funny if i sent it william anders |
| 14:27.44 | MothaWork | prpplague: people are already on them for GPL compliance? |
| 14:34.24 | adyer | prpplague: BTW, I'm pretty sure NXP didn't buy ST (looking in scrollback). The ARM9 parts NXP just picked up were from Sharp. |
| 14:51.47 | MothaWork | prpplague: there appears to be some sort of clock infrastructure within the kernel. You know anything about it? |
| 14:57.23 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 14:57.23 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 15:03.54 | *** join/#edev Ian_Daniher (n=it@204.10.219.119) |
| 15:17.01 | solar | morn |
| 15:38.45 | Ian_Daniher | g'morn |
| 16:21.13 | *** join/#edev Ei5GTB (n=Paul@213-202-146-134.bas502.dsl.esat.net) |
| 16:38.05 | solar | Anybody know how many beagleboards digikey had that got sold out in a matter of days? Was it 400 units? |
| 16:49.18 | *** join/#edev steliosk (n=Stelios@79.107.85.140) |
| 16:58.35 | *** join/#edev purl (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
| 16:58.35 | *** topic/#edev is a channel for the discussion of hacking small consumer electronic devices, mostly ARM based; Hammer Development boards as well as Nail Boards are now available at http://www.tincantools.com/ |
| 17:03.22 | prpplague | solar: 500 units |
| 17:03.38 | prpplague | sorry folks just got back from meeting |
| 17:04.56 | prpplague | adyer: Dear customer, |
| 17:04.56 | prpplague | As from August 2nd 2008, the wireless operations of STMicroelectronics have moved to a |
| 17:04.56 | prpplague | new company, ST-NXP Wireless. |
| 17:06.18 | prpplague | MothaWork: i've provided the information to SFLC |
| 17:06.36 | prpplague | MothaWork: i've been disappointed in how SFLC has responded to me |
| 17:07.07 | prpplague | MonMotha: they basically just want you to tell them who is violating copyrights for busybox and then leave them alone |
| 17:07.14 | *** join/#edev Redhatter (n=vk4fsjl@2001:388:f000:0:0:0:0:279) |
| 17:12.57 | MothaWork | prpplague: odd that they care only about busybox |
| 17:13.08 | MothaWork | I guess it is certainly the most prolific, but I'd expect they'd be interested in anything |
| 17:14.09 | solar | for whatever reason it's eaiser to them to go after ppl about busybox vs the kernel alone. |
| 17:14.54 | roxfan | possibly because busybox is copyrighted to a small number of people (i think) |
| 17:15.10 | roxfan | so maybe it's easier to get them to act |
| 17:16.03 | prpplague | MothaWork: yea, andersee and landley have given power of attorney to SFLC for busybox |
| 17:17.47 | MothaWork | prpplague: ah, makes things much easier for them, then |
| 17:18.00 | MothaWork | are the receptive to copyright holders of other GPL things approaching them with violations? |
| 17:18.26 | MothaWork | also, do they go after LGPL violations? |
| 17:20.30 | prpplague | MothaWork: yea, from what i gather you have to be setup with their law firm to start a "client-attorney" relationship |
| 17:21.09 | prpplague | MothaWork: basically if you aren't party to the suit/demands, which i am not, they don't really update you until the process is done |
| 17:29.35 | chouimat|work | wow the beagleboard I ordered yesterday at 16:45EST is here ... and it's smalll |
| 17:30.24 | ds2 | small??????? |
| 17:30.39 | chouimat|work | ds2: the board size |
| 17:30.54 | ds2 | right, again I ask, small??!?!?!?!?! |
| 17:31.07 | ds2 | that thing is at least 4x as big as a gumstix or a hammer |
| 17:31.23 | chouimat|work | ds2: I was expecting it to be bigger |
| 17:31.30 | ds2 | =) |
| 17:31.41 | ds2 | you should've gotten a EVM then... that'd be bigger |
| 17:32.45 | chouimat|work | now I need a hdmi to dvi cable |
| 17:32.59 | ds2 | amazon or DX if you are willing o wait |
| 17:33.01 | ds2 | to |
| 17:33.21 | chouimat|work | ds2: I will simply go get one a radioscrap |
| 17:33.40 | ds2 | is ratshack reasonably priced for those things? |
| 17:33.49 | chouimat|work | 20CAD |
| 17:34.13 | ds2 | that's 2x of the amazon price and about 4-5x DX price |
| 17:34.21 | ds2 | <-- cheap with cables |
| 17:35.33 | chouimat|work | ds2: I'm not willing to wait and I should ordered on when I ordered the board |
| 17:35.41 | ds2 | hehehehehe |
| 17:35.53 | ds2 | while you are at it, be sure you have a serial adapter |
| 17:37.25 | chouimat|work | :) |
| 17:37.47 | ds2 | the lack of serial adapter seems to be somewhat of a common problem |
| 17:37.51 | ds2 | hence the reason I mentioned it |
| 17:38.00 | ds2 | most stock PC ones will work |
| 17:38.14 | chouimat|work | ds2: cool I have a few decommissioned pc |
| 17:38.50 | ds2 | the DVI-D cable, IMO is secondary unless your goal is to do graphics =) |
| 17:39.37 | ds2 | you'll probally also want a 5V regulated power cube to 2.1mm plug cable or a crummy PC and a USB A to 2.1mm plug |
| 17:39.49 | *** join/#edev Ian_Daniher (n=it@204.10.219.119) |
| 17:40.32 | ds2 | crummy PCs tend to not enforce the 100mA before enumeration thing and directly provide 500mA |
| 17:42.29 | chouimat|work | ds2: I have a few universal powersupply :) |
| 17:43.26 | *** join/#edev methril|laptop (n=methril@204.73.220.87.dynamic.jazztel.es) |
| 17:48.18 | kergoth`work | prpplague: any idea what it is about oe that makes things so confusing for a lot of people at the beginning? is it just too many bits and pieces and connections to keep track of? |
| 17:48.27 | *** join/#edev landley (n=landley@m0d0e36d0.tmodns.net) |
| 17:48.27 | *** mode/#edev [+o landley] by ChanServ |
| 17:50.06 | landley | Yay internet via cell phone. |
| 17:51.23 | MothaWork | kergoth: I think that's a good chunk of it. The fact that it's rather easy to come up with a configuration that just won't build out of the box also frustrates things. |
| 17:53.16 | kergoth`work | hmm, okay. just mulling over a design for a new tool, and thinking about the usability issues. I think the .bb/.inc/.conf format and their differences are confusing too. OVERRIDES for conditionals is a mess, namespace wise, also |
| 17:53.50 | kergoth`work | like you can't use foo(){} format in a .conf, but you can a .inc and .bb, and a .conf can include a .inc.. how silly is that? |
| 17:53.53 | MothaWork | kergoth`work: I didn't actually mess with OE here, so I'm just going based on rumblings from those who did |
| 17:53.56 | kergoth`work | forces you to move things around for no good reason |
| 17:54.11 | kergoth`work | cool, thanks for the info, its a start :) |
| 17:54.12 | MothaWork | I attempted to make buildroot work and gave up |
| 17:54.25 | kergoth`work | has a hard time approaching things from the end user perspective |
| 17:54.41 | MothaWork | I think a certain amount of what you speak of is unavoidable |
| 17:54.56 | MothaWork | diving into the Linux kernel is hard for similar reasons (unfamiliarity with the APIs and conventions), but there's no real way around that |
| 17:55.06 | solar | end users want to type.. cross-build $foo w/o a whole lot of doing anything else |
| 17:55.21 | CosmicPenguin | and they want it to magically work for their system |
| 17:55.27 | CosmicPenguin | which is a silly expectation in the embedded world |
| 17:55.32 | MothaWork | At the same time, the Linux kernel tends to at least compile and work in most normal configurations, so if things break after modifying it, you can be reasonably sure that it was probably your fault. That doesn't seem so with OE. |
| 17:55.39 | CosmicPenguin | one of the things an new build system has to do is set expectations |
| 17:56.01 | CosmicPenguin | if you just want to run linux on your foo box, then debian is over that away |
| 17:57.24 | kergoth`work | MothaWork: i'm thinking that could be helped, at least in part, by requiring that a recipe be maintained by a specific person. anything unmaintained gets flagged as such and excluded from builds by default. in addition, having a good continuous build / job scheduler / tinderbox type setup thats easy to use will help too |
| 17:57.38 | kergoth`work | plus the ability to run more than just build steps in the jobs, unit tests and qa checks |
| 17:57.53 | kergoth`work | makes a list of usability issues to resolve |
| 17:58.30 | kergoth`work | heh, don't mean to spam the channel or anything, feel free to ignore me, talking helps me sort it out in my head :P |
| 18:00.11 | CosmicPenguin | we're not relaly talking about anythign else |
| 18:00.14 | kergoth`work | i think i tried to make bitbake -too- flexible. everything in the metadata makes things too haphazard. typos in variable names could go completely unnoticed |
| 18:00.59 | adyer | prpplague: wireless was a part of ST, but what you said was "st was sold to nxp just recently" which isn't true |
| 18:07.16 | ds2 | wonder if NXP is more likely to release info then ST was |
| 18:09.35 | *** join/#edev landley_ (n=landley@m1a0e36d0.tmodns.net) |
| 18:10.14 | MothaWork | kergoth`work: that's basically what Debian does |
| 18:10.28 | MothaWork | kergoth`work: and it does seem to work for them, albeit sometimes forcing a slowish release schedule |
| 18:11.51 | landley_ | Sorry for getting so enthused about chromium before noticing they were implementing it in C++. |
| 18:12.07 | landley_ | Not all all surprised my friend Stu says the XP demo took 300 megs of ram to boot. |
| 18:12.09 | landley_ | They wrote it in C++. |
| 18:12.22 | landley_ | Why would anyone write a _new_ browser in C++? Konqueror/Safari already exists... |
| 18:12.26 | landley_ | Oh well. |
| 18:12.31 | landley_ | Thought it was in C. :( |
| 18:21.03 | MothaWork | C++ isn't necessarily bad |
| 18:21.32 | MothaWork | Like C, there are several ways to abuse it. Unlike C, when you abuse C++, it's REALLY REALLY bad. When you abuse C, it's only bad :) |
| 18:22.14 | landley_ | Eric and I are writing a paper later this month, "Why C++ isn't my favorite language". |
| 18:22.23 | ds2 | hahahahahaahahahah |
| 18:22.23 | landley_ | I could go on for quite some time about what's wrong with C++. |
| 18:22.57 | landley_ | The fundamental problem is that C++ lives in a no-man's land between two local peaks. |
| 18:23.01 | landley_ | C is a portable assembly language. |
| 18:23.15 | landley_ | It's simple, and it maps directly to what the computer's actually doing. |
| 18:23.37 | ds2 | tell that to the folks running on stackless machines ;) |
| 18:23.39 | landley_ | (Sure optimizers give the code a big stir these days, but on a conceptual level there's a 1:1 relationship between actions you tell the machine to do, and what the hardware actually does.) |
| 18:24.02 | landley_ | Which variant of stackless machines? |
| 18:24.19 | landley_ | (That's like saying "tell that to the folks running the machines with no linked lists.") |
| 18:24.32 | landley_ | Trivial to implement in software no matter what the hardware's doing. I've written stacks _in_c_. |
| 18:25.18 | landley_ | The other local peak is the actual 4th gen languages like Python and such. |
| 18:25.25 | landley_ | Using references instead of pointers. |
| 18:25.43 | landley_ | References are always guaranteed to point to either a valid object or to NULL. |
| 18:25.55 | ds2 | like the smaller PICs |
| 18:26.07 | ds2 | no room for a stack when you have like 128bytes of RAM ;) |
| 18:26.09 | landley_ | Which means you can do dynamic typing without worrying about segfaults due to following a wild pointer or a dangling pointer to an already freed object. |
| 18:26.18 | landley_ | You can garbage collect sanely. |
| 18:26.41 | landley_ | ds2: you're not using _any_ programming language in 128 bytes of ram, are you? |
| 18:26.44 | MothaWork | ds2: people use C on the RAMless tiny AVRs |
| 18:26.50 | landley_ | The whole "portable" part goes out the window. |
| 18:27.02 | MothaWork | 32 8-bit registers |
| 18:27.05 | MothaWork | landley_: people do it |
| 18:27.16 | MothaWork | if you're careful, it's still nicer than using assembly in terms of maintainability |
| 18:27.16 | g1powermac | loves C |
| 18:27.34 | MothaWork | obviously you have limited call depth and recursion is pretty much impossible, but you can do it |
| 18:27.34 | landley_ | I'm quite aware what people do: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html |
| 18:27.44 | g1powermac | though really I do long for the few improvements C++ brought to the language minus the object oriented stuff |
| 18:28.13 | g1powermac | passing by reference is just so much nicer than dealing with pointers directly |
| 18:28.21 | landley_ | ds2: so the point you're making is that stackless machines are better programmed in C++? |
| 18:28.34 | MothaWork | landley_: heh, that's not abuse of a programming language. That's abuse of a binary format :) |
| 18:28.50 | MothaWork | g1powermac: some of those things are in C99 and/or the GNU extensions to C |
| 18:29.03 | ds2 | no, I am pointing out the direct mapping quality of C doesn't necessarily apply |
| 18:29.05 | MothaWork | anonymous pointers/structs and variadic macros are some of my favorites |
| 18:29.06 | landley_ | MothaWork: would you like me to show you abuse of programming languages without even bringing the obfuscated C code contest into it? |
| 18:29.06 | g1powermac | MothaWork, yea, some |
| 18:29.19 | MothaWork | landley_: oh, I've seen some |
| 18:29.35 | landley_ | ds2: if your example is going to be constructed out of legos, you can come up with a counter example to just about any programming argument. |
| 18:29.38 | MothaWork | Atmel comes up with some stuff that has made be literally say "wtf!?" |
| 18:29.40 | landley_ | "This one doesn't use binary!" |
| 18:29.42 | ds2 | making every single parameter a void * is a good thing ;) |
| 18:29.49 | ds2 | it satisfies the GPL }:-) |
| 18:29.54 | landley_ | I'm not having this conversation. |
| 18:29.58 | *** part/#edev landley_ (n=landley@m1a0e36d0.tmodns.net) |
| 18:30.26 | g1powermac | ehh |
| 18:30.27 | roxfan | o.o |
| 18:30.43 | MothaWork | that was unexpected |
| 18:32.34 | ds2 | hmmm wonder which one pushed it too far |
| 18:48.40 | *** join/#edev Ian_Daniher (n=it@204.10.219.119) |
| 19:05.24 | chouimat|work | ds2: my goal with the beagle board is to build a nice little upnp media player (for now) |
| 19:05.36 | prpplague | kergoth`work: hey bud, i'd love to talk about the OE stuff, but i have two boss's in the office at the momment |
| 19:05.46 | kergoth`work | hehe, lucky you |
| 19:06.35 | chouimat|work | is back from a 1h call with marvell engineers |
| 19:07.37 | *** part/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 19:11.52 | kergoth`work | hm, would people rather see one bigger flexible dsl or two seperate ones with similar formats for two different purposes, from a usability standpoint? i'm thinking the latter, even though its two formats to learn, therei snt much to learn, and they stay distinct |
| 19:43.25 | prpplague | ~seen sjhill |
| 19:43.26 | purl | sjhill <n=sjhill@real.realitydiluted.com> was last seen on IRC in channel #edev, 9d 1h 29m 1s ago, saying: 'greetings bit slingers'. |
| 20:07.36 | g1powermac | sadly remembers that clearly |
| 20:08.45 | *** join/#edev frikker (n=blaine@107.135.68.216.DED-DSL.fuse.net) |
| 20:22.54 | kergoth`work | CosmicPenguin: ping |
| 20:23.47 | *** join/#edev sjhill (n=sjhill@real.realitydiluted.com) |
| 20:23.47 | *** mode/#edev [+o sjhill] by ChanServ |
| 20:24.43 | prpplague | kergoth`work: maybe monday i can have some time to discuss you of the stuff regarding OE from my perspective |
| 20:25.02 | kergoth`work | cool |
| 20:25.36 | CosmicPenguin | kergoth`work: pong |
| 20:25.48 | *** join/#edev landley_ (n=landley@m3e0e36d0.tmodns.net) |
| 20:26.29 | kergoth`work | i was thinking about having file attributes/tags ala Conary, and killing staging/install from the package recipe.. then it only builds, and produces build artifacts, then the system deploys the artifacts based on their tags and analysis .. man pages to mandir, etc. so the recipe would just define, if it needed to override anything, the attributes of the build artifacts so it can deploy intelligently later on |
| 20:29.10 | CosmicPenguin | hmm |
| 20:29.35 | kergoth`work | http://gist.github.com/9019 or so, perhaps |
| 20:29.55 | CosmicPenguin | needs to learn |
| 20:30.37 | kergoth`work | note in that example the PACKAGES/FILES are elsewhere, distro policies, this is more from the app developer perspective |
| 20:31.23 | CosmicPenguin | shouldn't you be more trusting of the individual package isntall? |
| 20:32.42 | kergoth`work | if you use their install, then you have to convert from whatever their idea of distro layout is to whatever you want, instead of going directly to the source, though |
| 20:33.07 | CosmicPenguin | there must be a happy medium somewhere |
| 20:33.39 | CosmicPenguin | I'm thinking of crap like gtk with its hundreds of header files and such |
| 20:34.58 | kergoth`work | hmm, yeah, thats a good point |
| 20:35.25 | kergoth`work | i figured it could automate a lot, elf artifacts that are +x -> bindirs, etc, but itd be hard to retain directory structure amongst its own files |
| 20:35.51 | kergoth`work | unless you allowed wildcards in the attributes definitions, that could work |
| 20:36.07 | kergoth`work | include/gtk-2.0 -> pkgincludedir |
| 20:36.10 | kergoth`work | shrugs |
| 20:36.12 | kergoth`work | i dunno |
| 20:36.40 | CosmicPenguin | perhaps you stick with the install stage but then use your idea from there |
| 20:37.14 | kergoth`work | was toying with the idea of tracking inter-file dependency within a package and across packages, mostly automated, to handle dependencies, because there's no telling how the distro will package you, and with that info elsewhere, you need way to exert that dependency regardless of package naming, that lead me to thinking about this way |
| 20:37.58 | kergoth`work | yeah, thats true.. hmm |
| 20:38.02 | CosmicPenguin | I think reaching into the src package will require too much knowledge on the part of the maintainers |
| 20:38.13 | CosmicPenguin | just knowing that you have to go to .libs/<blah> is pretty abstract |
| 20:38.40 | kergoth`work | one could argue that the maintainer -should- know the packages they maintain that well, though. |
| 20:38.42 | CosmicPenguin | if you assume that the install stage will have some semblence of sanity to it (a bad assumption?) |
| 20:38.56 | CosmicPenguin | then you can take the resulting tree and smack it about |
| 20:38.58 | kergoth`work | i was thinking this recipe would reside in the source tree |
| 20:39.17 | CosmicPenguin | even use say a 'debian' class that can move the man pages and documents and whatnot to their right place |
| 20:39.45 | CosmicPenguin | if the recipe lived in the source tree then perhaps thing would change |
| 20:39.54 | CosmicPenguin | could you autogenerate the recipe from the automake file? |
| 20:39.56 | CosmicPenguin | runs |
| 20:40.09 | kergoth`work | i thought about that, actually.. i was thinking about the rebuild situation |
| 20:40.13 | kergoth`work | we dont want to rebuild things unnecessarily |
| 20:40.25 | kergoth`work | but that kind of means we want to know intimate details about the build to know what to monitor for changes |
| 20:40.41 | kergoth`work | which starts to blur the boundaries between tools, and i dunno how much to go into for that |
| 20:41.48 | CosmicPenguin | agreed |
| 20:41.53 | kergoth`work | could get really crazy and analyze the makefile dependencies to determine what sources feed into an artifact |
| 20:41.56 | kergoth`work | hehe |
| 20:42.16 | CosmicPenguin | One nice thing about OE is that for your average autotoolized program, shit just works |
| 20:42.19 | CosmicPenguin | 3 lines and you are there |
| 20:42.22 | kergoth`work | indeed |
| 20:42.32 | CosmicPenguin | but you can also make it work for Bob's parser with the stupid install and custom perl script |
| 20:42.36 | kergoth`work | i'm wanting to make the classes smarter, and probably define them outside of our usual metadata. maybe write them as plugins to the system instead |
| 20:43.14 | CosmicPenguin | You are not selling yourself short if you bias your system toward the responsible packages |
| 20:43.18 | kergoth`work | bitbake is just -too- flexible, -everything- being metadata makes things too haphazard |
| 20:43.21 | CosmicPenguin | assuming you left room for the stupid packages |
| 20:43.23 | kergoth`work | and confusing |
| 20:43.39 | kergoth`work | its like people taht write an app and put everything, even business logic, into an sql database |
| 20:43.46 | kergoth`work | i usually feel like choking those people |
| 20:43.47 | CosmicPenguin | and what you have in the gist post is great for a stupid package |
| 20:46.12 | kergoth`work | i like the idea of making the configuration system a seperate beast, with explicitly defined configuration parameters so user interfaces can present them properly. i was thinking about automatically analyzing the autoconf setup to snatch the --with- and --enable- as config parameters for the UI, and such |
| 20:56.10 | prpplague | well i got a "thanks we are looking into it" email from sflc |
| 21:02.30 | MothaWork | bah, stupid ECC |
| 21:02.39 | MothaWork | I seem unable to build a kernel that works on my board now |
| 21:02.48 | MothaWork | nonstop ECC errors from MTD |
| 21:04.10 | prpplague | btdt |
| 21:21.31 | kergoth`work | CosmicPenguin: maybe keep install/stage removed, let the package control file attributes if they choose to, but also have the classes like autotools be able to either make use of their package's install rules to set up the attributes, or analyze the buildsystem to determine them |
| 21:21.57 | CosmicPenguin | that might be a good alternative |
| 21:22.05 | *** join/#edev DrZimmerman (n=theo@77-56-241-196.dclient.hispeed.ch) |
| 21:22.55 | kergoth`work | trying to meet the needs of crazy cm folks and all the other use cases while retaining usability is a challenge :P |
| 21:24.04 | prpplague | kergoth`work: indeed |
| 21:24.20 | kergoth`work | particularly when i'm too lazy to actually document the uses cases or anything :D |
| 21:25.02 | prpplague | kergoth`work: it is almost like it needs to be three types of build systems, but all with the same core which can be built on |
| 21:25.22 | prpplague | kergoth`work: board developer-> gui developer -> cm |
| 21:27.07 | kergoth`work | i'm thinking 4 main components, user/distro/etc configuration management, able to pull in configuration shards/snippets from a variety of sources, save your setups, etc. then metadata management, an apt-like setup for managing and obtaining source/metadata from an upstream repository of such things. then the individual package build tool to run in the source tree to produce build artifacts, building based on the configuration bits from that system.. |
| 21:27.07 | kergoth`work | <PROTECTED> |
| 21:27.49 | kergoth`work | tools for everything, even saving/loading configurations, i dont want everybody having to edit textfiles if they dont want to |
| 21:28.07 | kergoth`work | no releases with packages before uis are created, or they'll never be created :P |
| 21:29.15 | prpplague | kergoth`work: so for a board developer that normally uses something like buildroot, how do you envision them using this new system? |
| 21:31.10 | kergoth`work | they'd set up their config (target, etc). then they'd configure the local job execution system to build this set of packages (probably stored somewhere so they can be shared).. maybe thats just a kernel, or kernel & busybox. for the kernel, they could be actively developing in a kernel tree and have the local job build out of there itself, or just deploy based on the local builsd you do... i want it to be flexible enough to pull out of any scm, or l |
| 21:31.10 | kergoth`work | ocal |
| 21:32.04 | kergoth`work | can set up builds out of scm for the nightlies or weeklieso r for continuous integration if you choose to |
| 21:32.32 | kergoth`work | since distro policy will be completely out of the package metadata, you'll be able to easily say i want this file and that file and this other file in my tree, and thats it |
| 21:32.47 | kergoth`work | well, thast the goal anyhow |
| 21:33.21 | kergoth`work | i always want it to be easier to inject custom rules into the deployment phases, to add your custom config files and such.. not sure how to manage that yet though |
| 21:33.25 | kergoth`work | s/always/also/ |
| 21:33.33 | kergoth`work | purl: quiet, you |
| 21:33.38 | *** join/#edev chouimat (n=dieu@r2351064.cidc.net) |
| 21:34.06 | kergoth`work | hehe, "* napo-o out of the ten "way to reduce a shark attack" listed in the paper today.. It did not mention to stay out of the water" |
| 21:34.28 | prpplague | hehe |
| 21:35.04 | prpplague | kergoth`work: so for developer type systems, we could tell it to build the toolchain kernel and busybox in short order? |
| 21:36.07 | kergoth`work | thats the intent, yeah. and be able to do all sorts of deployment tasks if you want them, scp to the board, make packages, whatever |
| 21:36.44 | kergoth`work | what i havent quite worked out is the best way to do a quick local build of just this one package from its source tree -and the delpoyment steps-. i'm thinking any job the jobserver can run should be able to be run manually, locally, at the commandline |
| 21:37.21 | kergoth`work | scratches head |
| 21:38.39 | kergoth`work | has a lot of details to work out |
| 21:39.23 | MothaWork | prpplague: I have an old, working kernel image. Building what should be the same codebase using the same .config, I end up with something that boots but gives nonstop MTD ECC errors |
| 21:40.16 | prpplague | MonMotha: interesting |
| 21:41.35 | kergoth`work | prpplague: thing is, the job server alone is a huge project. we're talking something like cruisecontrol, but with a lot more dependency stuff and improved flexibility.. and thats not going into the rest of the system :P |
| 21:41.54 | kergoth`work | reads a bit of his c# book |
| 21:42.07 | prpplague | kergoth`work: yea, did think it would be easy |
| 21:42.42 | kergoth`work | maybe i'm trying to do too much, meet too many needs, but there's a lot of overlap between projects to do this sort of thing, no point failing to take advantage of that |
| 21:42.59 | MothaWork | prpplague: of course, I'm not 100% sure it really IS the same codebase or config. It's just what's in CVS. |
| 21:43.25 | prpplague | kergoth`work: indeed |
| 21:44.14 | prpplague | kergoth`work: like i said, it seems like it should really be three different projects, but where the metadata from each could be exchanged |
| 21:46.49 | prpplague | heads home for the day |
| 21:50.07 | *** join/#edev landley (n=landley@cpe-70-116-30-223.austin.res.rr.com) |
| 21:50.07 | *** mode/#edev [+o landley] by ChanServ |
| 22:07.03 | ds2 | hmmm sounds like the dogs are all in the house now |
| 22:10.30 | *** join/#edev L_Deluxe (n=lou@c-68-53-134-58.hsd1.tn.comcast.net) |
| 22:31.38 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 22:31.38 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 22:58.54 | *** join/#edev joe_bleau (n=joe_blea@adsl-69-152-217-93.dsl.fyvlar.swbell.net) |
| 23:11.13 | g1powermac | have you guys seen the new MS commercial with Jerry Seinfeld in it? |
| 23:11.19 | g1powermac | its pretty bad |
| 23:15.21 | landley | Yeah, I saw it. |
| 23:15.43 | landley | I knew gates was all about nothing, but I didn't know he wanted to be quite that explicit about it. |
| 23:15.59 | g1powermac | heh |
| 23:16.07 | g1powermac | I did up a whole critique on it: http://g1powermac.com/?p=13 |
| 23:16.33 | g1powermac | just because I'm also a tv commercial producer |
| 23:17.36 | g1powermac | albeit, a part time one :-) |
| 23:21.28 | joe_bleau | Well, after all the hype I want to see it. |
| 23:21.50 | g1powermac | I got a youtube video on my blog post |
| 23:22.04 | joe_bleau | Had JS turned off, didn't see it. I did read your comments. |
| 23:48.52 | *** join/#edev Madsy2 (n=madsy@ti500710a342-1253.bb.online.no) |
| 23:49.59 | Madsy2 | roxfan: Again, thanks a lot for your help last night. |