Don't know about Debian but Gentoo Beta2 works fine for me using NFS.  But it's very slow - maybe 40 Kbytes/sec copying xbox->pc.  Going pc->xbox is very fast.  If you plan to use it for storing NAND backups, it's still faster than LPT.

I mount it in /nfs_share with something like this:

mount -t nfs -o soft,nolock,rw,rsize=32768,wsize=32768,tcp,nfsvers=3,noatime,nodiratime,async 192.168.0.105:/d/share /nfs_share

You should be able to read the temps from Linux using the sample source code provided.  See here:

http://www.free60.org/SMC

Maybe you can also port this code a XDK version.

You mean on the DVD power connector?  Which pin would need grounding?  For now, I just put a small piece of black electrical tape over the LED, under the faceplate.  Running without the DVD-ROM drive frees up a lot of space inside the case for improved GPU cooling mods, maybe an internal 3.5" HD, etc.

I'm planning on running my 360 without a DVD-ROM connected.  Seems to be working fine so far.  But I noticed the center green LED keeps blinking the entire time.  Is this a normal error message generated when it fails to detect the drive?  Guess I'll have to cover the LED or disconnect it.

This might not work.  Check the xbrflash thread.  It looks like the large nand (256/512MB) stores bad blocks at the end of the initial 64MB area - not at the end of the NAND as expected.

How do you know the video streaming is not encrypted?  Doesn't it only work with MS server apps such as Windows Media Center?

There is also Xbox Image Browser by Redline99.  Works to extract contents of iso file.

I wonder if there is anything that can extract directly from a burned DVD+R DL in the PC drive without having to rip to an iso file again.  I know a few tools that can do that from the original retail disc but that requires hooking up the hacked Xbox360 DVD-ROM drive to your PC every time.

Edit: Never mind... schtrom 360 does everything.  Thanks for the suggestion.

nandpro always uses small block number convention.  This is why for example, it will show total of 0x3FFF blocks on a 256Mb nand. lflash uses big block numbering which means total of 0x800 blocks on the same nand.  So in your example, 0xb0 / 8 = 0x16.  Same block is being reported in both programs (they just use different block sizes).  Hope this makes sense.

Edit.. I see trancy already answered your question too.

Could be some grounding problem.  Those HDMI switches run off the 5v supply from the host device.  You could try disconnecting some of the soldered wires until you pin down which one is causing the issue.  Does it happen with just the 3 JTAG connections in place?

trancy, good job cleaning up the code.  I figured it was something simple but didn't have time to investigate those numbers.  Looks like we only need nandpro now for the initial 50 block xell backup/flash.  Then once you can boot Linux, you can do all your future dumps and flashing from there at lightning speed. 

For the people working on 256/512 Mb write support, it may be easier to debug by simply writing a single (unused) block somewhere at the end of the nand.  Then read back this same block to see if lflash wrote the data correctly.  Hopefully this will not lock up Linux and not corrupt anything important in the nand.  Once the code works for these garbage/unused blocks, you can try to flash the important data at the start of the nand.

I noticed that the total Linux freezes/crashes are much more common when reading/writing to USB storage.  When reading/writing to RAM file system or network share, it doesn't seem to happen for me.  I only get brief pauses (terminal window only, not all of desktop) that eventually resume again.  Try that.

BTW, looking at the dump of a big block jasper, I don't think the sector size is any different from a regular 16Mb nand.  It's still 528 bytes.  There might be more than 32 sectors per block...have not verified that yet.

I think I read somewhere that the bad block flag is stored elsewhere on the larger NAND's.  Try changing:

if (sector_flash[0x205] != 0xFF) /* bad sector */

to:

if (sector_flash[0x200] != 0xFF) /* bad sector */

That should also work and might fix some of the bad sector errors you're seeing.  Rest looks fine to me.

Looking at the source code, I think you can ignore those illegal logical block warnings.  It's a bug in the code but irrelevant for flashing because it's actually coming from code that reads the NAND.  The part writing the NAND is fine - this is why the verify passes 100%  I'm not sure why it's even there in the middle of the flashing function.  It's passing raw physical addresses on a logical read so those addresses are out of range.  Don't worry about it.

Edit:
This code is only used with non-raw flash images to remap bad sectors for you.  Since all the XBR images are raw and have bad sectors already mapped, it's not needed.

To fix the bug, move the line with "readsector(sector_flash, i, 0);" to be inside the "if (!raw) block below it.  Something like this:

Did you try the original XBR_8895_0.bin?  Also could try with just the KV without updating config.  I'm curious if you get yours working because I also have a CB 1903 Xenon. CD/CE at 1888, 4532 kernel.

Can someone with a working jtag (in case the Linux software flash doesn't work) try flashing the XBReboot image using Linux/lflash? It would save those of us who can currently get into Linux using the KingKong exploit a lot of time.  I would try it but if it doesn't work, I won't be able to get back into Linux without soldering the jtag/lpt to my Xbox.

Thanks.

Yeah, I just noticed that after my post by reading Tmbinc's lflash readme.  In there he also mentions not using the tool for full image writes.

http://free60.git.sourceforge.net/git/gitweb.cgi?p=free60/tools;a=blob_plain;f=lflash/README;hb=HEAD

Hmm... maybe flashing this hack from Linux won't work after all.  I was really trying to avoid soldering the wires for the nand flashing.

Well, I'm sure I'm not the only one who stored his 360 for a couple years waiting just for this hack.  My only interest was to run unsigned xex files developed on my devkit.  So I guess you're saying that it would be ok to flash the patched XBReboot image from Linux using tmbinc's flash tool?  Are any of the hardware mods on the motherboard still necessary or were those only needed to dump/flash the nand?  Not even the 3 resistors/diodes bridging a few points?
 

Assuming you still have an old Xenon on which you can run the King Kong exploit, wouldn't it be easier to just flash the NAND from Linux or Xell directly?  Obviously the Xbox can write to the NAND when doing MS updates.  Seems like a lot less trouble than soldering and slow flashing using a PC.  I guess you could even trigger the rebooter directly from KK exploit and avoid doing any hardware mods at all or even opening the Xbox.  Would make this a 100% software mod - like those old save-game exploits on the original Xbox.

arnezami,

Sorry, somehow I missed your post several weeks ago. 

I would obviously vote for option 1.  I already have a devkit but don't have much reason or motivation to work on homebrew if nobody else will be able to enjoy it.

I think option 2 is also very critical since there are hundreds of potential skilled hackers and developers who can't get access to a devkit.  Something like XBMC would not be possible with only a handful of programmers.

This doesn't seem important to me at all - If you're really serious about homebrew, buy another console!

In an ideal world, I would love for this option to work.  Having the freedom of full hardware access is great.  But the reality is that all modern consoles (Xbox360, PS3) are incredibly difficult to code for even with professional tools and documentation.  Debugging multi-threaded code, shaders, etc. just isn't practical without the official tools.  I'm willing to sacrifice some hardware access for ease of development.  I think most developers who do this for a living would agree.

I think you're on the right path with the kernel rebooting trick.  If it works out, it might be the solution to all 3 issues you listed above. (assuming we can load a modded devkit kernel).

How is piracy related to a xex loader?  In order to run a xex loader or anything else on the 360, you need modded DVD firmware.  Once you have modded DVD firmware, you can already run pirated games.  No need for a loader.

The loader would only be useful to people that want to run homebrew.  There are MANY popular apps/emulators already ported to the 360 (here's another: http://www.xbox-scene.com/xbox1data/sep/EEZFpZuFVFfajVjLfN.php).  You either need to buy a devkit or wait for someone to write a loader for retail boxes.

I don't understand the whole Linux craziness myself... I mean why bother with an xbox360 when there are already a million other devices that run Linux without hacking?  I would rather write native apps using the XDK.  I guess to each his own...