Hello Gerald,
greetings from Italy, here i bough two beaglebone black from different reseller, but with the same Rev. A5C.
when ive done an image from the first, with the working network adapter, and flashed to the second, this board’s network adapter dont works never, but if i put a different image it works so i think is a driver problem caused by a different hardware installed.
Here it follow the dmesgs:
This one is the working :: http://pastebin.com/Xyid16FK
This one is not working :: http://pastebin.com/XruPQvVy
My question is why the same board with different HARDWARE??
ps=i spend a day debugging this plus i had to buy the micro hdmi cable to discover this…
"bone20" Yuck... Why do people still use an image that hasn't seen any
updates since June 9th..
Please "at-least" retest with:
http://elinux.org/BeagleBoardUbuntu#eMMC:_BeagleBone_Black
http://elinux.org/BeagleBoardDebian#eMMC:_BeagleBone_Black
Regards,
It is not different hardware. There have been no HW changes ever that affect this feature. Feel free to read all the changes of the HW on the support Wiki.
There may be some differences in the stability of the driver. Or there could be HW issue on the board. There are other variables as well as discussed on teh support Wiki affecting network adapters. I assume you have checked there. Correct?
But to say they are different HW is not a true statement and that we are marking boards as 5C when they are not is also not true,
Gerald
Because, the HW is different.
Gerald
“bone20” Yuck… Why do people still use an image that hasn’t seen any
updates since June 9th…
Was June when i started working on this “beautiful” board, and now from i understood there isnt a way to make any in place upgrate, i cannot reflash and starting all again…
Could you answer to my question, please?
—>>> Why the hardware is different? <<<—
It is not different. Did you read the Wiki?
Revision A5C (Production Version)
Production had some fallout of boards when running the HDMI tests in the previous production run. Resistor values were tweaked to improve the test results.
No changes in features or operation of the board.
- Changed R46,R47,R48 to a 0 ohm.
- Changed R45 to a 22 Ohm.
Revision A5B (Previous Production Version)
- Updated the PCB to incorporate the modification that was being done on Rev A5A. There is NO DIFFERENCE AT ALL in functionality between REV A5A and REV A5B.
- Made the LEDs dimmer for those that could not sleep due to the brightness of the LEDs.
Revision A5A (Old Production Version)
- Boards are built using the XAM3359AZCZ100 processor.
- PCB Change…LCD noise issue was resolved by adding 47pf bypass caps on some of the LCD signals.
- PCB Change…Added access to four battery charger signals on the TPS65217 (TS=Temperature Sense, BAT=Battery connection,BATT_SENSE=Battery voltage pin, GND=Ground). Pins are not populated but the four signals are in a 2x2 .1x.1 spacing.
- PCB Change…Added a power button which allows for wake up, power down, and sleep options. It also provides the ability to alert the processor before powering down to provide an orderly shutdown. It is expected that SW will be used in conjunction with the switch to control the various power modes and transitions from one to the other. By holding the button down for 8 seconds, it will force a power down of the board.
- Added a 100K pull down resistor from J1 pin 1 to J1 pin 4 to fix the unterminated serial port issue.
Gerald
It isn't... But the usb bus is known to be "finicky"... In some cases
you can add a simple short usb cable extension and it magically works
where it failed previously on a board..
Regards,
nope, i did a search on the web but i dont found nothing close to this issue.
please, could you provide a direct link?
Yes this is the change log of the board, ive the same Rev. so it’s useless… IMHO
As explained on the Wiki, that is because the short dongles have their RF patterns interfere with by the board. They have no antennae to speak of. Putting the board on standoffs can also help. Putting it on a cable gets it away from the board and the copper planes of the board.
Every board has a unique RF signature that can interfere with these cheap USB dongles. We put the same chips on the board.
Gerald
Who spoken about USB? ive got the issue on the native lan eth adapter… i cannot understand
Ahh... Duh.. You should "really" lead with that next time... I read
both dmesg logs and the only issue was usb babble warnings..
When you copied the image from board 1 to board 2, did you tweak
"udev" or /etc/network/interfaces, probally not... As each board has
a unique mac address, it's probally eth1..
If you want the same image to work on all boards, just add this very
simple udev rule ..
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Networking:UsingasharedSDcardwithMultipleBeagleBone
Regards,
So this is an Ethernet issue? Network adapter usually refers to adapting form one interface, USB, to another.
So, if this is an Ethernet issue, maybe one of the distributors shipped you a bad board, maybe one that was returned by someone else. Or maybe it is bad and has an issue, or maybe has been damged.
Just request an RMA and we will get it fixed.
Gerald
Yes, each board has a unique MAC address.
Gerald
Maybe we are not understanding well…
Ive no usb device attached on them, im forced to attach the usb storage only to get out the dmesg file from the no working network adapter.
Is clear now?
Shazbot!!! we cannot speak about different things!!! i dont use any usb dongle, i mean only the network adapter soldered to the board, the original one!
Many thanks but , it works on debian too?
ps=im not using a sd, im flashing the eMMC with the same image