RPi Zero 1.3 USB g_ether not working

[Ernst]

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.

[notyou]

… 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.

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?

I meant Broadcom not Ti. Was confusing a couple of different projects in my head.

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.

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?

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.

[notyou]

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

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

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

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

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.

[rpdom]

There isn't anything written to the SoC: it has no flash. All the storage is on SD card.

If your statement is true, the SoC has no flash what generates the USB product string "BCM2708 Boot"?

The code in the boot ROM inside the SoC. ROM != flash. It can't be updated without a new chip being built.

[nonefaken3]

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

[notyou]

There isn't anything written to the SoC: it has no flash. All the storage is on SD card.

If your statement is true, the SoC has no flash what generates the USB product string "BCM2708 Boot"?

The code in the boot ROM inside the SoC. ROM != flash. It can't be updated without a new chip being built.

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.

[notyou]

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

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).

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.

[jamesh]

If your statement is true, the SoC has no flash what generates the USB product string "BCM2708 Boot"?

The code in the boot ROM inside the SoC. ROM != flash. It can't be updated without a new chip being built.

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.

A warning to others - this sort of post gets you banned. For a week in this case.

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.

[scruss]

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)

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.

[YeahWell]

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.

A warning to others - this sort of post gets you banned. For a week in this case.

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.

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.

[rpdom]

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)

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.

All my current Zeros are that batch or older. I've just ordered a new one to test this.

[DougieLawson]

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.

NAND flash is non-volatile, erasable, programmable and alterable until wear leveling kills it.

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.

[scruss]

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.

[YeahWell]

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.

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).

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.

[rpdom]

There is 32k of boot rom

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).

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 waste spare to follow this up.

[jamesh]

Too fighty, too many people not reading/understanding what is written.

Closing.

[jamesh]

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.

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).

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.

And just to ENSURE that people don't get the wrong idea.

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.