where can I buy a k9f1g08u0d flash ic?

charliebrown

Inactive User
Joined
Jan 22, 2012
Messages
10
Reaction score
4
I've bought from china twice and on both occasions they sent k9f1g08u0E which is pin compatible but does not work.

flsahed the blank k9f1g08u0E using Broadcom studio and the box boots boot the CFE is unable to flash the image (or does flash but the boot code is not right because during boot it craps out). The USB flash also completes but same problem, cant get a full working box.

I'm 99% sure its because the E variant has slightly different (slower) timings to the D variant as well as there being 4 instructions in the embedded flash controller of the k9f1g08u0E that are different to a k9f1g08u0d.

So can someone save my bacon and tell me where I can buy a k9f1g08u0d chip from?. The chinese sellers always say k9f1g08u0D/k9f1g08u0E and end up sending k9f1g08u0E because thats all thats current :(

Original Vu UNO reduced to a useless brick due to a few quid chip! :Angryfire
 
Here's some information including an alternative part.

Code:
You don't have permission to view the code content. Log in or register now.

Looks like the D revision is obsolete.

Maybe something is reading the ID and finds it is different. Some timings are different but it probably wouldn't affect much, the E revision can only take one partial page write, in case something is using that, before an erase is required so they have possibly changed to a Multi-Level Cell (MLC).
 
Here's some information including an alternative part.

Code:
You don't have permission to view the code content. Log in or register now.

Looks like the D revision is obsolete.

Maybe something is reading the ID and finds it is different. Some timings are different but it probably wouldn't affect much, the E revision can only take one partial page write, in case something is using that, before an erase is required so they have possibly changed to a Multi-Level Cell (MLC).


Yeah I gathered as much (it being obsolete), which is a SERIOUS pain in the bum :(

I've resorted to using broadcom studio to programming the chip with a full dump, and dumping out what i write and its 100% the same so I know using a Cypress JTAG board I can program the chip.

Seems if you are in the same position as me where your nand goes bad and there are no free blocks left so relocation is a non-starter, you're stuffed. Box is a brick and even IF you can get a PIN compatible TSOP48 you're still SOL.

Feeling gutting knowing I'll have to bin this box and its a genuine box too, which makes it all the harder to part with the box.

If anyone has any other ideas about how I can recover this box I'm all ears. Chip erases fine and flashes an image via USB or Broadcom studio 3 but when it boots it craps out during the boot. I'm pretty certain an exact part match therefore is required the "E" variant does not work.

I suspect as per that link you posted, the devs of the CFE are using fixed timings rather than the better/correct way like in that PDF of waiting based on results of an API call to write/clear/erase etc
 
Last edited:
I wouldn't have thought using it for firmware would have wore it out that quickly. Unless they don't bother with wear levelling and have been hammering the same addresses.

Out of interest,is there a separate bootloader anywhere in there?
 
The problem is its not Just firmware... for most users, and me all the other stuff is written in the nand too. By that I mean anything in /var or any other part of the filesystem which gets mapped to MD0.

Ideally users should either install multiboot (from what i've read about it) thereby using the onboard as only a starter and anything that get changed gets changed on your second image on a USB flash stick (and therefore replaceable device).

Or map commonly used dirs to a USB stick so mount /var to a usb stick or something via fstab on the box.

Storing stuff that changes on the nand seems a bad idea but if you have no external storage setup there is no other place, so I understand why vu (and every other STB) use a partition on the nand to preserve stuff between reboots.

Perhaps I just got a bad nand with very few spare blocks and it was down to that. Who knows :(

I have bought a new box (solo) again genuine, even though I know clones are cheaper. I'd just love to recover this box, bought a hot air rework, bought the Cypress board, but to no avail.

As for a bootloader, I'm pretty sure its all in the nand, I did have 2 full dumps, one that was partially overwritten (this from the original nand on the box that crapped out mid flash), and one from another uno thats also genuine that belongs to a friend.

Programing either didnt work, both programmed to a virgin chip allow the box to boot (which is good), and the box accepts and programs an image from USB but the box does not fully boot. I'm missing "something", and the guys in the official forums are being tight lipped about what. The assumption that the chip is the issue in that its not 100% compatible is all mine, but it seems a reasonable idea because I found a link of another guy who used the E part in his D based project and had issues, it wasn't a drop in replacement as hoped.

Shame there isnt a drop in TSOP 48 thats available to purchase, or some device that can be purchased to salvage out the flash ic and fixing the box.

If you're curious, this is the serial output with the new nand installed with after flashing via USB a image from the usual places (vix/etc).


Copyright (C) Broadcom Corporation.

writing vfd
New NAND flash at 18000000 offset 00000000 size 116736KB
New NAND flash at 18000000 offset 07200000 size 4096KB
New NAND flash at 18000000 offset 07600000 size 4096KB
New NAND flash at 18000000 offset 07A00000 size 2048KB
New NAND flash at 18000000 offset 07C00000 size 1024KB
New NAND flash at 18000000 offset 07D00000 size 512KB
New NAND flash at 18000000 offset 07D80000 size 512KB
New NAND flash at 18000000 offset 07E00000 size 1024KB
New NAND flash at 18000000 offset 07F00000 size 1024KB

DDR Freq: 396MHz
CPU speed: 405MHz
Memory Config: 64-bit UMA
Device Tech: 1Gb
Total memory: 512MB
Boot Device: NAND
Total flash: 128MB

Initializing USB.
Initialize First USB Controller
USB OHCI start : Power Switching Mode Changed from 2000902 to 2000b02
USB: Locating Class 09 Vendor 0000 Product 0000: USB Hub
Try to Initialize Second USB Controller
Initialize Second USB Controller
USB OHCI start : Power Switching Mode Changed from 2000902 to 2000b02
USB: Locating Class 09 Vendor 0000 Product 0000: USB Hub

CFE initialized.

checking usb
ACK :
writing vfd
Starting splash screen.
nand_erase_block 0x1fb20000 0x20000 doneLoader:elf Filesys:raw Dev:flash0.kernel File: Options:mem=48M mem=256M@0x20000000 rootfstype=jffs2 root=/dev/mtdblock0 rw
Loading: !!!!! UNC read error occurred, while reading from NAND flash
nand_erase_block 0x1f200000 0x20000 doneFailed.
Could not load : I/O error
 
if the instruction set is compatible I could try it. in fact I think i might, will keep you all posted, in the meantime will keep looking for an exact part match. either way will let you know how i get on :Cheers:

Mouser...

MERCHANDISE TOTAL: £1.81
DELIVERY CHARGE: £12.00
ORDER TOTAL: £13.81

I hope for that much delivery, the CEO is driving to my house! :D
 
well.... time for an update! :)

I managed to get a chip and long story short its a success AND a failure

Looks like its not working because the CFE is playing silly buggers.

I can actually flash images without errors but they always fail to boot, except 2 images that do boot up all the way! :-o

Firstly is an blackhole NFI image 1.6 been modded by the author, using the serial cable i flash it and it boots up ALL the way. The problem is neither it or an old official vu image find anything when doing a scan, not even FTA channels and i made sure tuner was setup right and even upgraded FPGA via plugin in case it was bad.

Unsure what to do now :(

I can boot up in a fully functioning box so perhaps i need to use a "smarter" flasher in a fully booted box (using the stock NFI or this arab one?) rather than using USB boot to flash.

there are very few NFI images out there :(
 

Attachments

  • arabic_boot.txt
    68.5 KB · Views: 2
This is me flashing openvix (latest) via usb and you can see no issues on flash, however on the restart it fails... I believe the problem is this line (its the first reported problem so likely the root cause of the issue)

UBI error: vtbl_check: too large reserved_pebs 562, good PEBs 228


Complete log attached in any case
 

Attachments

  • latest_vixfail.txt
    17.3 KB · Views: 2
This is me flashing openvix (latest) via usb and you can see no issues on flash, however on the restart it fails... I believe the problem is this line (its the first reported problem so likely the root cause of the issue)

UBI error: vtbl_check: too large reserved_pebs 562, good PEBs 228


Complete log attached in any case

The box is recovered using a spansion chip :)

Required some kernel hacking to fix chip id but its all working fine :banana:
 
Back
Top