I am not sure that I understood the basic conditions and the results.
I did a few tests myself and I did find something interesting that I am currently unable to explain. I created a SD card with Jessie Light dated 2017-01-11. I edited cmdline.txt to add "modules-load=dwc2,g_ether" immediately after rootwait, and config.txt to add the line "dtoverlay=dwc2".
This change did not work while testing with four different Pi zeroes with USB connection to a Windows 7 using putty.
But I did notice something interesting, when doing a ping from Windows 7 I did get a response, and a second attempt with putty did get a reply from the Pi zero and I was able to connect.
Re: RPi Zero 1.3 USB g_ether not working
The road to insanity is paved with static ip addresses
Re: RPi Zero 1.3 USB g_ether not working
I meant Broadcom not Ti. Was confusing a couple of different projects in my head.scruss wrote:There isn't anything written to the SoC: it has no flash. All the storage is on SD card. What TI chips are on the Zero?notyou wrote:… I have not been able to locate anything saying that the main chip has any code that gets flashed to it at any point. With the open source nature of the project you would think that if it existed it would be published. So it is probably from Ti.
If your statement is true, the SoC has no flash what generates the USB product string "BCM2708 Boot"? Remember you *only* see that with the SD card removed prior to booting it.
Yes, there are 2 jacks. One is for power only the other is for USB and optionally power. I use the USB one for USB and the power one for power. I am unsure why that confuses you.Talking of SD cards, are you sure that yours isn't corrupted? It can happen distressingly easily with Raspberry Pis. Also, I'm a little confused about your sequence of starting the Zero up: you start it connected to a keyboard and HDMI, then disconnect the USB (with some other power supply keeping the Zero running?) and plug the Zero into a desktop host with no other USB attached?
Re: RPi Zero 1.3 USB g_ether not working
So I am getting a replacement, even the distributor agrees that the unit is defective. Bonus I appear to be able to keep the broken one (probably more trouble than its worth to return ship a $5 unit anyway).
Here is my work around.
Bust out the bus pirate (sparkfun v3 edition).
Black wire to pin 6 (gnd)
Brown wire to pin 8 (TxD)
Orange wire to pin 10 (RxD)
Set the bus pirate to do serial->ttl bridging - remember folks its 3.3v TTL so just wiring up a DB9 and jamming it into a usb/serial adapter wont work (commands for my bus pirate firmware, there are different versions so watch out "m 3 9 1 1 1 2 (0) (1)") The final macro is to do a "transparent bridge"
Alternatively you can use a (usb) serial->ttl cable like adafruit and others sell for cheap but I had the bus pirate and couldnt find my serial-ttl cable. Plus now I can say arrr and it has more blinky lights than a mere cable.
Set up ppp on the RPi
make sure that console=serial0 is not in your /boot/cmdline.txt file (or reference to ttyACM0)
cheap method to ensure it always works - edit /etc/rc.local to call a script which basically just does
Now anytime the RPi is powered up (at the end of the boot sequence) it will try to do serial PPP via the UART.
On the desktop
instant painfully slow networking. Its like a nostalgic flashback to when ISDN was all the rage and DSL didnt exist. You should be able to go much faster than 115.2k but I have to reset the bus pirate to change it so I left it for now. Cable length and RFI are going to be some big killers, clock rate is also a parameter that likely has to be tuned a bit to crank out more speed. 115.2k is safe, reliable and should work with just about anything out there but then so should 4 times that speed.
Here is my work around.
Bust out the bus pirate (sparkfun v3 edition).
Black wire to pin 6 (gnd)
Brown wire to pin 8 (TxD)
Orange wire to pin 10 (RxD)
Set the bus pirate to do serial->ttl bridging - remember folks its 3.3v TTL so just wiring up a DB9 and jamming it into a usb/serial adapter wont work (commands for my bus pirate firmware, there are different versions so watch out "m 3 9 1 1 1 2 (0) (1)") The final macro is to do a "transparent bridge"
Alternatively you can use a (usb) serial->ttl cable like adafruit and others sell for cheap but I had the bus pirate and couldnt find my serial-ttl cable. Plus now I can say arrr and it has more blinky lights than a mere cable.
Set up ppp on the RPi
make sure that console=serial0 is not in your /boot/cmdline.txt file (or reference to ttyACM0)
cheap method to ensure it always works - edit /etc/rc.local to call a script which basically just does
Code: Select all
stty -F /dev/ttyAMA0 raw
stty -F /dev/ttyAMA0 -a
/usr/sbin/pppd /dev/ttyAMA0 115200 10.0.1.2:10.0.1.1 noauth local debug dump defaultroute nocrtscts persist maxfail 0 holdoff 1
On the desktop
Code: Select all
sudo stty -F /dev/ttyUSB0 raw
sudo pppd /dev/ttyUSB0 115200 10.0.1.1:10.0.1.2 proxyarp local noauth debug nodetach dump nocrtscts passive persist maxfail 0 holdoff 1
# lets set up NAT quick and dirty so the RPi can get out to the intarwebz
echo "1" | sudo tee -a /proc/sys/net/ipv4/ip_forward
sudo modprobe ip_tables
sudo modprobe ip_conntrack
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Re: RPi Zero 1.3 USB g_ether not working
The code in the boot ROM inside the SoC. ROM != flash. It can't be updated without a new chip being built.notyou wrote:If your statement is true, the SoC has no flash what generates the USB product string "BCM2708 Boot"?scruss wrote:There isn't anything written to the SoC: it has no flash. All the storage is on SD card.
-
- Posts: 5
- Joined: Sat Feb 18, 2017 10:54 pm
Re: RPi Zero 1.3 USB g_ether not working
Hello scruss,
i have tested with 3 different power adapters (1,5A, 2A and 2A), 3 cables, 2 different SD cards (SAmsung and Makespot) and reinstalled OS from scratch on both, 2 different model/age computers (desktop and laptop). And as soon as you get "good" RPi zero, everything works in any combination. The "bad" works, except g_ether and similar things.
The "bad" RPi zero: ELPIDA B4432BBA-1D-F, 16270R06600
The "good" RPi zero: ELPIDA B4432BBA-1D-F, 15470R05300 (i hope i was able to read it corrent, as had heatsink on it)
Regards,
Olegas
i have tested with 3 different power adapters (1,5A, 2A and 2A), 3 cables, 2 different SD cards (SAmsung and Makespot) and reinstalled OS from scratch on both, 2 different model/age computers (desktop and laptop). And as soon as you get "good" RPi zero, everything works in any combination. The "bad" works, except g_ether and similar things.
The "bad" RPi zero: ELPIDA B4432BBA-1D-F, 16270R06600
The "good" RPi zero: ELPIDA B4432BBA-1D-F, 15470R05300 (i hope i was able to read it corrent, as had heatsink on it)
Regards,
Olegas
Re: RPi Zero 1.3 USB g_ether not working
Ok sparky if you say so.rpdom wrote:The code in the boot ROM inside the SoC. ROM != flash. It can't be updated without a new chip being built.notyou wrote:If your statement is true, the SoC has no flash what generates the USB product string "BCM2708 Boot"?scruss wrote:There isn't anything written to the SoC: it has no flash. All the storage is on SD card.
BTW dont be so quick to correct someone (especially when they didnt exactly say what you are correcting them on). EEPROMs are eraseable programmable ROMs. ho hum its so tedious playing with children on the internet that have no other desire than to prove how smart they are.
In other words ROM may = flash or it may not, and ROM may be updated without building a new chip or it may not. Going back to the 90s it started to become more common for microcode to be updatable.
My original comment was about microcode on the chip, I intentionally left it ambiguous as to whether or not it was updateable. The flash comment was what was thrown back to try to correct me that there is no microcode. Ya know cause someone wanted to prove they were smarter. Then you come along wanting to prove you were smarter and tried to correct that.
If you are going to try to play that game at least be correct in your statement. Dont be pedantic and wrong it just makes it look like you were picked on as a child and now turned to the internet to try to get even with all those kids but really in your heart you can never get even.
This also had nothing to do with the original thread showing just how compulsive the behavior is.
Re: RPi Zero 1.3 USB g_ether not working
That would almost suggest some internal change, possibly to the "non existent" storage on the chip that gets flashed at some point. (sorry couldnt resist but at least its somewhat on topic).nonefaken3 wrote:Hello scruss,
i have tested with 3 different power adapters (1,5A, 2A and 2A), 3 cables, 2 different SD cards (SAmsung and Makespot) and reinstalled OS from scratch on both, 2 different model/age computers (desktop and laptop). And as soon as you get "good" RPi zero, everything works in any combination. The "bad" works, except g_ether and similar things.
The "bad" RPi zero: ELPIDA B4432BBA-1D-F, 16270R06600
The "good" RPi zero: ELPIDA B4432BBA-1D-F, 15470R05300 (i hope i was able to read it corrent, as had heatsink on it)
Regards,
Olegas
Mine is also an Elpida 16250R01500 so very close in series number to your bad one. It might be that they just started churning out bad chips and no one noticed for a while.
Re: RPi Zero 1.3 USB g_ether not working
A warning to others - this sort of post gets you banned. For a week in this case.notyou wrote:Ok sparky if you say so.rpdom wrote:The code in the boot ROM inside the SoC. ROM != flash. It can't be updated without a new chip being built.notyou wrote: If your statement is true, the SoC has no flash what generates the USB product string "BCM2708 Boot"?
BTW dont be so quick to correct someone (especially when they didnt exactly say what you are correcting them on). EEPROMs are eraseable programmable ROMs. ho hum its so tedious playing with children on the internet that have no other desire than to prove how smart they are.
In other words ROM may = flash or it may not, and ROM may be updated without building a new chip or it may not. Going back to the 90s it started to become more common for microcode to be updatable.
My original comment was about microcode on the chip, I intentionally left it ambiguous as to whether or not it was updateable. The flash comment was what was thrown back to try to correct me that there is no microcode. Ya know cause someone wanted to prove they were smarter. Then you come along wanting to prove you were smarter and tried to correct that.
If you are going to try to play that game at least be correct in your statement. Dont be pedantic and wrong it just makes it look like you were picked on as a child and now turned to the internet to try to get even with all those kids but really in your heart you can never get even.
This also had nothing to do with the original thread showing just how compulsive the behavior is.
Also, the post is fairly wrong on a number of points.
The SoC has no flash - it has a small amount of permanent ROM for the bootcode. It also has a small amount of OTP memory.
So, if you plan on being abusive to other forums members, at least get your facts right first.
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.
Working in the Applications Team.
Re: RPi Zero 1.3 USB g_ether not working
The one I have that works fine with g_ether has batch # 16200R01400 on the RAM. I have about five more of almost the same age, and one about six months older. If this is a very recent problem, I won't be able to verify it, as all of mine were made before 2017.nonefaken3 wrote:The "bad" RPi zero: ELPIDA B4432BBA-1D-F, 16270R06600
The "good" RPi zero: ELPIDA B4432BBA-1D-F, 15470R05300 (i hope i was able to read it corrent, as had heatsink on it)
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him
Pronouns: he/him
Re: RPi Zero 1.3 USB g_ether not working
How is the OTP memory programmed? Is it flashed?jamesh wrote:A warning to others - this sort of post gets you banned. For a week in this case.notyou wrote: Ok sparky if you say so.
BTW dont be so quick to correct someone (especially when they didnt exactly say what you are correcting them on). EEPROMs are eraseable programmable ROMs. ho hum its so tedious playing with children on the internet that have no other desire than to prove how smart they are.
In other words ROM may = flash or it may not, and ROM may be updated without building a new chip or it may not. Going back to the 90s it started to become more common for microcode to be updatable.
My original comment was about microcode on the chip, I intentionally left it ambiguous as to whether or not it was updateable. The flash comment was what was thrown back to try to correct me that there is no microcode. Ya know cause someone wanted to prove they were smarter. Then you come along wanting to prove you were smarter and tried to correct that.
If you are going to try to play that game at least be correct in your statement. Dont be pedantic and wrong it just makes it look like you were picked on as a child and now turned to the internet to try to get even with all those kids but really in your heart you can never get even.
This also had nothing to do with the original thread showing just how compulsive the behavior is.
Also, the post is fairly wrong on a number of points.
The SoC has no flash - it has a small amount of permanent ROM for the bootcode. It also has a small amount of OTP memory.
So, if you plan on being abusive to other forums members, at least get your facts right first.
Also in what you quoted he said "In other words ROM may = flash or it may not, and ROM may be updated without building a new chip or it may not." Is that also wrong?
That seems to be the crux of the complaint.
Re: RPi Zero 1.3 USB g_ether not working
All my current Zeros are that batch or older. I've just ordered a new one to test this.scruss wrote:The one I have that works fine with g_ether has batch # 16200R01400 on the RAM. I have about five more of almost the same age, and one about six months older. If this is a very recent problem, I won't be able to verify it, as all of mine were made before 2017.nonefaken3 wrote:The "bad" RPi zero: ELPIDA B4432BBA-1D-F, 16270R06600
The "good" RPi zero: ELPIDA B4432BBA-1D-F, 15470R05300 (i hope i was able to read it corrent, as had heatsink on it)
- DougieLawson
- Posts: 42142
- Joined: Sun Jun 16, 2013 11:19 pm
- Location: A small cave in deepest darkest Basingstoke, UK
Re: RPi Zero 1.3 USB g_ether not working
NAND flash is non-volatile, erasable, programmable and alterable until wear leveling kills it.YeahWell wrote: How is the OTP memory programmed? Is it flashed?
Also in what you quoted he said "In other words ROM may = flash or it may not, and ROM may be updated without building a new chip or it may not." Is that also wrong?
That seems to be the crux of the complaint.
OTP "burns" a link out so that the memory will always read as a HIGH (binary 0b1) digit when the OTP is written. Once that burn-out is done there's no way back. It's definitely NOT NAND flash memory, it's an entirely different formation on the silicon.
Languages using left-hand whitespace for syntax are ridiculous
DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.
The use of crystal balls and mind reading is prohibited.
DMs sent on https://twitter.com/DougieLawson or LinkedIn will be answered next month.
Fake doctors - are all on my foes list.
The use of crystal balls and mind reading is prohibited.
Re: RPi Zero 1.3 USB g_ether not working
It's getting a little too fighty in here — let's stick to the topic. There's nothing saved on a Raspberry Pi Zero board that could cause the hardware problem the OP described.
Anyone else notice the reg dates and activity of the main contenders here? Hmm.
Anyone else notice the reg dates and activity of the main contenders here? Hmm.
‘Remember the Golden Rule of Selling: “Do not resort to violence.”’ — McGlashan.
Pronouns: he/him
Pronouns: he/him
Re: RPi Zero 1.3 USB g_ether not working
That remains to be unproved. There is 32k of boot rom, which I plan on comparing a working vs a non working assuming I get some volunteers to dump the boot rom (need a serial to ttl cable, I already have software).scruss wrote:It's getting a little too fighty in here — let's stick to the topic. There's nothing saved on a Raspberry Pi Zero board that could cause the hardware problem the OP described.
I also plan on dumping the 512 bytes of OTP, 2k of bootrom ram, and 14k of not quite sure between the bootrom ram and the bootrom ctl register which I think is related to the bootrom.
If its all identical then its not suspect, however if something changed then it is a contender.
The other option is a design or QC problem with the pi.
Re: RPi Zero 1.3 USB g_ether not working
Which as you should know by now is hard-coded into the BCM2835 chip. It can't get changed without a very significant sum of money being spent to redesign the chip and that is very unlikely when it is no longer the main chip being used on the Pi range ( BCM2836 for Pi 2 is now being dropped in favour of the BCM2837 for Pi2B, Pi3B, Pi3A and CM3).YeahWell wrote:There is 32k of boot rom
The OTP memory is the only bit that can get changed easily. Maybe something in there, coupled with a change to the bootcode/"firmware" on the SD card? Well, my new Zero should arrive today or tomorrow, I'll see if I've got any time to
Re: RPi Zero 1.3 USB g_ether not working
Too fighty, too many people not reading/understanding what is written.
Closing.
Closing.
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.
Working in the Applications Team.
Re: RPi Zero 1.3 USB g_ether not working
And just to ENSURE that people don't get the wrong idea.YeahWell wrote:That remains to be unproved. There is 32k of boot rom, which I plan on comparing a working vs a non working assuming I get some volunteers to dump the boot rom (need a serial to ttl cable, I already have software).scruss wrote:It's getting a little too fighty in here — let's stick to the topic. There's nothing saved on a Raspberry Pi Zero board that could cause the hardware problem the OP described.
I also plan on dumping the 512 bytes of OTP, 2k of bootrom ram, and 14k of not quite sure between the bootrom ram and the bootrom ctl register which I think is related to the bootrom.
If its all identical then its not suspect, however if something changed then it is a contender.
The other option is a design or QC problem with the pi.
There is hardcoded boot ROM data in the SoC, this is hardcoded as the mask level, so is therefor very very unchangeable unless you design a new mask ($1M) and build new chips with that mask. This, AFAIK, is not readable from the ARM, and is in fact VC4 code, not ARM code.
On startup, this boot code reads bootcode.bin from the SD card, this is the second stage bootloader (/boot/bootcode.bin), which will in turn load /boot/start.elf on the videocore, then starts up the kernel (/boot/kernel7.img on the Pi3)
The are some bytes of OTP memory, OTP stands for one time programmable - these bits are permanent once set as they blow fuses in the clip. These are BITs of data, not executable code. Note, there are NOT 512 bytes of this.
That's it.
The SD card which contains the bootcode.bin, start.elf file and the kernel is the area that can be changed. Rewriting a SD card will ensure this data is factory fresh.
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.
Working in the Applications Team.