| 01:34.46 | *** join/#neo900 Humpelstilzchen (erik@f054020108.adsl.alicedsl.de) |
| 01:42.19 | *** join/#neo900 rjeffries_ (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 02:02.41 | *** join/#neo900 MonkeyofDoom (~~Monkeyof@2601:d:3080:f8a:6ef0:49ff:fee1:a332) |
| 02:03.36 | *** join/#neo900 enyc (~enyc@muddle.enyc.org.uk) |
| 02:08.27 | *** join/#neo900 webmeister (webmeister@unaffiliated/webmeister) |
| 02:15.26 | *** join/#neo900 mva (mva@gentoo/contributor/mva) |
| 02:15.43 | *** join/#neo900 unclouded (~neil@2001:4428:200:80fc:7e05:7ff:fe0d:d421) |
| 03:12.14 | *** join/#neo900 rjeffries_ (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 03:50.48 | *** join/#neo900 ddark (~ddark@31.154.241.158) |
| 04:10.11 | *** join/#neo900 rjeffries_ (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 04:31.09 | *** join/#neo900 rjeffries_ (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
| 06:15.32 | *** join/#neo900 freemangordon (~ivo@46.249.74.23) |
| 06:29.18 | *** join/#neo900 Pali (~pali@Maemo/community/contributor/Pali) |
| 06:31.17 | *** join/#neo900 vakkov (~vakkov@79.132.29.146) |
| 07:34.40 | *** join/#neo900 kolp (~quassel@x5f776efd.dyn.telefonica.de) |
| 09:06.29 | freemangordon_ | Pali: here? could you look at mails in the neo900-devel ML, if you can give some idea on how to enable onenand in kernel? |
| 09:08.03 | *** join/#neo900 SylvieLorxu (~SylvieLor@dhcp-077-251-165-191.chello.nl) |
| 09:08.38 | DocScrutinizer05 | while THIS are really tiny pogopins: http://www.arieselec.com/products/data/23018-csp-micro-bga-test-burn-in-socket.htm see page bottom |
| 09:09.51 | freemangordon_ | :) |
| 09:10.44 | DocScrutinizer05 | I wonder ehat the socket incl err inlay would cost. I even wonder if I ever will be able to find out |
| 09:11.15 | DocScrutinizer05 | posibly a few kilobucks |
| 09:30.11 | DocScrutinizer05 | nah, friendly guys in Munich say it's a few hundred bucks only |
| 09:30.46 | DocScrutinizer05 | phone calls sometimes are really effective |
| 09:32.35 | wpwrak | pogo for bga ? neat ! |
| 09:50.18 | DocScrutinizer05 | yeah, and not really completely unfeasible to build a 'simple' tester for PoP chips from a BB-xM with a tiny "picture frame" PCB on top and such socket on top of the PCB |
| 09:51.01 | DocScrutinizer05 | I already have an offer to send those Munich guys a spec of the component we wanna test and they give us precise quote |
| 09:52.54 | DocScrutinizer05 | I also know how to design such stuff from other similar contraptions I've seen. Actually the 'tiny picture frame PCB' will be absolutely not that tiny, since it needs to be large enough to have 4 mounting holes for bolts that mount it rigidly to the BB-xM base PCB |
| 09:55.04 | DocScrutinizer05 | for positioning I suggest to have 2 (or 4) hollow vias over pins of OMAP FCPGA that are "do not use", so you can visually control positioning by looking though the via hole |
| 09:56.04 | DocScrutinizer05 | another 4 holes *exactly* on the 4 corners of OMAP will also help a long way for positioning |
| 09:57.23 | DocScrutinizer05 | dos1: Cell commented on Xmas Update - Neo900 - Neo900: is there an estimate on when will it be released? cause the specs r getting outdated quickly. |
| 09:59.12 | DocScrutinizer05 | could you please answer "while we are not competing regarding specs with any of the 'contemporary devices' we still hope to ship significantly before end of this year. But as always in development of any product: it's getting shipped when it's ready" |
| 10:00.40 | DocScrutinizer05 | OWTTE in your own words and more friendly way to say things :-D |
| 10:01.13 | DocScrutinizer05 | LOL |
| 10:02.44 | DocScrutinizer05 | wpwrak: we talked about inkjet printer and that I maybe need a cronjob to make it print a 'refresh page' once a week so it doesn't dry up. Guess what, it has a cronjob built in, it just started nozzle cleaning out of thin air, shocking me quite a bit |
| 10:03.17 | DocScrutinizer05 | X-P |
| 10:05.36 | DocScrutinizer05 | since that happened exactly 12:00 noon local time, you see the built-in NTP daemon works quite well ;-) |
| 10:06.18 | DocScrutinizer05 | I prolly need to check my network traffic and adjust my router's firewall for this brother printer |
| 10:07.17 | DocScrutinizer05 | idly wonders whom the printer gave a call already when I tried (in vain, aborted) to color-copy a 20EUR ygeldschein |
| 10:07.40 | DocScrutinizer05 | s/y*/banknote |
| 10:08.18 | DocScrutinizer05 | leftsuper+y = ding hotkey ;-) |
| 10:09.43 | DocScrutinizer05 | notices how electronic dictionary at your fingertips fosters mental laziness |
| 10:26.51 | *** join/#neo900 che11 (~che@n232.tum.vpn.lrz.de) |
| 10:29.11 | wpwrak | (can't copy 20 EUR) wow, creepy :) |
| 10:38.06 | DocScrutinizer05 | indeed, a silly inkjet printer detects german 20EUR banknotes and aborts copy |
| 10:38.15 | DocScrutinizer05 | that *is* creepy |
| 10:40.42 | DocScrutinizer05 | I *really* need to finally log all traffic on my LAN |
| 10:41.08 | DocScrutinizer05 | which is pretty tricky to accomplish |
| 10:41.34 | DocScrutinizer05 | the wonders of cheap routers :-/ |
| 11:09.12 | wpwrak | yeah, had you gotten a cisco, then the NSA would take care of logging your LAN ;-) |
| 11:09.41 | DocScrutinizer05 | (printer cronjob) of course I have no idea if the cronjob is really inside printer controller or maybe in PC driver for the printer |
| 11:09.55 | DocScrutinizer05 | wpwrak: LOL yeah |
| 11:10.35 | DocScrutinizer05 | wpwrak: but I bet they do even with my 2tier fritzbox|linksys setup |
| 11:11.35 | DocScrutinizer05 | http://leaksource.info/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/ |
| 11:16.18 | DocScrutinizer05 | makes you want a nonlinear junction detector with demodulator and wideband TX freq tuning |
| 11:16.53 | DocScrutinizer05 | plus a number of "old fashioned hubs" to splice into your cat6 cables |
| 11:17.41 | DocScrutinizer05 | the *names*!! "HOWLERMONKEY" |
| 11:22.57 | DocScrutinizer05 | "IRATEMONK provides software application persistence on desktop and laptop by implanting the HARD DRIVE FIRMWARE to gain execution through MBR substitution" - 2008-06-20 |
| 11:27.12 | DocScrutinizer05 | maybe Neo900 UG should contact NSA for component selection and sourcing, they seem to build quite some intriguing chips and stuff |
| 11:27.21 | DocScrutinizer05 | ;-) |
| 11:29.22 | DocScrutinizer05 | http://wstaw.org/m/2015/04/08/plasma-desktopwd1901.png |
| 11:40.12 | DocScrutinizer05 | http://wstaw.org/m/2015/04/08/plasma-desktopUF1901.png 'SNEAKERNET' is quite funny, obviously relating to those guys/entities that have no other access to IT infra and the SWAP application than waiting for someone wearing sneakers running around and delivering printouts or even spoken news |
| 11:41.09 | DocScrutinizer05 | we used the term "Turnschuhnetz" (~= SNEAKERNET) already back in the early 1980s |
| 11:44.55 | DocScrutinizer05 | on a somewhat related sidenote: Neo900 will provide a detector that could tell when somebody is using the obviously very popular method of "illuminating target with radar" mentioned multiple times in http://leaksource.info/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/ to eavesdrop on your local audio or device's data |
| 11:45.17 | DocScrutinizer05 | at least for some of the radar bands possibly used |
| 11:48.35 | DocScrutinizer05 | "SURELYSPAWN is part of the ANGRYNEIGHBOR family of radar retro-reflectors" |
| 11:49.57 | DocScrutinizer05 | you'd indeed suspect an angry neighbor when you notice somebody trying to 'fry' you with quite massive 2.4GHz microwave/radar radiation ;-) |
| 11:53.39 | DocScrutinizer05 | hey, you - as the attacking party - could even amplitude modulate the 2.4GHz TX at 80 or 90% with the usual halfwave sine found in common microwave ovens to cover the true purpose, and you can simply compensate for that AM by feeding it to RX demod amp negative input |
| 11:58.35 | DocScrutinizer05 | "GOPHERSET is a software implant for GSM SIM(!!!). This implant pulls phonebook, SMS, and call-log from target handset and exfiltrates it to a user-defined phone number via SMS" -- Sorry NSA, not on Neo900 ;-D |
| 12:00.00 | DocScrutinizer05 | worst case they could collect/keep an own hidden call-log but then calls are already publicly visible and thus known to whomever is interested |
| 12:02.35 | DocScrutinizer05 | and obviously they couldn't build a local hidden call log for times before the GOPHERSET was implanted, and they can't access any Neo900 call log from that time, even if such log exists in linux land |
| 12:05.40 | DocScrutinizer05 | MONKEYCALENDAR does same for GPS/geolocation data. Again no chance for doing that on a Neo900 |
| 12:24.49 | *** join/#neo900 Chat-ron (~alexandre@2a00:1a28:1166:f::1011) |
| 12:39.17 | *** join/#neo900 che11 (~che@n232.tum.vpn.lrz.de) |
| 12:46.58 | DocScrutinizer05 | now that's a smart device: https://leaksource.files.wordpress.com/2013/12/nsa-ant-ragemaster.jpg |
| 13:41.18 | freemangordon_ | Pali: ever seen "onenand_wait: timeout! ctrl=0x0000 intr=0x0000" in dmesg log? |
| 13:51.07 | freemangordon_ | Pali: isn;t it the same problem we hit when we enable onenand on n900? |
| 13:56.06 | *** join/#neo900 Humpelstilzchen (erik@x55b65910.dyn.telefonica.de) |
| 15:01.48 | *** join/#neo900 zipR4ND (~zipR4ND@213.187.85.13) |
| 15:19.27 | *** join/#neo900 arcean (~arcean@apn-46-215-94-243.dynamic.gprs.plus.pl) |
| 15:20.33 | *** join/#neo900 arcean (~arcean@apn-46-215-94-243.dynamic.gprs.plus.pl) |
| 15:23.59 | kerio | DocScrutinizer05: yeah but |
| 15:24.07 | kerio | think of the possibilities if they fucking released this micro technology |
| 15:24.36 | freemangordon | DocScrutinizer05: unfortunatelu it seems we won;t be able to draw a deffinite conclusion whether onenand works or not |
| 15:24.46 | kerio | that MAESTRO-II thing |
| 15:24.57 | freemangordon | at least not soon |
| 15:26.21 | DocScrutinizer05 | freemangordon: I'm not yet convinced about that stuff |
| 15:27.03 | DocScrutinizer05 | just did a https://www.google.de/search?q=%22onenand_wait%3A+timeout%21+ctrl%3D%2 |
| 15:27.16 | freemangordon | hmm? what stuff? you think the chip is faulty? |
| 15:27.19 | DocScrutinizer05 | seems the patch got introduced 2009 |
| 15:27.44 | DocScrutinizer05 | no, I think there's something wrong in kernel or uBoot |
| 15:27.54 | freemangordon | oh, deffinitely |
| 15:27.58 | freemangordon | I think the same |
| 15:28.05 | *** part/#neo900 zipR4ND (~zipR4ND@213.187.85.13) |
| 15:28.06 | DocScrutinizer05 | I wonder if we could boot N9 kernel |
| 15:28.27 | freemangordon | "we"? :) |
| 15:28.33 | DocScrutinizer05 | or use uBoot to do some decent flashing and readout of NAND |
| 15:28.54 | freemangordon | maybe it is not that bad idea to send me the second (faulty mmc if) device |
| 15:29.06 | DocScrutinizer05 | ok, no problem |
| 15:29.43 | freemangordon | as debugging sessions via email are nightmare |
| 15:29.50 | DocScrutinizer05 | indeed |
| 15:30.03 | DocScrutinizer05 | I already wondered if you could do that stuff remote |
| 15:30.08 | freemangordon | me too |
| 15:30.29 | freemangordon | but what I see as a problem is that someone should press the "reset" button on the device |
| 15:30.47 | DocScrutinizer05 | ouch |
| 15:30.54 | DocScrutinizer05 | I might find a way to do that remote too :-) |
| 15:31.02 | freemangordon | that would be great |
| 15:31.10 | freemangordon | is there WD on that BB? |
| 15:31.27 | DocScrutinizer05 | Nik built a 16 relay card 5 or 6 years ago... |
| 15:31.33 | freemangordon | oh |
| 15:31.43 | freemangordon | yeah, remote access will be the best approach |
| 15:32.24 | freemangordon | I only need the serial forwarded |
| 15:32.37 | freemangordon | or shell to the machine the device is attached to |
| 15:32.53 | DocScrutinizer05 | so I will ask Nik for a remote login account and some tiny hackery to connect reset switch to a relay |
| 15:33.04 | freemangordon | that will be great |
| 15:35.08 | DocScrutinizer05 | sent |
| 15:37.53 | DocScrutinizer05 | when relay card isn't available, then there's still ethernet power outlets |
| 15:38.30 | DocScrutinizer05 | which should be rather equivalent, when we power cycle the power supply |
| 15:38.44 | DocScrutinizer05 | ... unless board gets powered via USB |
| 15:40.15 | freemangordon | :) |
| 15:42.16 | DocScrutinizer05 | bbiam |
| 15:50.14 | DocScrutinizer05 | back |
| 16:17.32 | *** join/#neo900 ddark (~ddark@31.154.241.158) |
| 16:32.36 | DocScrutinizer05 | freemangordon: would you even want to mess around with MMC content? |
| 16:33.21 | DocScrutinizer05 | would you be able to do so via uBoot or whatever? or would you simply load kernel from serial/USB instead from MMC? |
| 16:34.47 | DocScrutinizer05 | btw NOLO actually has an option to boot kernel from USB attached storage IIRC |
| 16:35.15 | DocScrutinizer05 | so I guess uBoot must have too |
| 16:36.38 | DocScrutinizer05 | does ttyACM/USB work concurrently to mass storage mode? |
| 16:39.17 | DocScrutinizer05 | robot arm to move MMC from BB-xM to USB card reader, funny |
| 16:42.00 | DocScrutinizer05 | it's quite a pity Nik has so many other projects of higher priority than Neo900, so he frequently can't assign sufficient timeslots to us |
| 16:42.33 | DocScrutinizer05 | well, a pity for us |
| 16:42.44 | DocScrutinizer05 | maybe not so much for him, it seems |
| 16:43.00 | DocScrutinizer05 | :-) |
| 16:43.38 | rjeffries | DocScrutinizer05 what is working so far on Neo900? It seems your team has made decent if slow (!) progress. Is wpwrak still involved? |
| 16:43.50 | DocScrutinizer05 | sure |
| 16:43.56 | DocScrutinizer05 | nothing wrong |
| 16:44.27 | DocScrutinizer05 | just the progress being slow, among other reasons for the ones I just mentioned |
| 16:44.58 | DocScrutinizer05 | we're about to make NAND in our 1GB RAM PoP chips work with uBoot and kernel |
| 16:48.05 | *** join/#neo900 SylvieLorxu (~SylvieLor@dhcp-077-251-165-191.chello.nl) |
| 16:48.33 | DocScrutinizer05 | freemangordon and Nik debugged the stuff today, and we see a |
| 16:48.36 | DocScrutinizer05 | [ 3.601287] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x20000000, virtual base f0100000, freq 83 MHz |
| 16:48.37 | DocScrutinizer05 | [ 3.632690] onenand_wait: timeout! ctrl=0x0000 intr=0x0000 |
| 16:50.20 | DocScrutinizer05 | ooh what is *working*, not what is wrong. Well, the 1GB RAM seems to work just fine now, even in linux kernel |
| 16:51.16 | DocScrutinizer05 | [ 0.000000] Memory: 1004336K/1047552K available (5895K kernel code, 549K rwdata, 2336K rodata, 404K init, 8175K bss, 26832K reserved, 16384K cma-reserved, 252928K highmem) |
| 16:51.29 | DocScrutinizer05 | [ 0.000000] Machine model: BeagleBoard XM / GTA04 b7 / Neo900 Prototype |
| 16:52.55 | DocScrutinizer05 | the idiocy is: we can't find/get datasheets for that 1GB-RAM/512MB-OneNAND PoP chip |
| 16:54.14 | freemangordon | DocScrutinizer05: no (mmc contents) |
| 16:54.23 | DocScrutinizer05 | so if it wasn't the absolutely only chip existing that provides 1GB RAM and we (resp *you*, our customers) so badly want those 1GB RAM, we wouldn't even consider using such chip that has no public docs available |
| 16:54.25 | freemangordon | u-boot should be pretty much enough |
| 16:54.31 | DocScrutinizer05 | :-) |
| 16:54.41 | DocScrutinizer05 | freemangordon: thought as much |
| 16:58.18 | freemangordon | DocScrutinizer05: well, another option is to bite the bullet and assume that onenand works. if it turns that it is broken, well, you still have eMMC to put rootfs on |
| 16:58.32 | DocScrutinizer05 | freemangordon: would you need to watch any LEDs? |
| 16:58.38 | freemangordon | :D |
| 16:58.56 | freemangordon | NFC, I've never seen BB-XM in my life |
| 16:59.04 | DocScrutinizer05 | freemangordon: I don't think we could boot from eMMC |
| 16:59.11 | freemangordon | why? |
| 16:59.24 | DocScrutinizer05 | it's controller #2 |
| 16:59.38 | DocScrutinizer05 | boot sequence doesn't include #2 iirc |
| 16:59.54 | freemangordon | well, you can swap uSD/eMMC |
| 17:00.00 | DocScrutinizer05 | not really |
| 17:00.24 | DocScrutinizer05 | plus that would create another problem then: no boot from uSD |
| 17:00.44 | freemangordon | ok |
| 17:00.46 | DocScrutinizer05 | eMMC is 8bit bus, uSD is 4bit |
| 17:00.53 | DocScrutinizer05 | can't get swapped |
| 17:01.13 | ds2 | thought the DM3730 dropped 8 bit support? |
| 17:01.24 | DocScrutinizer05 | maybe we could find another SYS_BOOT config that allows booting from eMMC |
| 17:01.36 | DocScrutinizer05 | ds2: sorry? |
| 17:01.41 | DocScrutinizer05 | never heard of that |
| 17:01.43 | ds2 | wait |
| 17:02.54 | DocScrutinizer05 | (other SYS_BOOT) actually I pondered exactly that some ~60min ago |
| 17:02.58 | ds2 | just checked it. MMC1 is 4 bit only |
| 17:03.11 | DocScrutinizer05 | errr |
| 17:03.19 | ds2 | http://processors.wiki.ti.com/index.php/OMAP35x_To_AM37x_Hardware_Migration_Guide#8_data_bits_on_MMC1 |
| 17:03.43 | freemangordon | DocScrutinizer05: see in TRM, table 26-3 |
| 17:03.45 | DocScrutinizer05 | WTF? |
| 17:04.06 | freemangordon | 10001 and 10010 |
| 17:04.45 | DocScrutinizer05 | freemangordon: :nod: I seem to recall there's a SYS_BOOT config that has both MMC ports |
| 17:04.46 | freemangordon | ds2: AM37x == DM3730? |
| 17:04.57 | DocScrutinizer05 | yup |
| 17:05.02 | ds2 | freemangordon: yes, AFAIK... the DM3730 is the full one |
| 17:05.14 | freemangordon | ok |
| 17:05.17 | ds2 | other names are for DSPless, SGXless, etc versions |
| 17:05.33 | DocScrutinizer05 | AM has no errrr DSP? |
| 17:05.51 | DocScrutinizer05 | sth like that |
| 17:06.07 | DocScrutinizer05 | or what ds2 said :-) |
| 17:06.17 | freemangordon | ok |
| 17:06.35 | DocScrutinizer05 | ds2: are they mad? why did they drop 8bit? |
| 17:06.47 | DocScrutinizer05 | doubled data rate instead? |
| 17:07.05 | ds2 | donno. maybe silicon didn't work for 8 so they dropped it |
| 17:07.15 | DocScrutinizer05 | FFS |
| 17:07.31 | freemangordon | DocScrutinizer05: are you sure you can saturate 4bits @ 104 MHz? |
| 17:07.37 | ds2 | never looked into it as the stuff I was doing was for a uSD card |
| 17:07.52 | DocScrutinizer05 | freemangordon: when it does 104 then fine |
| 17:07.52 | freemangordon | ds2: ever played with onenand? |
| 17:08.00 | freemangordon | :) |
| 17:08.04 | ds2 | freemangordon: yes. |
| 17:08.10 | freemangordon | cool |
| 17:08.17 | ds2 | unsourceable by mere mortals |
| 17:08.17 | freemangordon | will you help ? |
| 17:08.28 | ds2 | help how? |
| 17:08.42 | DocScrutinizer05 | [ 3.601287] omap2-onenand omap2-onenand: initializing on CS0, phys base 0x20000000, virtual base f0100000, freq 83 MHz |
| 17:08.43 | DocScrutinizer05 | [ 3.632690] onenand_wait: timeout! ctrl=0x0000 intr=0x0000 |
| 17:09.02 | ds2 | oh that |
| 17:09.04 | freemangordon | that one |
| 17:09.19 | ds2 | tweak the timings in the driver |
| 17:09.31 | ds2 | fixed something like that on another board |
| 17:09.33 | freemangordon | but they come from n9/50 dts |
| 17:09.59 | DocScrutinizer05 | ...which uses the very chip |
| 17:10.01 | freemangordon | ds2: wanna full dmesg, with DEBUG enabled? |
| 17:10.11 | ds2 | IIRC (it has been over 5 years) - that timing depends on how other things are setup |
| 17:10.18 | ds2 | it wasn't calculated |
| 17:10.25 | DocScrutinizer05 | OMG |
| 17:10.33 | ds2 | freemangordon: don't think that will help too much |
| 17:11.00 | freemangordon | ds2: you mean that dts has bogus values? |
| 17:11.02 | DocScrutinizer05 | that might actually be the problem |
| 17:11.21 | ds2 | freemangordon: no... those values depend on everything else |
| 17:11.30 | DocScrutinizer05 | no, he means that it has incomplete values (or we don't use complete set of values) |
| 17:11.38 | freemangordon | ds2: anyway, scratch the timings... |
| 17:11.42 | ds2 | the problem I had before was - things work fine with the vendor kernel but didn't with the one we needed |
| 17:11.55 | freemangordon | any clue why "phys base 0x20000000" |
| 17:12.05 | ds2 | turns out we did the clocks differently so it needed new values |
| 17:12.20 | DocScrutinizer05 | actually what means "phys base 0x20000000"? |
| 17:12.27 | freemangordon | all dmesg logs from n9/50 have "phys base 0x400000" |
| 17:12.32 | ds2 | hmmm? that's the physical base address |
| 17:12.36 | DocScrutinizer05 | ds2: goooood point: CLOCKS |
| 17:12.40 | freemangordon | yep, I would like to know too |
| 17:12.45 | ds2 | this is a O3 platform right? |
| 17:12.49 | freemangordon | ds2: yes |
| 17:12.51 | freemangordon | omap3 |
| 17:12.55 | freemangordon | beagleboard |
| 17:13.03 | DocScrutinizer05 | with 512MB NAND |
| 17:13.17 | freemangordon | and 1GB of RAM |
| 17:13.20 | ds2 | DocScrutinizer05: Vendor kernel and L-O kernel at one point had different clocking frameworks |
| 17:13.24 | freemangordon | the same chip as in N9 |
| 17:13.34 | ds2 | let me find my TRM |
| 17:13.39 | DocScrutinizer05 | ooh, so that's the base addr for NAND in 64bit addr space? |
| 17:13.53 | freemangordon | ds2: u-boot is able to detect the chip correctly |
| 17:14.05 | ds2 | freemangordon: u-boot doesn't do PM |
| 17:14.16 | DocScrutinizer05 | :-D |
| 17:14.23 | DocScrutinizer05 | *clocks* |
| 17:14.42 | DocScrutinizer05 | and possibly even power domains |
| 17:15.18 | freemangordon | ds2: anyway, http://pastebin.com/FuikEiFu is the full bootlog, including 1st and 2nd stage BL |
| 17:15.42 | DocScrutinizer05 | freemangordon: don't you think it would be wise to try the N9 genuine kernel? |
| 17:15.57 | DocScrutinizer05 | I mean, 4.0 err... :-x |
| 17:16.04 | freemangordon | DocScrutinizer05: better the one from nemo |
| 17:16.12 | DocScrutinizer05 | bleeding edge is fine and all, but... |
| 17:16.20 | freemangordon | yeah, got it |
| 17:16.31 | freemangordon | but I don;t really can't be of help here |
| 17:16.55 | freemangordon | what I can do is to try to boot that kernel (Nik is using) on n900 qemu |
| 17:17.14 | DocScrutinizer05 | hmm that also sounds like a useful approach |
| 17:17.17 | freemangordon | I can tweak qemu to report the same onenand as on the real HW |
| 17:17.24 | freemangordon | if needed |
| 17:17.47 | DocScrutinizer05 | I guess we want to ship that board to you, eh? |
| 17:17.53 | DocScrutinizer05 | per express |
| 17:18.25 | DocScrutinizer05 | why can't you help on a slightly aged kernel? |
| 17:18.36 | freemangordon | If you manage to do it so it is here before eastern holidays :) |
| 17:18.53 | freemangordon | DocScrutinizer05: n9 kernel is different compared to n900 |
| 17:18.54 | ds2 | do this - grab the sources for that U-boot |
| 17:18.59 | ds2 | look at the timings there |
| 17:19.05 | ds2 | compare it with the debug output |
| 17:19.10 | freemangordon | ds2: I don;t think there are timings at all |
| 17:19.19 | freemangordon | in u-boot that is |
| 17:19.24 | ds2 | there is |
| 17:19.32 | ds2 | well... maybe |
| 17:19.39 | ds2 | it could be the rom timings |
| 17:19.45 | freemangordon | this u-boot is build with config for beagleboard, which uses NAND, not OneNAND |
| 17:19.59 | freemangordon | and the board itself is BB |
| 17:20.08 | ds2 | OneNAND kind of works as NAND for a lot of things |
| 17:20.09 | freemangordon | just the PoP is replaced |
| 17:20.22 | ds2 | blah... I need to run... sorry. I have to back to back mtgs :( |
| 17:20.45 | freemangordon | ds2: ok. please, look at the bootlog if you have time and will :) |
| 17:20.59 | ds2 | maybe this evening |
| 17:21.07 | freemangordon | great |
| 17:22.19 | freemangordon | DocScrutinizer05: what I am thinking is that maybe the GPIO config is wrong, I guess it is made for GTA04, not BB with onenand |
| 17:22.49 | freemangordon | but without having the schematic, I can't really tell |
| 17:26.18 | jake42 | schematics for gta04 and bb-XM are free to dl :-) |
| 17:26.57 | freemangordon | yeah, but not the schematics for that BB-xm with that replaced PoP :). I guess it makes difference |
| 17:27.12 | DocScrutinizer05 | bb-xm schematics are at https://raw.githubusercontent.com/CircuitCo/BeagleBoard-xM-RevC/master/BeagleBoard-xM_revC_SCH.pdf |
| 17:28.04 | DocScrutinizer05 | the differences to our frankenBB are just the PoP and the SYS_BOOT resistors |
| 17:28.34 | freemangordon | DocScrutinizer05: the difference is where are gpmc/Axx lines connected |
| 17:28.56 | DocScrutinizer05 | which lines? |
| 17:29.10 | freemangordon | gpio34-41 |
| 17:29.26 | DocScrutinizer05 | I doubt GPIO lines are on PoP |
| 17:29.35 | DocScrutinizer05 | and even when they are, they are not changed |
| 17:29.40 | freemangordon | they are muxed |
| 17:29.59 | DocScrutinizer05 | a BGA pin is a BGA pin |
| 17:30.25 | freemangordon | yes, but if some of the GPIOs are not set up correctly, onenand won;t work |
| 17:30.34 | DocScrutinizer05 | when CS1 (for example) is muxed, then we can find out about that without any schematics |
| 17:31.11 | DocScrutinizer05 | TRM will suffice to tell which GPIO is muxed on CS1 |
| 17:31.17 | freemangordon | why CS1? |
| 17:31.25 | freemangordon | isn't it on CS0? |
| 17:32.05 | DocScrutinizer05 | because I just thought that this is a signal that *might* not be needed on 512MB one bank RAM, which obviously is irrelevant and unrelated |
| 17:32.44 | DocScrutinizer05 | I guess for NAND pinout absolutely zilch has changed from original BB-xM |
| 17:33.00 | freemangordon | anyway, it seems I should read the TRM more carefully to try to grok how this shit works |
| 17:33.21 | freemangordon | is going afk |
| 17:33.32 | DocScrutinizer05 | see you later, I hope |
| 17:33.36 | DocScrutinizer05 | waves |
| 17:34.28 | DocScrutinizer05 | you're right (some of) the NAND signals also are on bottom balls |
| 17:34.40 | DocScrutinizer05 | but they always were |
| 17:35.23 | DocScrutinizer05 | so an incorrect muxing in that kernel would also affect a standard BB-xM and actually every OMAP3 device |
| 17:36.05 | DocScrutinizer05 | AIUI |
| 17:36.37 | DocScrutinizer05 | since also AIUI the pins on top and bottom are hardwired together, not muxed between upper and lower |
| 17:37.21 | DocScrutinizer05 | honestly I guess ds2 is up on something real with his clocks |
| 17:38.15 | DocScrutinizer05 | the controller timing config has to match the clock generating config |
| 17:39.06 | DocScrutinizer05 | when 4.0 is using a different divider/PLL setting for clock generators then you can't use a 2.x based timing together with it |
| 17:41.27 | DocScrutinizer05 | the memcontroller timings are no absolute values I guess. they are "5 clock cycles of clock#17". When you change clock#17 then you also need to change the timing value in memcontroller to get the same absolute nanoseconds result |
| 18:20.44 | *** join/#neo900 che11 (~che@h222.tum.vpn.lrz.de) |
| 18:24.26 | *** join/#neo900 nox- (noident@freebsd/developer/nox) |
| 18:35.19 | *** join/#neo900 sparetire (~sparetire@unaffiliated/sparetire) |
| 19:09.57 | *** join/#neo900 norly (~norly@enpas.org) |
| 19:11.14 | *** join/#neo900 norly (~norly@enpas.org) |
| 19:21.05 | freemangordon | hmm, N9 xloader does some weird stuff with gpmc/nand |
| 19:21.26 | DocScrutinizer05 | hmmm |
| 19:46.47 | *** join/#neo900 Humpelstilzchen (erik@x55b1d174.dyn.telefonica.de) |
| 20:59.18 | *** join/#neo900 mvaenskae (~mvaenskae@unaffiliated/mvaenskae) |
| 21:23.41 | *** join/#neo900 Kabouik (~quassel@65.76.93.92.rev.sfr.net) |
| 23:09.20 | *** join/#neo900 rjeffries (~rjeffries@pool-108-40-199-126.snloca.fios.verizon.net) |
