| 00:31.15 | *** join/#edev JoeLlama (n=snork@pool-71-110-219-97.lsanca.dsl-w.verizon.net) |
| 00:39.14 | *** join/#edev davidc__ (n=davidc__@user-12ldvch.cable.mindspring.com) |
| 00:57.27 | *** join/#edev linac (n=lin@122.90.83.230) |
| 01:28.19 | *** join/#edev landley (n=landley@cpe-66-68-109-179.austin.res.rr.com) |
| 01:28.19 | *** mode/#edev [+o landley] by ChanServ |
| 06:12.51 | *** join/#edev SandGorgon (n=Administ@122.162.50.31) |
| 07:46.15 | *** join/#edev chiques (n=working_@pool-71-189-111-152.lsanca.fios.verizon.net) |
| 08:30.08 | Zoiah | Hi, I have 2 unused devices based on Broadcom StrataSwitch architecture. One 3com 3870 (actually an Accton/Edgecore ES-4649) and one Dell PowerConnect (actually made by Delta Networks). |
| 08:30.34 | Zoiah | Both are powered by a MPC8245 and have two JTAG connectors on the board. |
| 08:30.56 | Zoiah | One COP-layout with the MPC8245 behind it and one PLD-layout with 2 CPLDs behind it. |
| 08:31.08 | Mirell | wonders how many will be awake 3AMish on a Sunday.. |
| 08:31.32 | Zoiah | I'm just visualizing it myself a bit. ;) |
| 08:32.51 | Zoiah | I got a Olimex ARM-OCD-USB which is able to connect to both JTAG ports. OpenOCD, UrJTAG and TopJTAG are all able to traverse the JTAG chain and see the devices, so I believe the connection is ok. |
| 08:33.51 | Zoiah | My current goal is to read and write the Flash ROM(s) on the devices. You can download binary updates from the manufacturers website, but this does not contain the bootloader. |
| 08:34.42 | Zoiah | The bootloader does not appear to have some kind of backdoor, so if I brick the device, I'm screwed. |
| 08:35.45 | Zoiah | OpenOCD does not support the MPC8245 at all. |
| 08:35.48 | Zoiah | UrJTAG supports doing memory I/O to the MPC8245, but is not able to detect any flash on any of the common (or uncommon) locations. |
| 08:38.31 | Zoiah | TopJTAG Flash Programmer directly toggles the pins of the flash device, but this requires you to know which flash pins are connected to which pins on the MPC8245. I do not have schematics, nor do I know how to trace the signals from the flash device to the MPC8245 BGA, so this does not work for me either. I foud some MPC824x-based reference schematics on the internet and tried their setup to no avail. |
| 08:42.35 | landley | Mirell: well, me for one. |
| 08:43.26 | landley | Zoiah: if you have a jtag, you can replace the bootloader they've got, if you've copied it off. |
| 08:43.49 | Zoiah | I am kinda stuck here and I've already dug all (for me) interesting things from the Accton firmware: http://stuff.zoiah.net/doku.php?id=accton |
| 08:43.50 | landley | Ah, but not if you haven't got the how-to-flash programming info... |
| 08:44.16 | landley | Um, actually you could copy the bootloader into ram with the jtag and run it from there and have it reflash itself, couldn't you? |
| 08:44.28 | Zoiah | Is anybody either familiar with Broadcom StrataSwitch + MPC8245 (even though the devices are from different ODMs, it seems the hardware and software design is at least similar, so I'm assuming they're from the same reference design.). |
| 08:44.46 | landley | Zoiah: you'll want to talk to prpplague on monday, during business hours for the US Central time zone. (He lives near Dallas.) |
| 08:44.52 | landley | He's the expert on this stuff, I'm not. |
| 08:45.01 | Zoiah | Or MPC8245/JTAG-fiddling in general. |
| 08:45.18 | Zoiah | landley: my idea was to try to put u-boot on the device. |
| 08:45.23 | landley | I take over once the sucker can boot a Linux kernel far enough to talk to a serial console from an initramfs. :) |
| 08:45.36 | landley | Isn't there a #uboot channel on here, or #u-boot or something like that? |
| 08:45.48 | Zoiah | But if I read their website and mailinglists, the U-boot people don't like you trying to run it from RAM. |
| 08:45.56 | landley | Ah, it's #u-boot. |
| 08:46.24 | landley | That's because it can't initialize the dram controller if it's running from ram. |
| 08:46.27 | landley | Chicken and egg problem. |
| 08:46.45 | Zoiah | http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM |
| 08:47.13 | landley | There was an openbios talk on exactly this thing at OLS in... 2006? |
| 08:47.49 | Zoiah | I read some people talking about putting a minitiature flash directly into the cache of the CPU and then flashing u-boot via serial. |
| 08:48.17 | landley | It's possible that uboot should be a touch more modular than it is. :) |
| 08:48.42 | Zoiah | The problem I run in to is that I have very little experience and there doesn't appear to be much generic subject matter available. |
| 08:48.54 | landley | The thing is, firing up the dram controller and getting it to work is actually fairly complicated, and is _the_ big fiddly thing the early boot code does. |
| 08:49.03 | landley | The rest of the hardware initialization is simple in comparison. |
| 08:49.13 | landley | What the LinuxBios (now OpenBios) people did was pull a fast one using the CPU cache. |
| 08:50.02 | Zoiah | What is OLS? |
| 08:50.18 | landley | They set up the CPU's translation lookaside buffer to think it had loaded in the first 4 or so cache lines from DRAM into the L1 cache. They let it fetch garbage, and configured it not to write the cache back to DRAM unless it had to evict those cache lines to make room for more. |
| 08:50.25 | landley | OLS = Ottawa Linux Symposium. |
| 08:50.32 | landley | I'll see if I can dig up the paper or recording in a moment. |
| 08:51.14 | landley | So anyway, once the CPU had fetched 4 cache lines worth of garbage, they zeroed the data out... which stayed in cache until they touched more dram. |
| 08:51.36 | landley | Then they were very careful to not touch any DRAM (only ROM, which the mapping said wasn't cached) until they had the dram controller up. |
| 08:51.43 | Zoiah | That sounds reasonable. |
| 08:52.07 | landley | This let them set the stack pointer to this 1k or so of memory, and jump to a C function. |
| 08:52.16 | landley | So they could initialize the DRAM controller from C code. |
| 08:52.22 | landley | Which made things MUCH MUCH simpler. |
| 08:52.43 | landley | This C code couldn't use any global variables, and could only use a small amount of local variables and not much recursion because it had a small stack to play with. |
| 08:52.46 | landley | But hey: C code! |
| 08:53.21 | landley | And then once the dram controller is clocked up and has time to stabilize and everything, they can start using the rest of the DRAM. |
| 08:53.46 | landley | the other thing is, openbios is only this early boot code. |
| 08:54.32 | landley | PC bioses actually havve two parts: the part that initializes the hardware, and the part that provides the tiny IDE/floppy device drivers and all the DOS callbacks and such that are used by lilo and grub and such to load an OS from disk. |
| 08:55.05 | landley | Those are two separate parts: OpenBios provides the first (hardware initialization), the Bochs Bios provides the second (bootloader and callback API). |
| 08:55.14 | Zoiah | The initialization and the realmode stuff nobody really ever uses anymore except for bootstrapping their own stuff. |
| 08:55.22 | landley | There's memory descriptor tables and such in there, I forget which half they live in. |
| 08:55.38 | landley | Zoiah: yeah, but it has to be there or you can't load. |
| 08:55.43 | landley | The thing is it's standardized. |
| 08:55.50 | landley | Intel proposed several replacements for it and they all SUCK. |
| 08:56.12 | Zoiah | Oh, wait, CoreBoot is not OpenBIOS. |
| 08:56.22 | landley | http://kerneltrap.org/node/6884 |
| 08:56.46 | landley | Zoiah: according to the issue of linux journal I have lying around, coreboot is another fork off of Linux Bios, I thought? |
| 08:57.00 | Zoiah | Yeah. |
| 08:57.27 | Zoiah | I was thinking they had booted Linux from this, but I was confusing the two projects. |
| 08:57.39 | landley | Sigh, http://www.linuxjournal.com/article/10447 isn't free yet, I'd have to root around for the paper copy I got at Ohio LinuxFest. |
| 08:57.50 | landley | Anyway, sounds like they're both descended from the same parent project. |
| 08:58.00 | landley | The LinuxBios project stalled, but forks of it continued. |
| 08:58.27 | landley | A bit like the gcc->egcs thing, except the original project didn't come back from the dead long enough to hand off the name this time. |
| 09:00.10 | Zoiah | I fiddled a bit with LinuxBIOS in the past. |
| 09:00.22 | landley | I didn't have hardware I was willing to risk bricking. |
| 09:00.25 | landley | I break everything. :) |
| 09:00.40 | landley | Hence "you wanna talk to prpplague". |
| 09:00.48 | Zoiah | Hot-swapping the flash device on x86 boards is generally easy. |
| 09:01.05 | Zoiah | So it's hard to actually brick it. |
| 09:01.11 | landley | Don't get me wrong, there are times I've had to do this sort of thing, and I have. |
| 09:01.40 | Zoiah | I've never had to do it, never had a job in this. Just having fun. :) |
| 09:01.52 | landley | It just tend to stick to software from the hobbyist end of things, because I always play around with stuff until I break it (or else I dunno what it does), and software you can reset from a backup. |
| 09:02.20 | landley | Hardware, once it's broken you have to put it back together again before you can continue. |
| 09:02.41 | Zoiah | That's indeed one of my problems. ;) |
| 09:03.52 | *** join/#edev SandGorgon (n=Administ@122.162.50.31) |
| 09:10.32 | Zoiah | I did run into some interesting things while disassembling the firmware of the 3com/Accton. |
| 09:10.55 | Zoiah | Among which a remotely accessible (telnet) backdoor: |
| 09:10.57 | Zoiah | http://stuff.zoiah.net/doku.php?id=accton:accton.pl |
| 09:11.03 | Zoiah | With a password generated from MAC-address. |
| 09:19.59 | landley | Zoiah: fun. |
| 09:22.07 | landley | Mostly these days for fun I play with qemu. |
| 09:22.08 | Zoiah | http://stuff.zoiah.net/doku.php?id=accton:backdoor shows an example |
| 09:22.10 | landley | Can't brick qemu. :) |
| 09:22.41 | Zoiah | Getting this firmware to run on qemu was out of my league. ;) |
| 09:22.50 | Zoiah | I tried. |
| 09:23.44 | armin76 | Zoiah: nope |
| 09:27.08 | Zoiah | landley: I'll try prpplague tomorrow, thanks. |
| 09:27.33 | Zoiah | armin76: worth a try. :) |
| 09:30.27 | *** join/#edev lyakh (n=lyakh@p57BD26A9.dip0.t-ipconnect.de) |
| 09:37.47 | *** join/#edev mbuf (n=mbuf@124.123.179.93) |
| 10:01.19 | *** join/#edev Geep (n=JoeBelow@bas21-toronto12-1242561276.dsl.bell.ca) |
| 10:01.19 | *** join/#edev biliquai (n=biliquai@61.6.64.6) |
| 11:14.22 | *** join/#edev pirho (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 11:30.20 | *** part/#edev landley (n=landley@cpe-66-68-109-179.austin.res.rr.com) |
| 12:20.15 | *** join/#edev menomc (n=amery@shell.opensde.net) |
| 13:26.27 | *** join/#edev pirho_ (i=pirho@gateway/gpg-tor/key-0x2CEEC9CB) |
| 13:45.02 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 13:45.03 | *** mode/#edev [+o GPSFan] by ChanServ |
| 15:07.31 | keesj | I know it's really a basic question so it should be easy to amswer |
| 15:08.01 | *** join/#edev JoeLlama (n=snork@pool-71-110-219-97.lsanca.dsl-w.verizon.net) |
| 15:09.05 | keesj | I am using the hammer(s3c2410) and some external GPIO pins, the soc is configured to have the embedded up-up resistors enabled and the buttons it attached to the soc drive the line to ground |
| 15:10.01 | keesj | I do need resistors to limit the current? I aske this becasue somewho whenever draw 3 pins down "all the pins go down" |
| 15:14.30 | keesj | hmm I think the problem are my pull-ups I added when prototyping with the arduino |
| 15:15.24 | keesj | yep! |
| 16:18.57 | *** join/#edev roxfan (n=dunno@91.182.227.161) |
| 16:30.24 | *** join/#edev freddy (n=freddy@hotel742.server4you.de) |
| 17:21.53 | *** join/#edev Crofton (n=balister@66-207-65-47.bark.dmt.ntelos.net) |
| 17:25.22 | *** join/#edev mbuf (n=mbuf@124.123.179.93) |
| 18:14.44 | *** join/#edev florian (n=fuchs@f049137152.adsl.alicedsl.de) |
| 19:13.54 | *** join/#edev Omegamoon (n=egoe@demolitionman.xs4all.nl) |
| 20:01.01 | Mirell | Sigh. |
| 20:11.51 | *** join/#edev lyakh (n=lyakh@p57BD26A9.dip0.t-ipconnect.de) |
| 20:18.30 | *** join/#edev Madsy (n=Madsy@fu/coder/madsy) |
| 20:51.33 | *** join/#edev chiques (n=working_@pool-71-189-111-152.lsanca.fios.verizon.net) |
| 20:54.32 | *** join/#edev JoeLlama (n=snork@206.169.63.10) |
| 20:59.32 | *** join/#edev davidc___ (n=davidc__@user-12ldvch.cable.mindspring.com) |
| 21:31.10 | *** join/#edev dijenerate (n=dijenera@64.210.44.37) |
| 21:40.27 | *** join/#edev roxfan2 (n=dunno@117.74-241-81.adsl-dyn.isp.belgacom.be) |
| 21:54.48 | *** join/#edev davidc___ (n=davidc__@user-12ldvch.cable.mindspring.com) |
| 21:58.40 | *** join/#edev davidc____ (n=davidc__@user-12ldvch.cable.mindspring.com) |