<set_>
that is the old source. i changed it to handle hex.
<set_>
Instead of bytes, i am using hex.
<zmatt>
that phrase doesn't make sense
<set_>
Oh.
<set_>
Dang it!
<zmatt>
like, I can't even begin to guess what you could even mean by saying that
<set_>
I was using an address.
<set_>
0b111111 and now I am using 0x34.
<zmatt>
okay, and?
<set_>
I received an ` remote error ` on the 0b111111 address but I received an error about the paste during the hex address.
<zmatt>
that error is not occurring in the code you pastebinned
<set_>
i know
<set_>
Let me get that source.
<set_>
Brb.
<zmatt>
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)
<das>
I'm not sure if it would cause issues or if there are lines the other CPU on the board might be holding
<OP>
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.
<zmatt>
das: you mean physically access a NAND chip from two hosts? definite no to that
<zmatt>
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?
<zmatt>
OP: right, what that person is asking sounds like what I'm suggesting: just replace the ethernet phy
<zmatt>
and connector
<zmatt>
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
<das>
zmatt: was afraid so, any litterature on that?
<zmatt>
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)
<zmatt>
if you want to update the filesystem, do so *via* the running system
<das>
corruption is the point of the exercise
<das>
I'd like to exploit a TOCTOU
<das>
but it can't be a traditional chip-off
<zmatt>
das: see this kind of information would have been useful to include in your initial answer
<zmatt>
*initial question
<zmatt>
das: just to be clear, you're talking about raw NAND here, not eMMC ?
<zmatt>
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
<das>
it's eMMC in my case
<zmatt>
you really need to work on how you ask questions :P
<das>
sorry, it's one of these "unknown unknowns"
<das>
type of questioning
<zmatt>
eMMC is relatively simpler.. isolating the clk and cmd lines from the host while you meddle with the eMMC would suffice
<zmatt>
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
<zmatt>
regardless, it's still not a trivial thing to do and will require doing a hardware patch
<das>
would the host trying to access the NAND while it's unavaible because of the switch cause a kernel panic?
<zmatt>
the eMMC you mean
<das>
yeah slowly realizing this is out of my reach atm
<das>
eMMC yes ^^
<zmatt>
I'm pretty sure it should retry, dunno how many times
<das>
do you know of documented examples of such attacks?
<zmatt>
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
<OP>
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?!
<das>
I think you gave me enough material to be able to research it further anyways
<das>
thanks a lot :)
<zmatt>
OP: normally any phy will work, I've never seen or heard of a phy requiring firmware
<zmatt>
das: yeah maybe "eMMC man in the middle attack" or so
<OP>
zmatt: With firmware I mean firmware inside the BBB to properly configure the PHY. Not all of them have same registers.
<OP>
Especially fiber and copper PHYs differ.
<zmatt>
OP: the phy is auto-detected normally
OP has quit [Quit: Client closed]
<zmatt>
the only thing you need to configure is what interface is used, i.e. mii vs rmii vs rgmii
<zmatt>
if you use mii just like the existing phy on the beaglebone then no devicetree change should be needed
<zmatt>
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
<zmatt>
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
<zmatt>
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
otisolsen70 has quit [Quit: Leaving]
<OP>
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.
<zmatt>
linux handles that for you
<zmatt>
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
<OP>
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?
<OP>
sensitive I meant, sorry!
<zmatt>
the bbb has no wifi, and obviously if you have no need for hdmi you can remove that (like the beaglebone green does)
<zmatt>
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
<OP>
Would it make sense to use the BBGreen as base? Don't know that part yet!
<zmatt>
not really
<OP>
It is always good to have a reference design, not?!
<zmatt>
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
<OP>
Is there a beagle bone reference design available with the osd335x?
<zmatt>
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)
<OP>
Do they use the osd335x?
<zmatt>
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
<zmatt>
*since the only part it would have in common...
<OP>
As a conclusion: osd335x with fiber-phy and beaglebone blue reference design?
<zmatt>
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
<zmatt>
but honestly, hooking up eMMC is very simple, simpler than hooking up the phy for sure
<OP>
Sure.
<OP>
"if you want to be particular..." That's cool stuff!
<zmatt>
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)
<OP>
Yep but the eMMC I can easily connect or use other design for reference.
<zmatt>
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
<OP>
Oh, perfect.
<zmatt>
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
<OP>
Nice. Can I ask what position you have in the project?
<zmatt>
none
<zmatt>
I'm just a beaglebone user
<OP>
Sure ;-)
OP has quit [Quit: Client closed]
Guest96 has joined #beagle
Guest96 is now known as OP
Guest76 has joined #beagle
<Guest76>
Hi. Recently we bought 2 Beagle bone Black but after some test recently it not working anymore
<Guest76>
the pwr led is flickering and the other led is off
<zmatt>
flickering as in, a brief flash of light when you connect power?
<Guest76>
yes
<zmatt>
that suggests you damaged the hardware, e.g. due to exposing I/O to overvoltage
<Guest76>
we measure voltage vdd_3v3b at connector P9 and sys-5v at connector P9 but all of these are 0
<Guest76>
so can I do to fix it
PhotoJim has joined #beagle
<Guest76>
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
Guest76 has quit [Quit: Client closed]
Freya29 has joined #beagle
<Freya29>
Hi. Recently we bought 2 Beagle bone Black but after some test recently it not working anymore
<Freya29>
the pwr led is flickering and the other led is off
<Freya29>
how can I fix it
Freya29 has quit [Quit: Ping timeout (120 seconds)]
Freya13 has joined #beagle
<zmatt>
Freya13: don't send private messages
<zmatt>
like I said, it indicates you damaged the board
<Freya13>
I'm sorry
<zmatt>
there is no fix, the board is dead
<Freya13>
So I can not fix it
<zmatt>
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)
<zmatt>
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
ikarso has quit [Quit: Connection closed for inactivity]
<Freya13>
thank you so much. I got it
Freya13 has quit [Quit: Client closed]
rob_w has quit [Remote host closed the connection]
Guest28 has joined #beagle
Guest28 has quit [Client Quit]
das has quit [Remote host closed the connection]
OP has quit [Quit: Client closed]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
lucascastro has joined #beagle
vagrantc has joined #beagle
lucascastro has quit [Quit: Leaving]
ft has joined #beagle
Guest11 has joined #beagle
Guest11 has quit [Client Quit]
otisolsen70 has joined #beagle
vagrantc has quit [Quit: leaving]
vagrantc has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981_b has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
otisolsen70 has quit [Quit: Leaving]
brook has quit [Remote host closed the connection]