**** BEGIN LOGGING AT Wed Oct 05 02:59:56 2022 Oct 05 03:03:58 21, 22! Oct 05 03:58:41 How would I change, in python on the BBB for the ServoCape usage, a hex to an int w/ @zmatt's older source for handling a servo? Oct 05 03:58:49 hint, hint! @zmatt! Oct 05 04:00:20 https://pastebin.com/DSj7DJ9k is the error. Oct 05 04:00:52 It seems the bytes was giving me the willies. I needed to use hex. Now, the above paste has the error instead of ' remote error '. Oct 05 04:01:13 It is my source now! So, I am at fault. Oct 05 04:25:39 I have no idea what I'm looking at Oct 05 04:25:53 Oh. Oct 05 04:26:08 the only thing I can conclude from that error is that you wrote nonsense in python and python is complaining about that Oct 05 04:26:13 pastebin.com/RhKjeKC1 Oct 05 04:26:37 https://pastebin.com/RhKjeKC1 Oct 05 04:27:22 that is the old source. i changed it to handle hex. Oct 05 04:27:33 Instead of bytes, i am using hex. Oct 05 04:27:43 that phrase doesn't make sense Oct 05 04:27:58 Oh. Oct 05 04:28:07 Dang it! Oct 05 04:28:24 like, I can't even begin to guess what you could even mean by saying that Oct 05 04:28:37 I was using an address. Oct 05 04:28:49 0b111111 and now I am using 0x34. Oct 05 04:29:19 okay, and? Oct 05 04:30:04 I received an ` remote error ` on the 0b111111 address but I received an error about the paste during the hex address. Oct 05 04:30:24 that error is not occurring in the code you pastebinned Oct 05 04:30:47 i know Oct 05 04:31:04 Let me get that source. Oct 05 04:31:06 Brb. Oct 05 04:31:49 and no modification is required to the Pca9685 class, you can just pass a different address (whether you choose to write it in binary, hex, or decimal, is absolutely irrelevant... they're just different ways to write a number) Oct 05 04:32:18 https://pastebin.com/srK0gziv Oct 05 04:32:43 oh Oct 05 04:33:04 yeah this code is just... nonsense Oct 05 04:33:17 i thought it used to work. Oct 05 04:33:39 I made a hard copy of it for some reason. Oct 05 04:34:20 Do I need to use the functions in the other file, i.e. the one that you wrote? Oct 05 04:34:33 it also looks like you're using a different pca9685 class, not mine Oct 05 04:34:54 hmm. Oct 05 04:35:03 There was two versions. Oct 05 04:35:17 at least it doesn't have the same name (PCA9685 vs Pca9685) Oct 05 04:35:45 Right. I changed Pca to PCA. Oct 05 04:35:46 anyway, python is complaining about line 11 of https://pastebin.com/srK0gziv being nonsense, because that line *is* nonsense Oct 05 04:35:50 and so are lines 12 and 13 Oct 05 04:35:56 why did you do that? Oct 05 04:36:07 I wanted capitalized letters. Oct 05 04:37:04 I thought the error was that hex could not be interpreted as an int? Oct 05 04:37:06 the standard convention in python (and many other languages) is to give classes TitleCased names Oct 05 04:37:14 oh. Oct 05 04:38:01 okay, i will change it back. Oct 05 04:38:02 no the error is that 11 is nonsensical... you're trying to do a comparison between a Pca9685 object and an integer Oct 05 04:38:07 *line 11 Oct 05 04:38:16 oh. Oct 05 04:38:23 my guess would be you were intending to do a comparison on the angle Oct 05 04:38:32 Aw. Oct 05 04:38:32 though I have no idea what you were intending to do after that Oct 05 04:38:55 Just a call to handle one servo at a specific address and then quadruped. Oct 05 04:39:05 >= 90 was presumably also means to be <= 90 Oct 05 04:39:29 anyway, afk Oct 05 04:39:32 No! Oct 05 04:39:45 Thank you. Oct 05 05:33:12 heyy anyone online Oct 05 11:42:17 hello, is it possible to write to a NAND flash that is part of a running system? Oct 05 11:42:49 i'd like to overwrite a file after the boot Oct 05 11:47:42 Hi, I wanted to participate in the google-group https://groups.google.com/g/beagleboard. Is there a chance someone approves my request? Oct 05 11:54:16 OP: that group has been replaced by https://forum.beagleboard.org/ Oct 05 11:55:57 das: ?? why would it not be? Oct 05 12:00:14 Okay, thanks! Oct 05 12:07:58 I'm not sure if it would cause issues or if there are lines the other CPU on the board might be holding Oct 05 12:11:05 Hi again, I'm posting to the forum but would also like to ask you guys whether anyone has experiences in getting the BBB fiber-ready. I found this thread here (where I wanted to answer to) and planing to something similar. Oct 05 12:11:06 https://groups.google.com/g/beagleboard/c/y579ziDQuhU Oct 05 12:11:37 Also I found this part by Microchip, which seems to be intended to be used with the BBB: https://www.microchip.com/en-us/development-tool/EVB-LAN9352 Oct 05 12:11:47 das: wait, what exactly do you mean? Oct 05 12:12:08 das: you mean physically access a NAND chip from two hosts? definite no to that Oct 05 12:14:02 OP: I don't suppose it's an option to just make a custom board based on the osd3358 (which is basically the SoC + ram + pmic of the beaglebone in a package) and add a fiber-capable ethernet phy to that? Oct 05 12:14:57 OP: right, what that person is asking sounds like what I'm suggesting: just replace the ethernet phy Oct 05 12:15:01 and connector Oct 05 12:16:31 OP: I'm not sure why you'd want to attach a switch unless you specifically need multiple ethernet ports, and obviously attaching one via SPI is not going to be very performant Oct 05 12:16:38 zmatt: was afraid so, any litterature on that? Oct 05 12:18:02 das: literature on what? you simply can't have two masters on one bus, and also you can't modify a filesystem while it's mounted on a system since that is pretty much guaranteed to result in corruption (since the data structures cached by the OS won't match the on-disk filesystem anymore) Oct 05 12:18:20 if you want to update the filesystem, do so *via* the running system Oct 05 12:18:30 corruption is the point of the exercise Oct 05 12:19:05 I'd like to exploit a TOCTOU Oct 05 12:19:20 but it can't be a traditional chip-off Oct 05 12:19:38 das: see this kind of information would have been useful to include in your initial answer Oct 05 12:19:43 *initial question Oct 05 12:20:27 das: just to be clear, you're talking about raw NAND here, not eMMC ? Oct 05 12:25:29 das: with raw nand the host will be continuously driving many of the lines, so you'd need to essentially perform a hardware man-in-the-middle attack that briefly disconnects the host from the nand chip while you do your thing, so that would be quite an invasive patch Oct 05 12:28:46 it's eMMC in my case Oct 05 12:30:07 you really need to work on how you ask questions :P Oct 05 12:31:00 sorry, it's one of these "unknown unknowns" Oct 05 12:31:05 type of questioning Oct 05 12:32:29 eMMC is relatively simpler.. isolating the clk and cmd lines from the host while you meddle with the eMMC would suffice Oct 05 12:33:35 or if you can somehow ensure the host doesn't attempt to perform a transfer while you're doing your thing, isolating only the clk line should suffice... all other lines are high-impedance when no transfer is being done Oct 05 12:34:36 regardless, it's still not a trivial thing to do and will require doing a hardware patch Oct 05 12:35:05 would the host trying to access the NAND while it's unavaible because of the switch cause a kernel panic? Oct 05 12:35:19 the eMMC you mean Oct 05 12:35:22 yeah slowly realizing this is out of my reach atm Oct 05 12:35:43 eMMC yes ^^ Oct 05 12:35:59 I'm pretty sure it should retry, dunno how many times Oct 05 12:37:25 do you know of documented examples of such attacks? Oct 05 12:37:56 I'm sure people will have done such things, but I suggest you google it since that's also what I'd have to do Oct 05 12:37:58 zmatt: Sorry was away from computer. Sure, there is no need to use a switch, only thing is, the switch comes with a stack and is intended for use with BBB. I have some experiences with PHYs and simply replacing might not work since different PHYs need different settings, requiring custom firmware?! Oct 05 12:38:07 I think you gave me enough material to be able to research it further anyways Oct 05 12:38:10 thanks a lot :) Oct 05 12:38:20 OP: normally any phy will work, I've never seen or heard of a phy requiring firmware Oct 05 12:38:32 das: yeah maybe "eMMC man in the middle attack" or so Oct 05 12:39:11 zmatt: With firmware I mean firmware inside the BBB to properly configure the PHY. Not all of them have same registers. Oct 05 12:39:21 Especially fiber and copper PHYs differ. Oct 05 12:40:03 OP: the phy is auto-detected normally Oct 05 12:40:32 the only thing you need to configure is what interface is used, i.e. mii vs rmii vs rgmii Oct 05 12:41:25 if you use mii just like the existing phy on the beaglebone then no devicetree change should be needed Oct 05 12:42:03 zmatt, really? Oct 05 12:42:10 OP: https://libera.irclog.whitequark.org/beagle/2022-10-05#1664970003-1664970096; Oct 05 12:42:40 What can I find here? Oct 05 12:42:59 that's a chatlog, since your connection briefly dropped Oct 05 12:43:09 Ah, thanks! Oct 05 12:43:49 So zmatt, it is auto-detected? Oct 05 12:43:51 here's the DT declaration for the ethernet interface on the beaglebone: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am335x-bone-common.dtsi#L414-L432 Oct 05 12:44:28 along with the referenced pinmux blocks Oct 05 12:45:27 So would expect using a different PHY should work out of the box. Or is there a list of supported PHYs? Oct 05 12:45:29 for comparison, here's the BBE which has a gigabit ethernet phy (RGMII): https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am335x-sancloud-bbe.dts#L100-L117 Oct 05 12:48:12 I'd expect any phy to work... the phy interface and essential registers are standardized by IEEE, so a phy-specific linux driver isn't needed unless the phy has bugs that linux needs to work around or you want to use custom phy-specific features Oct 05 12:50:07 if a special driver is needed then linux will normally auto-detect this, unless the phy is very broken and doesn't even report a (correct) phy ID Oct 05 12:54:56 OP: the only compatibility-issue there might be is that when using RGMII, the AM335x can't provide "internal delay" for transmit, so the phy or the pcb needs to provide that delay Oct 05 12:58:48 zmatt: That is quite some nice info. Have been working with PHYs interfaced by microcontrollers, where I had to write drivers myself. Thus had to take care on the register settings. Copper/Fiber differ slightly here and there. Oct 05 12:59:16 linux handles that for you Oct 05 13:01:58 hmm I'm actually a little confused by the BBE dts specifying "rgmii-txid" rather than "rgmii-id" since I don't think the am335x supports internal delay for receive either Oct 05 13:02:54 zmatt One more thing now that I have you here: We are planing to use our custom BBB in a EMI sensible area. Thus want to remove active components from the PCB. Don't need wifi, display, and so on. See any danger in that? Oct 05 13:04:07 sensitive I meant, sorry! Oct 05 13:04:17 the bbb has no wifi, and obviously if you have no need for hdmi you can remove that (like the beaglebone green does) Oct 05 13:05:58 of course if you replace ethernet and remove hdmi then you may be better off just making a custom board consisting of osd335x + eMMC + phy + whatever else you need rather than customizing the BBB design Oct 05 13:07:13 Would it make sense to use the BBGreen as base? Don't know that part yet! Oct 05 13:07:45 not really Oct 05 13:08:30 It is always good to have a reference design, not?! Oct 05 13:08:58 the osd335x is what various later boards like the bbb-wireless are based on, it's a module that contains the am335x, pmic, ddr3 ram, and passives... which combined make up what would otherwise be the most critical and difficult parts of the design Oct 05 13:11:28 Is there a beagle bone reference design available with the osd335x? Oct 05 13:12:49 which also means you may only need a 4-layer pcb (like the beaglebone blue and the pocket beagle) rather than a 6-layer (like the BBB) Oct 05 13:15:14 Do they use the osd335x? Oct 05 13:15:19 I'm not sure how useful a reference design would be, since the only since it would have in common with your desired design is the osd335x and the attached eMMC ... for that part you could look at the beaglebone blue I guess .. though it uses the OSD3358-BAS instead of the newer and more sensible OSD3358-BSM Oct 05 13:15:35 *since the only part it would have in common... Oct 05 13:16:52 As a conclusion: osd335x with fiber-phy and beaglebone blue reference design? Oct 05 13:17:51 if you want to be particularly lazy, there's even a version of the osd335x that also integrates the eMMC... its minimal reference design is very minimal indeed ;) https://twitter.com/pdp7/status/1100349116515827712 Oct 05 13:18:50 but honestly, hooking up eMMC is very simple, simpler than hooking up the phy for sure Oct 05 13:19:22 Sure. Oct 05 13:19:56 "if you want to be particular..." That's cool stuff! Oct 05 13:22:06 so while it may be informative to check the schematic of the beaglebone black wireless and/or beaglebone blue and/or pocket beagle to check for anything that looks applicable, but I'd suggest using the OSD335x-SM (used on the pocket beagle) rather than the original OSD335x (which is used on the blue and black-wireless) Oct 05 13:22:28 You recommend this chip Oct 05 13:22:29 https://www.mouser.de/ProductDetail/Octavo-Systems/OSD3358-512M-BSM?qs=sGAEpiMZZMu3sxpa5v1qriV5vgGpNFXkLvOCoQQjau8%3D Oct 05 13:23:04 they are in short supply. BSM is better to use than BSP. Oct 05 13:24:11 BSP? Oct 05 13:24:54 and isn't everything in short supply? :P Oct 05 13:25:14 Certain a re available but yes! Oct 05 13:25:21 Certain are available but yes! Oct 05 13:25:39 "BSM is better to use than BSP" why? Oct 05 13:26:21 Mouser doesn't know the `BSP` Oct 05 13:26:22 https://www.mouser.de/c/?q=osd3358 Oct 05 13:27:04 I'd recommend the BSM yeah (or ISM if you need wider temperature range) Oct 05 13:29:50 BSM + eMMC + custom Phy (power supply, connectors, ..., ), as a stating point for my design? Oct 05 13:31:09 Would like to go with a reference design still. Which one is using BSM again, the BB-Blue? Oct 05 13:31:54 no, the pocket beagle uses the bsm Oct 05 13:33:38 Ah, okay sorry! Oct 05 13:34:28 Are the schematics open? Oct 05 13:34:42 yep Oct 05 13:35:08 https://github.com/beagleboard/pocketbeagle Oct 05 13:35:17 the pocketbeagle has no eMMC though Oct 05 13:35:24 Where you get all those links from ;-) Oct 05 13:35:31 Via the wikis? Oct 05 13:35:48 I went to https://github.com/beagleboard/ and typed "pocket" into the repository search field Oct 05 13:35:59 ;-) Oct 05 13:36:15 Why simple? Oct 05 13:36:45 Yep but the eMMC I can easily connect or use other design for reference. Oct 05 13:36:59 for eMMC you could look at either the blue or the black-wireless ... those signals are on different balls in the BSM but other than that it's the same thing Oct 05 13:37:28 Oh, perfect. Oct 05 13:38:08 my pins spreadsheet includes for each signal the ball on both AM335x packages (ZCE and ZCZ) and all three OSD335x variants: https://goo.gl/Jkcg0w Oct 05 13:38:57 Nice. Can I ask what position you have in the project? Oct 05 13:39:09 none Oct 05 13:39:30 I'm just a beaglebone user Oct 05 13:39:42 Sure ;-) Oct 05 13:58:34 Hi. Recently we bought 2 Beagle bone Black but after some test recently it not working anymore Oct 05 13:58:51 the pwr led is flickering and the other led is off Oct 05 13:59:16 flickering as in, a brief flash of light when you connect power? Oct 05 13:59:25 yes Oct 05 13:59:42 that suggests you damaged the hardware, e.g. due to exposing I/O to overvoltage Oct 05 14:01:05 we measure voltage vdd_3v3b at connector P9 and sys-5v at connector P9 but all of these are 0 Oct 05 14:01:27 so can I do to fix it Oct 05 14:03:07 or at least we can use it in short time. because we need it for next project but order and delivery these other is too late Oct 05 14:08:31 Hi. Recently we bought 2 Beagle bone Black but after some test recently it not working anymore Oct 05 14:08:53 the pwr led is flickering and the other led is off Oct 05 14:09:06 how can I fix it Oct 05 14:52:08 Freya13: don't send private messages Oct 05 14:52:17 like I said, it indicates you damaged the board Oct 05 14:52:46 I'm sorry Oct 05 14:52:51 there is no fix, the board is dead Oct 05 14:52:58 So I can not fix it Oct 05 14:53:49 specifically, it generally indicates that an I/O cell of the am335x has been damaged (typically due to overvoltage), resulting in internal damage in the chip that results in a power supply line being shorted to ground (inside the chip) Oct 05 14:54:07 the power management IC detects this short-circuit and immediately power off again, this is what's causing a brief flash of the power led Oct 05 15:05:01 thank you so much. I got it **** ENDING LOGGING AT Thu Oct 06 02:59:56 2022