An update...

I have the adapter and now already have a couple of chips ready to put in...
but,
Im attempting to determine if it can in fact handle a 16MB SPI device... which would give me plenty of space to put both the kernel AND boot logo... so it could FINALLY boot w/o an SD card.

Who am I kidding? Ive just been too fkng lazy (and blind!) to do it! :rolleyes:
:D

NO, I have NOT given up...
 

and Im actually feeling 'a bit guilty' for not having the 2 netbooks back together and running along yet. Some exciting developments have taken most of my attention... some of it away from car repairs, no less!

I am curious about attempting to do something with the OTG port (rear USB) these devices have on them. I have heard NOTHING about using them... even for standard USB uses.

But playing around with those will happen soon.

I do keep saying that, dont I? :rolleyes:

:D

Zombie Resurrection Mode!
 

Yes, after most of a year, I am coming back to attempt to finish what I've started!
The first part of the year was spent getting my knee fixed... and looking at all the disassembled toys awaiting my TLC!
Uh huh... :rolleyes:

Among other things, I also have a nice, new soldering tool... so AWAY WE GO! :D

Im afraid to see how much app-get-ing is going to be needed NOW! :p

The Wrecking Crew gets busy!
 

I have been 'flirting with danger' this week on the netbooks, but have gleaned some important information.

Firstly, it SEEMS that a W25Q64 (Winbond 64Mbit/8MB) SPI is the largest it is willing to accept. Cannot tell if this is a limitation of the available u-boots, or some other devious contrivance.

I have been playing with 'another' netbook... not the one Ive been 'Linuxing'... but one that hopefully will be. I suspect that the w-load Ive put on it (v 19.something) is NOT for these books... for even though it comes up operating, it cannot recognize the 2GB NAND chip it was configured with. Does not read/write/erase it either.

While I have not been actively working on them, I have NOT stopped thinking about what needs to be done, and how to automate a safe modification of the system(s). For example:

The default location of the w-load, the 'raw init' (or U0 for Android tablet familiars) ALWAYS resides from FFFF-0000 to FFFF-FFFF.
So, if the SPI is, for example an 8Mb device (or 80-0000, 128 64KB 'pages'), the beginning of the device is
FFFF-FFFF - 0080-0000 or (FF80-0000).
Yes, some of you are complaining that it doesnt 'line up', as the result would show FF7F-FFFF... I just 'cheat'. :rolleyes:

I was working with a 2MB (25Q16) device and 'blew it up' again when I tried to save the logo.bmp into the SPI... without enough room. :p It wiped out EVERTHANG!

I HAD attempted to use a W25Q128 (128Mbit/16MB) device but it did not 'sit well' with the erase function.
I suspect this has to do with the incompatible wload/uboot versions... as it keeps calling EVERYTHING a 25Q64 (actually the SST version)... I'm hoping I have saved originals somewhere, and can try again, but I'm beginning to be concerned about the soldering/unsoldering of these SPIs... I wish I could fit a 'zif socket' in there...

Once the 64s show up I will try (yet) again! :D

EDIT: I did manage to find some older versions of w-load and u-boot... am going to try the 128Mb/16MB chip again. I THINK there is supposed to be enough room for it... but will have to 'wait & see'! :D

The '64s arrived today... and one is already progged and ready to go!
I have 3 u-boots for these things now... and I am hoping that one of them will be able to work with a 128 (16MB) device.
I believe that an 8-megger will be enough for a while, as
u-boot is 320k (fff8-0000 to fffc-ffff),
2 configs @64k (fffd-0000 to fffe-ffff), and
w-load at 64k (ffff-0000 to ffff-ffff).
All of which fits into 512k. so 8MB - 512k leaves 7.5Mb open.

That oughta be plenty to hold the kernel and a lousy logo! :p
:D

Shift of focus...
 

After many permutations of SPIs on this 'unfixed' board, I am going to return to the 'original' unit. The NAND device, after all the attempts, does not get recognized under any attempt... I fear that the board itself is faulty and would not work with any SPI.

Thus, I have reloaded a 16MB with a fresh load which will be put into the other board.
:(

I was able to confirm today that the 8MB device IS large enough to hold the kernel, logo AND the 512k of u-boot etc.
Unfortunately this 'broken' board does not boot the kernel completely... and I suspect it is related to the NAND 'problem'.

Now that the weekend is coming I can (re)build the 16MBer with the info I was able to pull back off the 8... before I locked it up again. :rolleyes:
Hint: ALWAYS ERASE the area of SPI that you intend to write INTO... otherwise it will not work. :duh: :D

So, I SHOULD have the linux unit running again before the weekend is done. Then I can go blind trying to bring the dead tablets to life again... hopefully 'purifying' their linux-ness in the process! :p

:D

Something rotten in denmark...
 

Have been working with the 'working Linux book' and recently developed a severe problem...
The 128MB would not work correctly, but when I installed the 64, the kernel loads and blinks the keyboard lights but does not continue.

Im beginning to suspect that there may be solder-bridging in the area where the SPI mounts... I know that the kernel image is good as I used multiple copies from multiple sources which have not been modified...

I am beginning to feel quite negative about this... if I cannot find the cause I will not be able to continue.
:(