Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×
This discussion was created for logged-in users only, but now has been archived. No new comments can be posted.

Wii U's day-one update is capable of incapacitating machines.

Comments Filter:
  • I assume that the update comes with a warning about turning off power during update installation I also assume that the update takes some time? If these assumptions are correct why are people turning the WiiU off during the process? Are they dumb asses? They don't even deserve a warranted repair/ replacement if that is the case.

    • uh... because the update is FIVE GB in size, and with some people's connections, can take hours to download and install. A broken connection within these HOURS, not just a few minutes, can brick the Wii U. Seems like they should have just sent out/distributed update discs instead...
      • by JustNiz (692889)

        I'm already surprised that they didn't make the flash large enough to hold 2 firmware images, so that they can validate the most recently flashed image before they make it 'live', and fall back to the old one if the new one doesn't check out.

        But sorry I just cant believe your comment can be factual.
        I just can't believe even Niintendo would actually be stupid enough to start overwriting the flash while the new image is still being downloaded. Its just basic common sense to download it first (to SD I presume

        • by sjames (1099)

          Ideally, they would do that and have a toggle that flips the two segments in memory based on the reset line. The firmware goes into the alternate bank and then you hit reset. If it all works out, copy the (now primary) new image over the old. If anything goes wrong during any reflash, reset will put it right again.

          • by JustNiz (692889)

            why copy it over the old image? just use it in place.

            • by sjames (1099)

              So that next time someone hits reset they don't end up going back to the old firmware.

              If instead of a commonly used control like reset, there is a special recovery switch, the copy-over is unnecessary.

              • by JustNiz (692889)

                Just have it so after you've flashed the new bios and it gets checksummed and found good, it gets marked as valid.
                Then whenever you reset or power up, the boot loader just jumps to the entrypoint of whichever bios in flash is market valid and has the latest version number.
                Obviously next time you flash the bios, which one it overwrites depends on which is valid and/or oldest.

                • by sjames (1099)

                  That's fine if you aren't flashing the bootloader itself. The scheme I outlined allows for a safe re-flash of everything.

          • by Kiralan (765796) *
            Agreed. Motherboards have been doing this for YEARS! At the very least, have a minimal permanent/ROM Bios that can do a download.
      • by JustNiz (692889)

        Oh and BTW its 1 GB not 5GB

    • I have to wonder when the user's powering it off during this process. If it's being bricked when powered off during the download phase (before the firmware gets flashed), then it's a point of concern, since it should be stuffing that data into a holding area before it does a single thing with it.

      However, if it's during the flashing phase, well, then that's the user's stupid fault. They DO throw warnings all over the place. But, knowing Nintendo, there's a nonzero chance that the download/update screen ar

In seeking the unattainable, simplicity only gets in the way. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982

Working...