New IT forum
29 June 2022, 07:07:26 am *
Welcome, %1$s. Please login or register.

: MiraBox now in stock.
 
Pages: [1] 2 3

Author Topic: GuiPlug v2.7 now available  (Read 31309 times)

NewITMalcolm

  • Administrator
  • Sr. Member
  • *****
  • Posts: 394
GuiPlug v2.7 now available
« on: 31 October 2011, 01:42:12 pm »

GuiPlug v2.7 for the Dreamplug is available for Download and will shortly be available from the shop.

New Features for v2.7 include:

-  Hot Plugging of Usb Monitors, Usb Monitor can be removed and plugged back in anytime.
-  Kernel 3.0.7
-  improved wifi Client configuration
-  Refreshed Debian Squeeze rootfs

Other changes include:
- VNC access still starts if no USB monitor is found at boot but is now moved to port 5901 to allow monitors to be hot-plugged at any time. Adding a usb-monitor will not disrupt VNC access.

Downloading and writing the image:
http://downloadsnewit.co.uk/SD-images/Dreamplug/GuiPlug/v2.7/

md5 to verify the downloaded image.
Quote
99d4069a485529e728a51b36cede73af  NewIT-GuiPlug-v2.7-4Gb-29oct11-Dreamplug.img.gz

Here is the best way to decompress the image to your SD card.(change the sdx to your device)
Code: [Select]
gzip -cdv NewIT-GuiPlug-v2.7-4Gb-29oct11-Dreamplug.img.gz | dd of=/dev/sdx bs=8192
If it does not complete without errors the SD card is probably too small.
I would thoroughly recommend the 'Integral Endurance' SD cards for their Performance and longevity.
http://www.newit.co.uk/shop/products.php?cat=10
(If anyone thinks they have a faster SD card I would love to hear from them.)




Logged
NewITJames

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #1 on: 02 November 2011, 10:12:04 pm »

I know everyone's bored to tears with this - but I had to cut this image down to 4GB to fit on my SD card - AGAIIN...
Anyway, it boots beautifully now.
Should *I* make a '3.9GB' image available?
Logged

Confusticated

  • New IT customer
  • Hero Member
  • *
  • Posts: 663
Re: GuiPlug v2.7 now available
« Reply #2 on: 02 November 2011, 10:55:58 pm »

There is more than one way to skin a cat, or write an SD Card

http://www.newit.co.uk/forum/index.php/topic,2648.msg7681.html#msg7681
Logged
Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #3 on: 05 November 2011, 08:49:27 pm »

Here's another, maybe trivial.
Has anyone managed to get BBC iPlayer to work?
Under 2.6 it didn't recognise the 'phone' (which I assume the Plug was presenting itself as).
Under 2.7 it just seems to hang.
Logged

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #4 on: 06 November 2011, 09:49:20 pm »

OK, polite people say I am tenacious; I do believe most would simply have given this one up as a bad job.
The new v2.7 image is 4102029312 bytes . I have a new, decent quality 4GB SDHC card, which is only 4041211904 bytes.
Using dd to copy the image fails of course, leaving the target root partition irrecoverably corrupt.
The card's predecessor was run under v2.6 before i knew about the length thing. I have no actual evidence to support this theory, but it was irrecoverably damaged, probably by a write-past-end during operation frying its internal addressing. The manufacturer actually replaced it.

So I decided to try and create a shorter image:
There is more than one way to skin a cat, or write an SD Card

http://www.newit.co.uk/forum/index.php/topic,2648.msg7681.html#msg7681

Fortunately I vaguely remembered using chmod under Unix about 20 years ago to permit a shell file to run and got the image partitions mounted.
fdisk would not allow me to create a dos partition starting any earlier than sector 2048 for some reason, and the boot sector must start at 62.
So I copied a strip of the original image using dd with count. This overwrote the partition 1 start sector so I could partition and format the device and copy the files in from the tar images. This solution worked, I'm pleased to say.

So OK. maybe tar images are not ideal.

Once again, why can the image files not be a fraction shorter, say 3.8GB for a 4GB card? Then if you want to expand the image to fill the card (with gparted), you can. Shortening the images to fit is a real fiddle, and furthermore needs to be done in an environment with enough room.
« Last Edit: 06 November 2011, 09:56:55 pm by Ralph Houston »
Logged

Confusticated

  • New IT customer
  • Hero Member
  • *
  • Posts: 663
Re: GuiPlug v2.7 now available
« Reply #5 on: 06 November 2011, 11:51:28 pm »

Hi Ralph,

Quote
fdisk would not allow me to create a dos partition starting any earlier than sector 2048 for some reason
Flash devices do not work on 512B sectors, they read 'pages' typically 4,096B nowadays. before a page can be written, the flash must be erased.
BUT (its a huge but) the smallest area that can be erased is a 'block', a multiple of 'pages', typically 256kB.
So how does Linux handle this ? It copies what is in a partially used block, appends the page to be written, erases the whole block, and writes the copy+page.

2048 * 512 = 1,048,576

Which is divisible by 512kB, 256kB, 128kB, 64kB, 32kB, 16kB, block sizes and also 8192B, 4096B, 2048B, 1024B, page sizes, which is why it was chosen.

Quote
the boot sector must start at 62
This is so wrong when dealing with flash, the partition must start on a page boundary or you will get a large performance penalty because of multiple copy writes.
(Ah, if you are an 'Old Hand', I know where you got this from, limitations of the MSDOS Boot Sector)

     A      B       C
[------][------][------]
   ^
      If your partition starts here, both blocks A & B must be copied, erased and rewritten (because an erase is 'block' bytes long).

     A      B       C
[------][------][------]
        ^
          If your partition starts here, only block B must be copied, erased and rewritten.


NB I have over-simplified this to try to explain what is going on here, trust Linus & the other Devs, they are very clever blokes, fdisk gets it right.
Please go and read about flash memory on Wikipedia, don't take everything I have said here as gospel.

« Last Edit: 07 November 2011, 12:19:04 am by Confusticated »
Logged
Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #6 on: 07 November 2011, 10:23:17 am »

Thanks for all this info!
But what can I say, I copied the two partitions from the tars and the plug would not boot.
(I didn't have the JTAG on, so I don't know why not - I suspect it was the old one kernel - other root problem),
When I put them on with the 'fat16' partition matching the start sector in the image, it booted first time.
I'll investigate further and report.
Logged

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #7 on: 07 November 2011, 11:19:13 pm »

So, further invesigation. Obtained yet another 4GB SDHC card.
Created partitions with partition 1 starting at sector 2048, and partiton 2 of length +2200M. Wouldn't start GuiPlug, cryptic messages on graphical monitor during 1st boot. Reboot, no gui messages at all. In both cases, JTAG boot messages seemed OK.
On inspiration, enlarged root partition, now it starts GuiPlug! Wish I knew what had gone wrong before. Suspect I committed cardinal sin of changing two things at once, attempting to keep root partition as small as possible.
No out-of-space errors during attempt 1, I notice.
The image from NewIT has partitions from sector 62-11809 and 11810 onwards, not on page boundaries - is this non-optimal?
In the 'recommended' pattern, partition 1 starts at sector 2048.

Now if I follow your description, confusticated, to use the deprecated start address, or deprecated block lengths, would cause locations to be read and rewritten once or twice during image transfer. This would reduce the lifetime by a cycle or two and be slow, but apart from elegance, what is the issue?
Logged

Confusticated

  • New IT customer
  • Hero Member
  • *
  • Posts: 663
Re: GuiPlug v2.7 now available
« Reply #8 on: 08 November 2011, 12:44:03 pm »

Quote
partitions from sector 62-11809 and 11810 onwards
Well noted, the first partition is not so much an issue (although not optimal), it is only written when you update the kernel (and normally only read by u-boot).
That second partition should be moved (I make that a 1k boundary, which is not coarse enough).

Quote
cause locations to be read and rewritten once or twice during image transfer
When using 'dd', writing is not performed at the file system level, its 'device' level, and as you start at the beginning of (not some offset into) the device, this wont occur
(I am assuming that normal Linux disk caching is in play, and that 'raw device' or O_DIRECT access is not being used).
Un-tarr'ing, normally takes place at the file system level of access.

Quote
read and rewritten once or twice during image transfer
rewrite two blocks for every block write
So, writing a log entry, copying a file.....i.e running Linux :)

NB Linux disk caching will reduce the number of writes, but it can't do anything about the situation where the write starts partially in one 'physical' block and continues into its neighbouring 'physical' block. It must erase the entirety of both blocks.





Logged
Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!

NewITMalcolm

  • Administrator
  • Sr. Member
  • *****
  • Posts: 394
Re: GuiPlug v2.7 now available
« Reply #9 on: 08 November 2011, 02:19:35 pm »


If anyone has any fixes or improvements for the Gui image the please post and I will try and include them.  :)

Logged
NewITJames

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #10 on: 09 November 2011, 12:46:52 am »

Thanks Confusticated and James
So to satisfy all requirements, what would be recommended:
- zero the image
- fdisk and format new partitions, say sectors 2048-102399 as fat16 and 102400-7782399 as ext3 (512B sectors, leaving 5% slack on nominal 4GB card)
- copy in uImage and root system
- dd image (bs=1M count=3800) and gzip it?

Then ftp this where?

Best regards
Ralph
Logged

Confusticated

  • New IT customer
  • Hero Member
  • *
  • Posts: 663
Re: GuiPlug v2.7 now available
« Reply #11 on: 09 November 2011, 06:31:56 pm »

Logged
Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #12 on: 09 November 2011, 09:33:16 pm »

Sorry, I wasn't completely clear. I've seen and used your method for copying the images, thank you, Confusticated. My question to you is do you agree with my suggested sector boundaries?

And to James, if I succeed, would you like me to ftp the image somewhere for you and/or others to use?
Logged

Confusticated

  • New IT customer
  • Hero Member
  • *
  • Posts: 663
Re: GuiPlug v2.7 now available
« Reply #13 on: 09 November 2011, 09:53:41 pm »

Hi Ralph,
The numbers look OK to me, as a personal preference I would go for a first partition of 16MB but there is nothing wrong about having it larger.
And in fact, I have found having space on a file system usable in Windows is handy for that odd bit of information (I have disaster recovery info on mine, it can be useful at times of stress to have a record of where the Linux file system superblocks are :).
Logged
Advocatus Diaboli - My agenda is not to give you the answer, but to guide your thoughts so you derive it for yourself!

Ralph Houston

  • New IT customer
  • Full Member
  • *
  • Posts: 136
Re: GuiPlug v2.7 now available
« Reply #14 on: 11 November 2011, 09:10:12 pm »

OK, as a test I took a 4GB class 4 SD card and created a partition starting at sector 6144000 (aligned I hope).
The write rate with dd, using 1MB blocks, was 6.8MB/s.
With the destination a file, having formatted the partition to ext3, the write rate was 4.2 MB/s.
I then 'misaligned' the partition to start at 6143999 (worst case, read 1 sector + 1MB, write 2 x 1MB).
the rates became 7.4 and 3.8 respectively, i.e. no change.

Comments?
Logged
Pages: [1] 2 3
 
 

Powered by MySQL Powered by PHP SMF 2.0.10 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!