#milkymist IRC log for Wednesday, 2013-09-25

Action: ysionneau trying to compile gdb 7.6.1 for lm32-elf target13:46
ysionneauFYI a few days ago I got NetBSD kernel to compile and link into a lm32 elf binary13:46
ysionneauNow it's time for debugging and implementation of the few functions I left empty13:47
ysionneauI will be using qemu mostly, with gdb13:47
ysionneauMichael is cleaning up his patches in his mmu branch of qemu13:47
ysionneauwow, awesome, gdb compiled :)13:48
ysionneaugreat!13:48
ysionneauok it seems gdb 7.6.1 can connect to qemu-system-lm32 -M milkymist -s -S and do some single stepping14:03
mwallehiho16:56
sb0hi17:07
ysionneauhi !17:15
cdehi17:15
ysionneaumwalle: about your last e-mail, ok I got it now, I thought that the fact that GDB knows about the CSR id and that qemu knows where to read from when the code is accessing this CSR id would imply that the gdb code inside qemu would also know what to read upon request of this CSR id by gdb client17:17
ysionneauso I guess either gdb client is not requesting info about this CSR id, or either gdb server does not know where to find the value in qemu memory space17:24
mwalleysionneau: atm it is both17:24
ysionneauok17:24
mwalleneither the gdb has any support for the new registers nor does qemu17:24
ysionneauwell I can see in gdb client source code it has some notions about the new registers17:25
ysionneauat least in its bfd code17:25
ysionneauI guess it's just for desassembling code17:26
ysionneaubut it's not enough I imagine17:26
mwalleok i admit, i haven't actually tried it, i just had a quick look at the source code17:26
ysionneauI guess you're right, it still needs a few tricks to really be aware of those new registers17:27
mwalleand somewhere within the gdb/ directory is a function which returns the number of registrers17:27
ysionneauregister_names <=17:28
ysionneauyou got it17:28
ysionneauit lacks of PSW and TLB*17:28
ysionneaulet's add it...17:29
GitHub48[qemu] mwalle force-pushed master from 3f15f98 to 4d4fa05: https://github.com/mwalle/qemu/commits/master17:56
GitHub48qemu/master 949d83d Michael Walle: target-lm32: stop VM on illegal or unknown instruction...17:56
GitHub48qemu/master 89bc760 Michael Walle: lm32_sys: print test result on stderr...17:56
GitHub48qemu/master ed294f4 Michael Walle: lm32_sys: dump cpu state if test case fails...17:56
mwalleysionneau: i've just updated my github repository, please use the master branch for your mmu tests17:56
GitHub69[qemu] mwalle deleted mmu at 99e6157: https://github.com/mwalle/qemu/commit/99e615717:57
GitHub166[qemu] mwalle pushed 1000 new commits to for-upstream: https://github.com/mwalle/qemu/compare/b1e5fff4afd0...4470c88945cd17:57
GitHub166qemu/for-upstream 213c19d Andreas Färber: target-cris: Move cpu_gdb_{read,write}_register()...17:57
GitHub166qemu/for-upstream c3ce8eb Andreas Färber: target-alpha: Move cpu_gdb_{read,write}_register()...17:57
GitHub166qemu/for-upstream cfae5c9 Andreas Färber: target-s390x: Move cpu_gdb_{read,write}_register()...17:57
ysionneaumwalle: awesome! thanks :)20:30
ysionneaudidn't have time to try modifying gdb yet, had to leave for diner outside and I just came back in20:30
ysionneaugotta sleep now20:31
ysionneauwill see about that tomorrow hopefully20:31
ysionneaugn8!20:31
davidc__azonenberg: you're part of that homeCMOS thing eh? Is that still alive?21:21
GNUtoo-x60hi, I came found out that this channel was more apropriate than #qi-hardware for talking about the milkymist(-ng)21:31
GNUtoo-x60I'm looking again at its status some years later...21:31
GNUtoo-x60I found that there was a new device in "board bringup" phase,21:31
GNUtoo-x60so I wonder if it has any non-free dependencies: I downloaded some sources like migen and milkymist-ng, and I didn't find some yet...21:32
GNUtoo-x60Is the fpga syntetizing problem solved, or does it still require non-free vendor tools?21:32
GNUtoo-x60I guess that it's still necessary, because otherwise https://github.com/Wolfgang-Spraul/fpgatools.git would have a note on its README I guess...21:33
davidc__GNUtoo-x60: you still need FPGA vendor tools21:38
davidc__GNUtoo-x60: (though if you're being purist, one could argue the FPGA itself is a non-free dependancy)21:38
davidc__GNUtoo-x60: the FPGA vendor tool situation won't be solved for quite some time (if ever) I imagine21:38
GNUtoo-x60ok21:41
GNUtoo-x60The issue is that we need verifiable hardware...21:41
davidc__GNUtoo-x60: Is this a "wishlist" verifiable, or a  "I have a concrete threat model" verifiable21:42
davidc__because one is BS handwaving, the other is something that can be rationally discussed21:42
GNUtoo-x60(it starts becomming hard to really have freedom on common computers...)21:42
davidc__verifiable HW  != freedom21:42
GNUtoo-x60Background informations: I already use coreboot on the X60 with only the CPU microcode that is non-free,21:43
GNUtoo-x60(I'll get rid of it if I've the time...)21:43
davidc__Heh, well if you nuke the microcode "patch" there's still the microcode that was originally in it. Whats the difference? Not to mention the stuff in the north bridge; whatevers on your wifi card, probably something on your eth card if its new enough,21:44
davidc__Not to mention all the micros in common peripherals (keyboard, mouse, usb->sata converter, etc)21:44
GNUtoo-x60if all the remaining stuff is freed( like the NIC firmware, the CPU microcode that is avoided, and so on...), The issue is that I don't know how's the CPU is made:21:44
davidc__Well, you don't know how the FPGA is made either :P21:45
davidc__or the NIC21:45
GNUtoo-x60For instance the RNG isn't probably that good, and using the TPM for RNG wound't solve the problem and randio may be great but it's unproven so far...21:46
GNUtoo-x60I fear more the NIC firmware, because the NIC is on PCI and it has a DMA engine in the NIC...21:46
davidc__hell, if I wanted to backdoor your machine, I'd go after the NIC. 1) directly connected to a routable network, 2) hard to inspect outside of and 3) DMA access21:46
davidc__pfft, who cares about the FW. Do it directly in HW.21:47
GNUtoo-x60for the rest there is no AMT on the X60, too old...21:47
GNUtoo-x60though there is an ec...but it has no network or RAM access etc...21:47
GNUtoo-x60it only could implement a ring-buffer keylogger21:47
GNUtoo-x60anyway I see 2 long-term approaches:21:48
GNUtoo-x601) free existing hardware: it starts getting problematic:21:48
GNUtoo-x60AMD is not doing so well in buisness...21:48
GNUtoo-x60for Intel it's complicated:21:49
GNUtoo-x60if you take old hardware like the X201, the replacement for the BIOS is fully done(Coreboot, native GPU init etc...)21:49
GNUtoo-x60but the ME is signed21:49
GNUtoo-x60so even if someone succeed to replace its content with something that triggers the watchdog so it doesn't shutdown/reboot after 30min,21:50
GNUtoo-x60I heard that the new hardware doensn't even boot without the right code running on the ME21:50
GNUtoo-x60So a ground-up approach might work better...21:52
GNUtoo-x60Though the FPGA syntetizer issue is a big issuue21:52
GNUtoo-x60My other more practical question was to learn the status of the linux kenrel port on the milkymist one21:58
GNUtoo-x60but I'll probably look for myself21:58
GNUtoo-x60I guess there is no devicetree for that arch...21:58
GNUtoo-x60probably a board file...21:58
GNUtoo-x60and that probably contains every information needed.21:58
GNUtoo-x60ah it does use a dts22:03
azonenbergdavidc__: It's going slowly since i have a lot of stuff on my plate23:49
azonenbergi am still interested in doing it23:49
davidc__azonenberg: cool. Yeah, I might be looking at some stuff related to that (looking at generating plasmas for etching / etc)23:50
davidc__I might end up designing a DIY 13.56mhz RF supply + impedance matcher23:51
azonenbergOoh23:52
azonenbergYou want to do RIE or sputtering?23:52
davidc__azonenberg: RIE to complement my SEM23:52
davidc__for RE23:52
azonenbergooh23:52
azonenbergvery nice23:52
azonenbergI'm REing the XC2C32A, not sure if anyone mentioned23:53
davidc__didn't know that - cool23:53
azonenbergi have SEM cross sections and a low-res optical top metal image23:53
azonenbergas well as about 90% of the bitstream figured out23:53
azonenbergworking toward a full transistor-level analysis of it23:53
davidc__Nice. Once I get my SEM up and running, reversing FPGA bitstreams seems like a good start... just need to RE one of each type23:54
davidc__(sorry, I meant one CLB/IO/etc of each type)23:59
--- Thu Sep 26 201300:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!