**** BEGIN LOGGING AT Fri Sep 02 02:59:58 2016 Sep 02 09:48:49 hi anybody is there Sep 02 09:49:09 i want to discuss about beagleboard x15 Sep 02 09:49:22 in that i need help Sep 02 09:50:25 what is your *specific* issue? Sep 02 09:54:25 hi tbr i need what type of expansion connector is there in beagleboard x15 and how can i buy it Sep 02 09:54:51 have you looked at the elinux wiki x15 page yet? Sep 02 09:55:55 high-speed surface-mount this is only they mentioned but how can i buy and where to buy Sep 02 09:56:11 iam from INDIA Sep 02 09:56:27 please here there is no help for me Sep 02 09:57:50 iam ready to buy that high-speed surface-mount connector and iam going to make PCB for that also Sep 02 09:58:25 you should have another look at that page Sep 02 09:58:35 and download the System Reference Manual Sep 02 09:59:28 ok Sep 02 09:59:33 specifically you might want to direct your attention to page 86 Sep 02 10:00:18 thank you so much TBR Sep 02 10:00:30 i found that Sep 02 10:21:52 zmatt: Yeah, it seems to be the case. The reset button fixes it, 'uboot> reset' doesn't, watchdog doesn't. Sep 02 10:22:37 zmatt: It Appears that the PHY might power up at higher voltage than the CPU (according to what I read) and thus be delayed to the cpu... This is causing. issues. Sep 02 11:05:44 is there external hardware connected? Sep 02 11:06:58 to the expansion headers I mean Sep 02 11:18:11 zmatt: Yep Sep 02 11:18:23 zmatt: It's powered via that. Sep 02 11:18:33 Custom build thing that we're testing. Sep 02 11:20:19 oh boy, I hope you paid careful attention to power domain crossings and what exactly happens during power up/down Sep 02 11:21:01 zmatt: That's what I'm starting to worry about. I'm not a hardware guy, I'm software. :-( Sep 02 11:21:11 Which is also why we pay someone else to do it. Sep 02 11:21:21 which may stink Sep 02 11:22:11 providing 5v via pins 5+6 of P9 is not a problem of course, but the question is how the stuff connected to the BBB I/Os gets powered exactly Sep 02 11:23:15 well if you're doing embedded stuff you're going to be a hardware guy whether you want to or not :) Sep 02 11:24:08 Yea, I'm learning that Sep 02 11:24:25 I was supposed to proof a report about TLS usage on constrained devices and recommendations... Sep 02 11:24:34 But instead I'm sitting here with hardware stuff Sep 02 11:24:37 And it hurts. Sep 02 11:25:29 I don't know about TLS specifically, but crypto is fine if you use good primitives Sep 02 11:26:01 This is more recommendations for interop and considering low-size /low latency packet streams in real time usage. ;P Sep 02 11:26:07 It's stuff I do know about ;) Sep 02 11:26:21 Instead, I'm reading the schematics for this and checking how they do the pins... Sep 02 11:27:12 depends on how much effort you're willing to put in ;) making good use of the AES accelerator could make symmetrical encryption pretty much free Sep 02 11:27:30 interop is more important than performance Sep 02 11:27:35 thus TLS :) Sep 02 11:27:58 well you mentioned "low latency" and "real time usage" too, so I was getting a bit conflicted message here ;) Sep 02 11:27:59 This is to be one of those legal / guiding documents saying "you must be at least this tall to ride" Sep 02 11:28:04 Yea Sep 02 11:28:12 also, AES isn't exactly going to be an interop problem Sep 02 11:28:13 ;) Sep 02 11:28:20 ... trust me Sep 02 11:28:25 With these vendors, it is Sep 02 11:28:30 They can't even figure out DHCP at times. Sep 02 11:34:00 the AES accelerator is very decent btw: 165 ns per (16-byte) block for most modes (incl GCM) with 128-bit key size Sep 02 11:34:28 zmatt: Neat. :) Sep 02 11:34:36 zmatt: ( The document isn't BBB specific. ) Sep 02 11:34:48 One of these days I'll learn how electronics work. Sep 02 11:35:13 also very key-agile: switching keys doesn't really take more time than writing the key register Sep 02 11:36:25 That is nifty Sep 02 11:36:37 Is there a private key store in the am33x? Sep 02 11:37:45 not really, although the (primary) aes key written into the AES acceleratio peripheral can't be read out Sep 02 11:38:06 But that doesn't survive reboots, I'd guess Sep 02 11:38:09 no Sep 02 11:38:11 or power loss Sep 02 11:38:27 Ah, so some external (nxp?) thing would be needed for that. Ach well Sep 02 11:38:28 if you mean whether there's a root of trust or any way to build one... no Sep 02 11:38:57 Nah, don't care about that Sep 02 11:39:21 Just want a write-only or per-cpu /board key that can be used to encrypt a secret with Sep 02 11:40:33 what good would that do? Sep 02 11:42:29 Basically, I want a verifiable unique per-board id that cannot be copied via a full disk readout or similar Sep 02 11:42:41 Avoid storing private keys in clear text. Sep 02 11:42:47 eeprom? Sep 02 11:43:21 btw, to get back to power stuff: try shutting down the beaglebone using the poweroff command and measure what happens to a couple of supplies, e.g. vsys and vdd_3v3b can be measured on P9 Sep 02 11:43:31 Spidler: use the RPMB of the eMMC ? Sep 02 11:43:55 for the first application at least Sep 02 11:44:34 rpmb would be a solution, yes. Sep 02 11:44:43 the second one you mention is much more involved since it required a public key crypto engine combined with the key store within the same secure boundary Sep 02 11:44:50 Yeah. Sep 02 11:45:22 zmatt: So, poweroff the device and measure the pins? That sounds doable. Sep 02 11:45:26 Thanks, Sep 02 11:45:35 especially the 3v3b Sep 02 11:47:20 Lemme dig up the oscilloscope :) Sep 02 11:47:22 Thanks! Sep 02 11:47:25 Very appreciated Sep 02 11:47:59 http://elinux.org/BeagleBone_Power_Management#Power_down has some example powerdown pics, although none are actually of an unpatched bbb Sep 02 11:49:11 on an unpatched one, 3v3b probably tries to stay active a bit longer but then vsys (green) will just crash faster and take everything down with it Sep 02 11:49:48 if however your external hw is injecting current, that will change things Sep 02 11:51:15 Thanks Sep 02 11:52:02 should you ever observe the 3v3b staying above 2V when the BBB is shut down, CUT POWER IMMEDIATELY Sep 02 11:52:54 e.g. this one was a yikes-moment: https://lh3.googleusercontent.com/-C9Uq48C-wwc/VUOT3kcXUXI/AAAAAAAAAC8/c6xC9VFFW5A/s1600/off-bat-serial.png Sep 02 11:53:19 Not sure how to read that, but it sounds scary Sep 02 11:53:36 Serial power fed BBB? Sep 02 11:53:46 ... power over serial. sounds absurdly scary. Sep 02 11:53:54 Wait. there's a name for that. Mbus! Sep 02 11:54:01 * Spidler goes to beat his head against the wall Sep 02 11:54:43 this was bbb powered via the battery connection of the PMIC, which has as side-effect that vsys remains powered after shutdown Sep 02 11:55:02 combined with the design flaw that causes the 3v3b regulator to remain powered Sep 02 11:55:16 combined with the uart console buffer being powered from 3v3b rather than 3v3a Sep 02 11:56:10 which means that if a serial cable was connected, the logic-high state was being rammed down the uart0_rxd pin of the cpu Sep 02 11:56:21 zmatt: compare 3.3v vs. Ground, or ? Sep 02 11:56:35 if not stated otherwise, yes always vs ground Sep 02 11:56:51 I'm not even ashamed of asking that, Don't want to fuck shit up worse ;P Sep 02 11:57:09 https://groups.google.com/d/msg/beagleboard/7sxPePT7wkM/V1Ft-xxh0agJ this message is the context of that image btw Sep 02 11:57:50 Oh. Right, so 3v3b is staying powered, and then the uart has power all time? Sep 02 11:57:53 That.. sounds odd Sep 02 11:57:56 no Sep 02 11:58:12 there's a buffer between the cpu and the console port Sep 02 11:58:17 meant to provide isolation Sep 02 12:02:14 except stupidly the buffer ic is not powered by vdd_3v3a (the 3.3v I/O supply of the cpu) but by vdd_3v3b (the "aux" supply for external components including expansion header, eMMC, sd card slot, etc) Sep 02 12:02:58 Oh.. Okay. Sep 02 12:06:23 the regulator bug causes the vdd_3v3b to remain on after shutdown (it uses vdd_3v3a as enable-signal, but leakage between the power domains via e.g. pull-ups keeps vdd_3v3a sufficiently high to be considered logic 1 by the regulator) Sep 02 12:07:36 the whole thing is actually saved by the (otherwise quite idiotic) behaviour of the PMIC of unconditionally switching to battery power at the start of sequenced shutdown, even if there's no battery Sep 02 12:12:41 Okay. how is it expecting the battery power to work? I'm learning all kinds of stuff I wasn't intending to ;-) Sep 02 12:15:12 there are terminals for direct connection of a li-ion battery pack (unsoldered 2x2 header labeled TP5-TP8) Sep 02 12:15:35 Oh, fancy. I didn't know that. Sep 02 12:15:38 but there are lots of details/gotchas Sep 02 12:15:52 the 3v3b regulator problem being the most prominent though Sep 02 12:15:53 Sounds like they should remain unsoldered for me. Sep 02 12:16:44 Right. So the BB-Green (other test) power cycles itself when you remove the ethernet cable. Sep 02 12:16:57 Everything is awesome. Sep 02 12:17:04 o.o Sep 02 12:17:10 what?! Sep 02 12:19:24 so.. We see 1.67V between Ground and vdd3v3 Sep 02 12:19:28 When it's in poweroff Sep 02 12:21:39 o.o Sep 02 12:21:56 your external hardware is slow-cooking the beaglebone Sep 02 12:22:10 sounds like it. Sep 02 12:22:38 that does perfectly explain ethernet trouble though Sep 02 12:24:54 1.0 V on the sys_5v Pin... Sep 02 12:24:56 Fuck. Sep 02 12:25:01 that's normal Sep 02 12:25:10 Okay Sep 02 12:25:18 In power off? good Sep 02 12:25:29 shutdown but powered, yeah Sep 02 12:25:31 So, it's the 3.3v that's leaking down there? Sep 02 12:25:40 vsys tends to hover around 1v then Sep 02 12:25:55 okay Sep 02 12:26:24 So. How is this _supposed_ to work, might be the next, relevant question Sep 02 12:26:47 the 3.3V from the addon board is appearantly shipping power down where it shouldn't. Clearly ungood ++ Sep 02 12:27:20 can you check 3v3a? the easiest measurement point is TP4 located near the PCB edge right next to the power led Sep 02 12:29:18 Yea, I can do that Sep 02 12:29:23 GImme a while to unscrew everything ;P Sep 02 12:31:14 note that it's reachable from either bottom or top side Sep 02 12:32:41 it's hugely important though I guess... 1.67V on 3v3b (and obviously not being supplied by vsys( is already quite bad Sep 02 12:33:11 Just had it screwed on to something, had to unscrew it, cause my probes couldn't get to it Sep 02 12:35:46 but in general every I/O of a chip belongs to some power supply domain. most chips are not okay with applying a voltage to its I/Os higher than supply + some margin or lower than 0V - some margin (margin is often 0.3V but it varies, check datasheet of component) Sep 02 12:36:46 this implies that if that power supply is off, you may not drive the I/Os high at all Sep 02 12:37:49 Let me see if I can comprehend this, I'll rephrase a bit. Sep 02 12:37:50 some chips are designed to tolerate it however, e.g. the console buffer on the beaglebone is 5V tolerant even when unpowered Sep 02 12:38:09 If the power supply is off, I really don't care about driving things. Sep 02 12:38:10 Ahh Sep 02 12:38:11 Right Sep 02 12:38:18 _then_ I understand Sep 02 12:38:33 And the 3.3v isn't, and it's now being supplied from the wrong direction? Sep 02 12:38:58 so basically, current is flowing back into the board via the peripherials that are on the addon board (3.3v) Sep 02 12:39:58 if the peripheral board is making its own 3.3v and driving that into beaglebone I/Os, then when the bbb is off (power supply = 0V) they're exceeding the max spec by nearly 3V Sep 02 12:40:51 Yeah, it is. Sep 02 12:40:53 Okay Sep 02 12:41:01 I saw 2.1 V on the sysv board in poweroff state. Sep 02 12:41:15 on what? Sep 02 12:42:08 TP4 => ground Sep 02 12:44:57 * plaw hi-5's pdp7 Sep 02 12:45:16 can't believe I actually checked this #.... so much idling Sep 02 12:45:17 So. if I right now remove our 3.3V feed from the board (jumper) we don't see that power leak. Sep 02 12:46:21 Spidler: 2.1V on vdd_3v3a ? Sep 02 12:46:28 yes Sep 02 12:46:30 ABANDON SHIP ABANDON SHIP Sep 02 12:46:45 commence flailing Sep 02 12:47:21 Happy times. Sep 02 12:47:24 * Spidler sighs Sep 02 12:49:02 maybe if you're lucky the timings in which the supplies come up when you apply power avoid serious violations (although the ethernet probs would make be worried) Sep 02 12:49:43 And what should the proper fix be? Sep 02 12:50:07 there's no short answer to that Sep 02 12:50:49 making sure the 3v3 of external logic is only powered once the 3v3 of the beaglebone is stable Sep 02 12:51:56 in that case do be careful not to cause the same problem in opposite direction though... that's easier however since you can leave the BBB pins high-z until the external logic is powered up Sep 02 12:52:27 (and they immediately go high-z again when reset is asserted) Sep 02 12:54:41 this is basically one example of the many ways of safely crossing a signal between power domains: make sure driver of the signal is disabled when the receiver is not yet powered Sep 02 12:55:12 using an open-drain/open-collector driver with a pull-up at the receiver side (to its supply) works too Sep 02 12:56:25 or use some buffer that's tolerant on its input side and power it from the receiver's suppy Sep 02 12:56:35 zmatt: I owe you a beer or two. Sep 02 12:57:52 Hmm Sep 02 12:57:59 there are also chips designed for the purpose, e.g. we use an lvds transmitter on the lcdc pins which has separate supplys for the digital inputs and lvds outputs, and allows the two supplies to be powered up/down in any order/combination Sep 02 12:58:13 I wonder if it would be enough for us to cut the 3.3v line from the cape to the board Sep 02 12:58:34 that makes no sense Sep 02 12:58:47 I have no idea :-) Sep 02 12:58:51 * Spidler is completely noob here. Sep 02 12:59:26 Remember that i sit here googling every third term that you're using Sep 02 13:00:28 the simplest solution of all is of course avoiding split power domains in the first place. i.e. use a single regulator with sufficient power budget Sep 02 13:00:31 A driver in my world is a piece of software. Sep 02 13:00:36 hehe Sep 02 13:01:08 And an open collector is a non firewalled udp listener accepting broadcasts from the local network. ;P Sep 02 13:01:14 lol Sep 02 13:01:56 Well. The problem is that the power supply on the BBB isn't enough to drive the 3.3V that the board needs for distances. Sep 02 13:02:08 yeah that's what I feared Sep 02 13:02:14 I'm perfectly fine with making sure that the board is the only supplier of 3.3v Sep 02 13:02:23 The problem is how the heck do you do that without mixing things. Sep 02 13:02:23 not possible Sep 02 13:02:38 Figured Sep 02 13:02:48 the 3.3v of the am335x needs to be carefully timed by the PMIC Sep 02 13:03:02 Ok. Sep 02 13:03:26 So the board fucks that timing up by being too fast, and then things get power out of order. Sep 02 13:03:46 And the board keeps delivering power as long as it's connected, even when the BBB has shut it's part down Sep 02 13:03:55 So voltages are high everywhere when it shouldn't be. Sep 02 13:04:13 god no it's not supplying 3.3v to the bbb I hope Sep 02 13:04:21 I certainly HOPE not Sep 02 13:04:29 you'd notice by 3v3b being higher than it is, and probably smoke appearing from somewhere Sep 02 13:04:34 Haha Sep 02 13:04:35 Okay Sep 02 13:04:59 let me elaborate on the problem of 3.3v Sep 02 13:05:01 Well, the problems go away when I break the jumper on the board's own 3v3 Sep 02 13:05:03 Please do Sep 02 13:05:54 the 3.3v supplies of the am335x are labeled VDDHV .. High Voltage Sep 02 13:06:47 if you check the datasheet you'll notice that pretty much everything else has 2V as Absolute Maximum Rating Sep 02 13:07:41 they also warn emphatically and repeatedly that under no circumstance (including during power up/down ramping) must any 3.3V supply of the am335x exceed the 1.8V supplies by 2V or more Sep 02 13:08:10 that's why the PMIC uses timed sequencing to bring up the 3.3V supplies after the 1.8V supplies are stable Sep 02 13:08:32 *Nod* Sep 02 13:08:59 PMIC, Power Management IC? Sep 02 13:09:13 and why measuring 2.1V on vdd_3v3a while the supplies are supposed to be off is good reason to get quite nervous Sep 02 13:09:16 yes Sep 02 13:09:25 Okay. That's very understandable Sep 02 13:10:39 the reason is that the am335x is manufactured on a 40nm process... while this is typically good for things like power, performance, and cost... those tiny tiny transistors really can't take that much of a beating Sep 02 13:11:20 *Nod* Sep 02 13:12:02 specifically, once you reach 2V across the gate of a transistor you quickly head into deep-frying territory Sep 02 13:12:28 Right, quite understandable. Sep 02 13:12:34 Shit's broken, yo. Sep 02 13:12:44 they actually have to do magic for 3.3V I/O, using cascaded transistors and an intermediate bias voltage to avoid 3.3V across any single transistor Sep 02 13:13:10 Intermediate bias voltage? *goes to google* Sep 02 13:14:01 Patents don't really help me understand things, google. *smacks the search world* Sep 02 13:14:38 ehh, like, voltage is like pressure: by using multiple valves you can step down from high to low pressure with sections of intermediate pressure levels inbetween to avoid too much pressure difference on each individual valve Sep 02 13:14:42 or something like that Sep 02 13:15:14 (very loose analogy) Sep 02 13:15:22 Right, so a step-up / step down ladder, small current in, add more current, ramping up to desired amount Sep 02 13:15:28 And then the other way around Sep 02 13:16:37 the details aren't terribly important, the main point was to illustrate that 3.3V is already well outside the comfort zone of the processor when all this machinery is operational Sep 02 13:19:25 Right Sep 02 13:19:46 So, right now I have a headache on my hands that I'm not sure how to fix. Sep 02 13:19:52 *Tosses back to fab* Sep 02 13:19:52 so if the bbb 1.8v supplies are not even (properly) powered up, then putting 3.3v on a processor I/O is simply a recipe for deepfried cpu Sep 02 13:20:04 that jumper you mentioned Sep 02 13:20:07 Mmm Sep 02 13:20:10 what does it connect exactly? Sep 02 13:20:52 Goes from the 5v power regulator on the board to the 3.3v Sep 02 13:21:04 Breaking it removes the 3.3v on the addon board completely Sep 02 13:21:08 the 3.3v of the external board Sep 02 13:21:09 right Sep 02 13:22:00 so what about my first suggestion: put the BBB in control of that (using any sort of suitable power switching device) Sep 02 13:22:44 make sure the default state is off and switch it on during early boot Sep 02 13:22:44 *Nod* Sep 02 13:24:42 So basically, triggering it with relay on the incoming 3.3v? Sep 02 13:24:57 ( Not quite, but that's about the term where I'm okay in electronics ;) Sep 02 13:26:19 hehe. I recommend against relying on the mere presence of the BBB's 3v3 though, use a GPIO instead Sep 02 13:26:43 Oh? Sep 02 13:26:51 Okay, I could do that Sep 02 13:26:56 using a power supply line as if it were a digital signal is a mistake (and one the BBB itself has also made, causing the 3v3b regulator bug) Sep 02 13:27:08 Not sure about the hardware people. I'm not that guy. Sep 02 13:27:13 Ahhh Sep 02 13:29:15 any more specific advice than this would be highly hardware dependent, and I'm afraid I have other stuff to do now :) Sep 02 13:29:29 Understood, thanks again, you've been very helpful Sep 02 13:32:06 Hm, if using a GPIO, do they all go low at shutdown? Sep 02 13:54:02 Hello Sep 02 13:55:53 Hi Blake Sep 02 14:03:31 Okay, I'm signing off to do something where I don't risk putting my desk on fire. Take care folks! Sep 02 14:06:42 where is the fun in NOT putting your desk on fire? :-C Sep 02 14:07:07 tbr: It's all about mood you know. Sep 02 14:07:22 or being a maniacal pyromaniac Sep 02 14:07:35 tbr: And I'm an easily distractable person who tends to sort of forget very interesting things.. Sep 02 14:07:45 ( Squirrel? ) Sep 02 14:08:15 Knowing your limitations is good, installing fire extinguishers and more than normal of smoke alarms also helps ;P Sep 02 14:08:43 Did you know that boiling eggs can be a health hazard? You might forget them and your egg timer catches fire. Sep 02 14:10:12 LPT has a signal for that Sep 02 14:10:46 Oh? Sep 02 14:13:08 However, if the online code was set to "on" and the check code was also set to "on", it meant that the printer still had paper, but was suffering an error (and may still be attempting to run). Due to the potentially hazardous conditions which could arise in early line printers, Unix displayed the message "on fire" to motivate any system operator viewing the message to go and check on the line printer immediate Sep 02 14:13:14 ly. Sep 02 14:13:21 → device on fire Sep 02 14:13:22 Ah, right Sep 02 14:13:23 Yes Sep 02 14:13:37 That kind of toner was nasty Sep 02 14:13:54 High speed mechanics near electronics near heat and flammable items... Sep 02 19:21:45 Hi I am looking for a tutorial that shows how to build a root files system from scratch for beaglebone black Sep 02 19:23:09 have you heard of "linux from scratch" aka lfs? Sep 02 19:24:47 oh and you do have an adapter cable for the debug serial port, right? Sep 02 19:24:57 I am referring to creation of root files system starting from busybox Sep 02 19:26:24 it doesn't get more from scratch than linux from scratch. Short of writing your own OS and kernel. Sep 02 19:26:50 I am using a book mastering embedded linux programming by Chris Simmonds but it seems to have left me in ditch Sep 02 19:28:26 I have been able to build kernel, dtb and u-boot Sep 02 19:29:34 so you want to put them on a SD card now? Sep 02 19:29:54 I have them on the sd card already Sep 02 19:30:16 the kernel boots up to the point that it is looking for a rootfs Sep 02 19:31:13 I know I can download an already compiled rootfs but I wanted to go through the pain of learning how to do this manually without relying on existing one Sep 02 19:31:53 there is the intermediate way of putting files together into a rootfs: https://eewiki.net/display/linuxonarm/BeagleBone+Black Sep 02 19:31:54 I understand that the following directories has to be created bin, sbin, dev, var etc Sep 02 19:32:11 then you can just use buildroot or openembedded/Ångström Sep 02 19:32:42 if you want to really go lower then http://trac.clfs.org/ is probably worth a look Sep 02 19:32:54 which is, as I initially mentioned linux from scratch Sep 02 19:32:57 Thanks tbr Sep 02 19:33:15 but again that is using an already compile rootfs Sep 02 19:34:04 no Sep 02 19:34:06 again buildroot , yocto does stuff in the back ground Sep 02 19:34:18 Cross Linux From Scratch (CLFS) is a project that provides you with step-by-step instructions for building your own customized Linux system entirely from source. Sep 02 19:36:18 I am looking up the website now thanks Sep 02 20:24:45 Hi.. anyone tried booting a custom kernel on beagle bone black? Sep 02 20:24:57 u-boot can pick the kernel Sep 02 20:25:13 but it is stuck at mmcblk1: p1 p2 Sep 02 20:25:31 before that i see messages like Sep 02 20:25:37 "waiting for root device" Sep 02 20:25:48 "unable to open rtc device" Sep 02 20:25:57 ArunMkumar: did you make your own initrd? Sep 02 20:26:37 no Sep 02 20:26:54 followed the instructions here at elinux http://elinux.org/Building_for_BeagleBone Sep 02 20:27:25 timestamp is 1.67 Sep 02 20:27:32 pretty early I think Sep 02 20:27:44 what is your kernel commandline for the root device? (like: "root=/dev/mmcblk0p1") Sep 02 20:28:42 right now it's stuck trying to find the rootfs and failing Sep 02 20:28:42 I found this in uEnv.txt Sep 02 20:28:43 root=${mmcroot} rootfstype=${mmcrootfstype} Sep 02 20:29:21 mmcblk0 which i think is my microSD card is picked up fine.. Sep 02 20:29:52 The size is mentioned as 8GB which is my microSD card Sep 02 20:29:59 looking for this mmcroot now Sep 02 20:31:40 it might be built into the uboot binary Sep 02 20:32:10 hey wait.. I see somthing here Sep 02 20:32:26 in the uboot messages I see this Sep 02 20:32:40 unable to read "uboot.env" Sep 02 20:32:47 from mmc0:1 Sep 02 20:32:56 using default environment Sep 02 20:33:02 Is this of any significance Sep 02 20:33:03 ? Sep 02 20:33:27 I'm not sure, I think that's normal Sep 02 20:35:46 ## Error: "mmcargs" not defined Sep 02 20:35:52 can this be a clue? Sep 02 20:36:42 isn't that what defined root=${mmcroot}...? Sep 02 20:37:19 I think so, my uEnv.txt file provided that Sep 02 20:44:08 0.000000] Kernel command line: console=ttyO0,115200n8 root= rootfstype=ext4 rootwait Sep 02 20:48:24 well, that's not right Sep 02 20:53:52 what is wrong in this , I am trying out multipole stuff here too Sep 02 20:54:46 my /boot/uboot/uEnv.txt has the following: Sep 02 20:54:49 mmcroot=UUID=dbc3462d-776f-495f-9422-1327eab5eab4 ro Sep 02 20:55:05 your uEnv.txt might be in /boot/uEnv.txt, depending on which image you're using Sep 02 20:55:26 instead of a UUID, it can be a device like /dev/mmcblk1p1 Sep 02 20:55:46 yes my uEnv.txt is in boot Sep 02 20:56:08 hey Sep 02 20:56:09 oh, mmcblkp1 in this case would be the onboard mmc Sep 02 20:58:28 'm working on a project using a radar module. here's the datasheet of the radar module: https://www.dropbox.com/s/f97hxkhglfevtar/Cayenne%20Data%20Sheet.pdf?dl=0 it uses a beaglebone black So with the radar module, I hooked up a USB to TTL Serial Cable to the serial ports because I'm trying to get serial data from the radar cape, but I'm not sure how to. Can anyone help me? Sep 02 21:00:08 what issue are you facing.. Sep 02 21:00:12 I am using serial cable too Sep 02 21:11:57 Well I don't know how to go about getting serial data from the radar cape. Sep 02 21:14:44 hey so this is the cable i'm using: https://www.amazon.com/GearMo%C2%AE-Header-TTL-232R-3V3-Windows-Support/dp/B004LBXO2A Sep 02 21:19:49 hey ArunMkumar? Sep 02 21:24:46 hey Sep 02 21:25:33 join the chat #sippy9090 Sep 02 21:30:50 ArumMkumar type '/JOIN #sippy9090' (without quotes) **** ENDING LOGGING AT Sat Sep 03 02:59:58 2016