**** BEGIN LOGGING AT Tue Jan 12 02:59:59 2016 Jan 12 03:32:23 40V is fine Jan 12 03:32:29 40V means it is NOT bricked Jan 12 03:32:45 that is the version signature for UART booting from the SoC Jan 12 04:37:58 i'm trying to get my dram test code to work but am getting dabort exceptions. Jan 12 04:38:24 i explain it in some detail here: http://www.digitalsignallabs.com/flat.txt Jan 12 04:38:52 can someone help? Jan 12 04:41:40 btw, matt, your stack pointer initialization in your code made some unnecessary assumptions which cost me a lot of time. Jan 12 04:42:22 namely, that .pushsection stuff. Jan 12 05:27:37 i've also posted this in the ti e2e site. it may make more sense to answer there: https://e2e.ti.com/support/arm/sitara_arm/f/791/t/482207 Jan 12 07:06:47 is it just me or are all the images on the element14 website rendered at like 20% quality Jan 12 07:25:29 Hi Jan 12 08:38:19 what is the user and password for debian image on beaglebone black? Jan 12 11:29:40 zmatt: ^^^^ Jan 12 11:30:23 torpico: you mean for root? it is blank, typically. just enter return at the password prompt. Jan 12 11:40:03 I have installed debian image in my beaglebone black. I want to connect to itfrom another computer via ssh. is this possible from another computer? Jan 12 12:12:03 yates: do you know the answer of my question? Jan 12 12:25:50 torpico: debian / temppwd Jan 12 12:27:13 yates: ugh, why would you write the entire test in asm... (note that my original example was in pure asm only cause someone specifically asked for a pure-asm baremetal example, I personally do not think it helps readability) Jan 12 12:28:53 yates: and I'm not gonna read all that stuff Jan 12 12:29:40 you're still doing misaligned stores though Jan 12 12:30:08 (which would be allowed if the MMU were enabled and the memory type set to normal, but this isn't the case) Jan 12 12:31:41 str is a 32-bit store, while you're incrementing the address by 2, hence the second iteration aborts Jan 12 12:39:06 zmatt: thanks. I have installed debian image in my beaglebone black. I want to connect to itfrom another computer via ssh. is this possible from another computer? Jan 12 12:40:56 ssh root@192.168.7.2 Jan 12 12:40:56 ssh: connect to host 192.168.7.2 port 22: Connection refused Jan 12 12:41:02 it gave me this Jan 12 12:43:34 is it connected via usb? Jan 12 12:44:31 also, you probably can't ssh as root, use username debian, password temppwd Jan 12 12:54:15 zmatt: yes via usb. Jan 12 12:56:31 zmatt: I want someone from another pc connect to my beaglebone black. can s/he do that while th BBB is connected to my pc not him Jan 12 12:56:37 ? Jan 12 13:02:39 complicated, I would recommend connecting the BBB to ethernet for that Jan 12 13:02:53 (it will acquire an address via DHCP) Jan 12 13:03:28 I'm afk for a bit Jan 12 13:14:40 zmatt: when I type http://192.168.7.2/ in my chrome browser it asks me username an password. what should I write? and what is this http://192.168.7.2/ address? Jan 12 13:15:11 I read manual but it didn't give me the clue I needed. Jan 12 13:47:07 guys, those here structions means I can connect to BBB via another computer (while it is connected via usb and Ethernet to my computer) ? Jan 12 13:47:11 http://elinux.org/Beagleboard:Terminal_Shells#SSH:_Setting_up_a_Static_IP Jan 12 13:47:26 help Jan 12 13:48:12 unable to start my beaglebone black Jan 12 13:49:17 JOIN Jan 12 13:49:24 HELP Jan 12 13:50:18 ?? Jan 12 13:56:02 heeeeeeeey? any one in here? Jan 12 13:56:16 those here structions means I can connect to BBB via another computer (while it is connected via usb and Ethernet to my computer) ? http://elinux.org/Beagleboard:Terminal_Shells#SSH:_Setting_up_a_Static_IP Jan 12 14:10:05 http://www.catb.org/esr/faqs/smart-questions.html Jan 12 14:11:45 torpico: those instructions presume that you have a way to access the BBB, either by ssh or by serial console. Also assigning a static IP shouldn't be necessary if DHCP is working. Jan 12 14:24:10 and please also note people in here are not paid to help they volunteer thier time and knowledge so please be patient and if someone can help they will Jan 12 14:31:13 tbr: in abstraction I have installed debian in my beaglebone black - I have access to it via minicom - after I use command "if config" it shows it has DHCP connection - I have an ethernet cable too but still not connected it to BBB /////// now I want someone from another PC connect to my BBB. But I don't want give him my bbb. My question is this: how I should do this? Jan 12 14:31:43 conect over the net? Jan 12 14:32:12 need to forward whatever port you need ie ssh or web or whatever in your router to your bbb ip Jan 12 14:32:51 or connect ethernet to the other laptop and bbb and indeed manually configure the interfaces with some IP addresses from a common subnet that doesn't collide Jan 12 14:33:32 that will only work on lan though? Jan 12 14:36:45 obviously Jan 12 14:36:56 I'm still a bit unclear what torpico is up to Jan 12 14:40:31 what this do? http://elinux.org/Beagleboard:Terminal_Shells#SSH:_Setting_up_a_Static_IP ? shouldn't I do these structions for DHCP? Jan 12 14:41:45 torpico: first you should get a clue about what you are trying to do in general Jan 12 14:41:58 you don't start bulding a house by constructing the roof Jan 12 14:42:55 To achieve that it would really help you for the future if you'd spend some time trying to understand how IP networking works Jan 12 14:43:17 magic? Jan 12 14:43:39 and duct tape, lots of duct tape Jan 12 14:44:32 tbr: someone else wants to use my bbb as a node for their cloud system. I want him to access my BBB, but without having bbb in his hand Jan 12 14:45:04 torpico: so are you at the same desk? in the same building? on the same planet? Jan 12 14:49:54 tbr: yes, same desk Jan 12 14:50:26 ok and his laptop has a RJ-45 LAN port? Jan 12 14:50:39 is it in use or is it available? Jan 12 14:53:08 Yes have that port Jan 12 15:50:46 tbr: AppleTalk was really so much easier Jan 12 15:50:56 hehe Jan 12 15:53:30 seriously, I know under the hood there were things like network ids, node ids, ports and shit like that but even as developer you never really needed to deal with them. Name (string), service (string), and on larger networks Zone (string). Jan 12 15:55:13 for LANs, TCP/IP is still far behind Jan 12 15:55:53 (in theory all the pieces are there, in practice they may not be installed, working, or supported properly by applications) Jan 12 16:00:56 https://www.youtube.com/watch?v=sdXp6qLSoTE :P Jan 12 19:10:30 jkridner: you are seroius with your quote to ROS on hackaday? Jan 12 19:10:38 yeah. Jan 12 19:10:42 neat Jan 12 19:10:50 With the recent work to put ROS on Jessie, I don't feel bad committing to it. Jan 12 19:11:57 We'll definitely have people play with the integration of ROS in the next few weeks, well ahead of the May launch. Jan 12 19:14:08 will see :) Jan 12 19:19:06 Hi. I've build u-boot for beagle. Now I'm trying to run u-boot on qemu. Want to get the u-boot shell prompt. But I'm stuck. Jan 12 19:19:06 Instructions from here (http://www.cnx-software.com/2011/09/26/beagleboard-emulator-in-ubuntu-with-qemu/) worked flawlessly . But I want to get u-boot shell only. Jan 12 19:20:57 ...I've also built qemu-linaro from sources to make support beagle. Fuh. Jan 12 21:23:02 So I'm still in the market for an early splash logo for BBB. I do have that working from u-boot, but the image disappears as soon as the kernel starts. I'm assuming this is some sort of clock/pin/power reset happening as a part of the board init process. So I guess it is back to the drawing board on this one. Jan 12 21:25:31 Therefore, my question is this: What happened to the early framebuffer? From what I can tell BBB inits LCDC and TDA998x some 11 seconds into the boot... Jan 12 21:28:38 That would not have been a problem if the kernel did not also kill my LCDC + TDA998x initialization. Jan 12 22:10:20 I'm poking around in the kernel config and I've come across a thing called simple frame-buffer. To me, this looks like exactly what I need: "This driver assumes that the display hardware has been initialized before the kernel boots, and the kernel will simply render to the pre-allocated frame buffer surface." Jan 12 22:10:51 Has anyone seen or played with something like this? Jan 12 22:31:13 eliasbakken: i've worked with that a bit on sunxi systems ... requires a u-boot or other bootloader to configure the framebuffer Jan 12 22:32:06 vagrantc: Yeah, I've got that working, but as soon as the kernel starts, everything is lost. Jan 12 22:32:27 eliasbakken: it needs support in u-boot separate from u-boot's framebuffer support Jan 12 22:32:49 eliasbakken: it sounds like you got u-boot's framebuffer support working Jan 12 22:33:02 simple-framebuffer needs to be supported in u-bot? Jan 12 22:33:14 eliasbakken: but you need to also write code to get u-boot to set up the simple-framebuffer that linux will then assume is all configured and ready to use Jan 12 22:33:55 "display hardware has been initialized before the kernel boots" Jan 12 22:34:07 where would you do that other than the bootloader? Jan 12 22:34:41 Yeah. Like I said, I've been working on it for a few days now, and I have the LCDC + HDMI framer set up for BBB. Jan 12 22:35:40 like i said, i've used simple-framebuffer on sunxi systems, and it sets up the simple-framebuffer from u-boot. Jan 12 22:35:53 OK, great! Jan 12 22:36:05 Or not great, but thanks for letting me know! Jan 12 22:36:48 From what I've read, the simple framebuffer also needs to be configured in the DT, right? Jan 12 22:37:09 yes Jan 12 23:02:15 does the am335x power in in Thumb state or in ARM state? Jan 12 23:02:54 also, what is the CFGTE input discussed in the A8 TRM? Jan 12 23:03:05 input to WHAT? Jan 12 23:03:47 s/power in in/power on in/ Jan 12 23:23:28 Vagrantc: So the simple-framebuffer node needs to be set up in the DT of both u-boot and the kernel, and match, is there anything else? I see there is some reference in the sunxi_display driver that the memory is reserved for the kernel, is that waht you are referring to? Jan 12 23:26:09 eliasbakken: i haven't actually read any of the code, but simply grepping through u-boot sources for simple-framebuffer and simplefb seem to produce some files to explore. Jan 12 23:26:28 looks like raspberrypi also may use simplefb Jan 12 23:26:59 that's about as much information as i have on the subject Jan 12 23:28:01 Yes, I did that! Thanks, I'll digg a bit deeper then! Jan 12 23:28:23 good luck! Jan 12 23:33:34 yates: it powers up in ARM state, although that's not particularly important since it powers up in secure world. entry of public ROM is also in ARM state, as is entry of the program (or secondary loader) loaded by public ROM Jan 12 23:35:18 both pubrom and secrom are a mix of ARM and Thumb code, and appear to have been produced using different compilers and then linked together, no idea why Jan 12 23:38:43 the CFGTE input is an input to the cortex-a8 processor (presumably tied off low in TI's instantiations of it) Jan 12 23:40:57 note that I can't actually be *certain* of its value on the am335x either, but overall the ROM appears to be closely related to that of the dm814x and there secrom was readable (hence I know it starts up in ARM mode) Jan 12 23:51:10 eliasbakken: the kernel should not be loading the tilcdc driver or touch the lcdc peripheral unless there's a DT node for it Jan 12 23:51:53 eliasbakken: using simple-framebuffer is an option if you want the kernel to be able to use the framebuffer you set up Jan 12 23:52:14 the memory used for it needs to be reserved either way obviously Jan 12 23:53:36 omitting or disabling the lcdc DT node (or blacklisting the driver if compiled as module) and reserving the framebuffer memory should suffice to keep the kernel from messing with your splash Jan 12 23:55:00 ohh wait, it may indeed Jan 12 23:55:13 but then simple-framebuffer isn't going to save you either Jan 12 23:55:41 it will by default disable all 'unused' modules Jan 13 00:01:53 there's a compile-time option to keep the kernel from doing that, not sure if there's also a runtime option. you may be able to convince the kernel that the lcdc module is in use (by sticking a ti,hwmods = "lcdc"; property onto a suitable DT node) or foil its attempt to disable it by setting lcdc's IDLEMODE and STANDBYMODE both to 1 in its sysconfig register Jan 13 00:02:19 I'm not sure the latter will keep it from meddling with the display PLL though Jan 13 00:03:05 in short, linux has some tendency to be meddlesome :P Jan 13 00:04:35 the annoying bit is that the kernel's knowledge that the module exists and can be disabled is hardcoded rather than coming from DT (that hardcoded knowledge is what's being referenced using ti,hwmods) Jan 13 00:05:34 the intention is that such hardcoded knowledge will eventually disappear and move into DT, which would allow you to hide lcdc entirely from the kernel's knowledge, but we're not there yet Jan 13 01:11:51 zmatt: the processor determeins its ARM/thumb mode at run-time from the state of the pcrs.T bit, right? Jan 13 01:12:05 T = 0 means ARM mode? Jan 13 01:13:36 and if it's in ARM mode, literal LDR should use the PC+8, right? Jan 13 01:14:28 I'm seeing pcrs.T = 0, but the process is using PC + 4 in an LDR literal instruction.. Jan 13 01:14:31 processor Jan 13 01:15:16 opcdoe is 0xE59FD024 Jan 13 01:15:53 so it's an ARM (A1) encoding, right? Jan 13 01:17:44 the immediate value is 0x24, and the pc of the instruction is 0x40240524, and it is loading the value at 0x402f0550 Jan 13 01:25:17 correction: pc of the instruction is 0x402f0524 Jan 13 01:33:56 nm. Jan 13 01:41:07 you can't necessarily tell from the code whether it's ARM or Thumb, as you said the processor keeps track of the instruction set currently being used in cpsr (while bit 0 of the instruction address is used for indirect branches and returns)... also, why are you manually performing the task of a disassembler? :P Jan 13 01:42:25 (at least, binutils objdump adds a comment after a literal load indicating the address of the literal) Jan 13 01:44:38 because it pleases me Jan 13 01:45:13 because i like to hear you get dumbfounded? Jan 13 01:45:27 or..., just because. Jan 13 01:45:31 why ask why? Jan 13 01:45:38 hehe Jan 13 02:38:27 rcn-ee: have you ever seen any anomalies on the framebuffer when not using X11? (but e.g. fb console or qt5 apps using the linuxfb backend) I'm seeing strange issues across different kernels (4.1-ti to 4.4-bone), apps (aforementioned), and lcdc configurations (hdmi and custom lcd cape) Jan 13 02:39:40 zmatt, other to side to side shifting, not much.. haven't tried linuxfb, i've only used x11/wayland.. Jan 13 02:39:58 side to side shifting would be one of the issues yes :P Jan 13 02:41:11 specifically that's the one I've seen using fb console, I'm seeing a different issue when using linuxfb on a kernel configured without framebuffer console Jan 13 02:41:46 we've always had that one, even back in 3.8.x days'.. Jan 13 02:42:09 namely the last column being a copy of specific earlier column... haven't counted the pixels yet, but it looks suspiciously like the same offset as the side-to-side jumping Jan 13 02:43:11 you thinking a dma bug, or an mis-hsync signal? Jan 13 02:43:15 that's interesting, since that means the issue has existed across different drivers Jan 13 02:43:32 well in 3.8 that was rob's first tilcd.. so same driver.. Jan 13 02:43:44 hm, ok Jan 13 02:45:07 well any suspicion I may have had of sync signals have been disposed of by the fact it persists with our lvds transmitter and an lcd panel that doesn't use hsync/vsync (it infers them from oe) Jan 13 02:45:29 plus the altered nature of the issue when using a linuxfb qt5 app Jan 13 02:47:23 replacing pixel WIDTH-1 by pixel WIDTH-N (for some fixed N) on every line can't be explained by sync Jan 13 02:47:40 in fact, I have trouble coming up with any plausible explanation for it at all Jan 13 02:47:52 the content of /dev/fb0 is correct however Jan 13 02:48:20 and it persists even after the qt5 app exits and leaves the final image on screen Jan 13 02:49:23 so it's corrupting it from /dev/fb0 thru the tilcd ip block.. Jan 13 02:50:31 I don't know whether linux copies the framebuffer every frame (since I think the kernel is supposed to submit new buffers via the driver and not modify an old one until released?) Jan 13 02:52:47 i.e. where it could be going wrong there (I don't see how) or in the lcdc peripheral itself (I don't see how) Jan 13 02:53:47 the jumping I could sort of have understood... the "new" issue otoh is far more bizarre Jan 13 02:55:46 hmm, maybe I'll see if I can reproduce the new issue via hdmi on my old jtag-equipped BBB, then halt cortex-a8 and leave lcdc to run autonomously and see what happens Jan 13 02:56:02 jkridner, anyone at ti we can bug for zmatt's ^^ something odd with the tilcdc block.. Jan 13 02:58:48 there's a thread on e2e I participated in to try to debug someone having issues with tilcdc; they were quite different, and occurred using a gpu-accelerated app, but equally mysterious Jan 13 02:59:32 three incarnations of mysterious corruption, all appearing different... there may be a single underlying cause Jan 13 02:59:57 i think the gpu just writes to /dev/fb0, so it's the block from memory -> output that seems to be corrupting it.. **** ENDING LOGGING AT Wed Jan 13 02:59:59 2016