Buffalo NAS-Central Forums

Welcome to the Linkstation Wiki community
It is currently Fri Jan 19, 2018 12:58 am

All times are UTC+01:00




Post new topic  Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Wed Feb 06, 2008 3:03 pm 
Offline
Newbie

Joined: Sat Jan 19, 2008 1:43 pm
Posts: 11
The 2.6 kernel flash driver, "/dev/mtd" does not work on my LinkStation HG, which has a M29DW324DB STMicro flash chip.

The following change fixes the problem, but in an odd way.

I tested this on my LS-HG and on my Kuro-HG.

Code:
diff -C 16 -r /usr/src/olinux/linux-2.6.23/drivers/mtd/chips/cfi_cmdset_0002.c /usr/src/linux/drivers/mtd/chips/cfi_cmdset_0002.c
*** /usr/src/olinux/linux-2.6.23/drivers/mtd/chips/cfi_cmdset_0002.c   Tue Oct  9 15:31:38 2007
--- /usr/src/linux/drivers/mtd/chips/cfi_cmdset_0002.c   Wed Feb  6 06:45:04 2008
***************
*** 319,350 ****
--- 319,362 ----
                  "bank location. Assuming top.\n", map->name);
           bootloc = 2;
        }
 
        if (bootloc == 3 && cfi->cfiq->NumEraseRegions > 1) {
           printk(KERN_WARNING "%s: Swapping erase regions for broken CFI table.\n", map->name);
 
           for (i=0; i<cfi->cfiq->NumEraseRegions / 2; i++) {
              int j = (cfi->cfiq->NumEraseRegions-1)-i;
              __u32 swap;
 
              swap = cfi->cfiq->EraseRegionInfo[i];
              cfi->cfiq->EraseRegionInfo[i] = cfi->cfiq->EraseRegionInfo[j];
              cfi->cfiq->EraseRegionInfo[j] = swap;
           }
        }
+
+       /*
+        * LinkStation hack - A problem was occurring because 0x555 is not equal to (0x2aa << 1).
+        *
+        * This hack turns off the addr_unlock scaling and causes the addr_unlock
+        * values to be pre-assigned properly below.
+        */
+       cfi->device_type = CFI_DEVICETYPE_X8;
+       /*
+        * end of LinkStation hack
+        */
+
        /* Set the default CFI lock/unlock addresses */
        cfi->addr_unlock1 = 0x555;
        cfi->addr_unlock2 = 0x2aa;
        /* Modify the unlock address if we are in compatibility mode */
        if (   /* x16 in x8 mode */
           ((cfi->device_type == CFI_DEVICETYPE_X8) &&
              (cfi->cfiq->InterfaceDesc == 2)) ||
           /* x32 in x16 mode */
           ((cfi->device_type == CFI_DEVICETYPE_X16) &&
              (cfi->cfiq->InterfaceDesc == 4)))
        {
           cfi->addr_unlock1 = 0xaaa;
           cfi->addr_unlock2 = 0x555;
        }
 
     } /* CFI mode */


Top
   
PostPosted: Wed Feb 06, 2008 3:22 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
tonyo, thank you for posting this...

Could this be the reason why and the fix for us not being able to flash our boxes while booted in 2.6? From what I can remember, I have only been seeing us flash while in 2.4 or from UBoot...

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Last edited by davy_gravy on Mon May 05, 2008 10:25 pm, edited 1 time in total.

Top
   
PostPosted: Wed Feb 06, 2008 3:40 pm 
Offline
Site Admin
User avatar

Joined: Mon Jul 11, 2005 7:19 am
Posts: 7703
Location: Austria, Vienna
yes, so far we all were only able to flash ppc boxes in the 2.4 kernel or from within UBoot.

would be cool if this limitation could get fixed. its a strange hack indeed. the patch looks like as if it cures the symptom but not the root of the problem. anyone knows what could be wrong?

_________________
LS1 (2.6 kernel, foonas svn1062, 750 GB, UBoot 1.2) & LS Pro (FreeLink/jtymod/GenLink, changes all the time)
Thx to all donators!


Top
   
PostPosted: Wed Feb 06, 2008 3:49 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
tonyo, could you expound a little more about what you mentioned to me in the irc?

You said, if I remember correctly, that it (the chip) is a 16 bit but needed to be accessed in 8 bit mode, in this particular instance? Is that right? ... (davy scratches his head while still waking up... )

'bender, when tonyo mentioned this to me, I was surprised...and happy to hear it, and suggested that he post it. I figured that it would get some people's attention. :D

... if it can be replicated on the HG (and on the other machines) then it could solve a lot of problems for us, I agree.

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Wed Feb 06, 2008 3:56 pm 
Offline
Site Admin
User avatar

Joined: Sun Jul 17, 2005 4:34 pm
Posts: 5332
Could this also work with the LS1's "4MB ST M29W320DT HG003"? I've prepared test kernels in my tmp directory http://hvkls.dyndns.org/downloads/tmp , so if anyone would test them please? Note, make sure apservd is running, my ugradehelper inhibits its startup on 2.6


Top
   
PostPosted: Thu Feb 07, 2008 2:03 am 
Offline
Newbie

Joined: Sat Jan 19, 2008 1:43 pm
Posts: 11
Quote:
You said, if I remember correctly, that it (the chip) is a 16 bit but needed to be accessed in 8 bit mode, in this particular instance? Is that right? ... (davy scratches his head while still waking up... )

This might sound confusing, so I've tried to say too much rather than too little in the hopes that it will help.

First, I don't have a schematic, so I'm not sure how A1, A0 and/or BYTE# are wired. I'm still not sure if it's 8-bit or 16-bit in truth.

Regardless, the CFI probe and detection code only works when all of the CFI table offsets are doubled. This is consistent with addressing a 16-bit flash, since the address lines are typically shifted by one bit. The A0 line (and up) on the flash are driven by A1 and up on the CPU. So byte addresses 0, 2, 4 would access flash word-addresses 0, 1, 2. This is a typical arrangement for 16-bit memory. In most cases the A0 line on the CPU is simply not connected.

The mtd driver doesn't know what the board is doing, so to figure it out, it simply tries it both ways in the probe code. In our case, the probe is successful with an offset scaling factor of two. This is typical for a 16-bit word memory accessed by byte addresses. This "offset scaling factor" is called "cfi->device_type" in the mtd driver.

Flash chips usually want to see commands written to the magic offsets 0x555 and 0x2aa. To get these offsets to appear at the 16-bit flash, the CPU writes to byte addresses 0xaaa and 0x555, which get shifted right due to the A1->A0 hookup, to become 0x555 and 0x2aa, which is what the flash wants to see.

However, what the mtd driver does is it takes the magic offsets 0x555 and 0x2aa and it shifts them left using the scaling factor "cfi->device_type" to produce the necessary doubled CPU byte addresses. This is a problem because a shift-left of 0x2aa does not yield 0x555, but rather 0x554. I think this is the real problem.

Unfortunately, the flash chip really does want the CPU to generate the byte addresses 0xaaa and 0x555. It seems to be emulating the behavior of 16-bit addressing while using byte addresses. The mtd driver writes to 0x554, but this usually works, because the A0 bit would be dropped anyway, i.e. it's not connected.

What I decided to do was change the scaling factor back to one and let the code directly use 0xaaa and 0x555 instead. This should work, because cfi->device_type isn't used for anything else once the detection and CFI table parsing is finished. I dislike the hack on aesthetic grounds, but it works. A more elegant approach would be to fix up the 0x554, whenever it occurs due to the scaling, but I thought the one-liner was simpler, even if it seems weird.


Top
   
PostPosted: Fri Feb 08, 2008 11:20 pm 
Offline
Newbie

Joined: Sat Jan 19, 2008 1:43 pm
Posts: 11
Did that explanation help anyone? It works for me. Anyone else?


Top
   
PostPosted: Sat Feb 09, 2008 1:03 pm 
Offline
Site Admin
User avatar

Joined: Sun Jul 17, 2005 4:34 pm
Posts: 5332
I'm about to deploy my upcoming kernel package v95 with your fix. We shall see :)


Top
   
PostPosted: Sat Feb 09, 2008 2:02 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
@ tonyo - thanks, that is very useful - intellectual contributions are always welcome here. surely someone from the community will ask a question related to this - we'll make sure to refer them to your thread and this answer. In fact, I'll link it to the UBoot/flashing categories pages.

@ andre - I'd really like to try this out. I have a used (eBay el-cheapo/salvage) HG that I may pop out of its box and try this on. I probably out to solder on a serial header first though (just in case - I trust your kernel work just fine - more to safeguard myself against my own mistakes - hehehe :) ).

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Thu Feb 14, 2008 8:14 pm 
Offline
Newbie

Joined: Sat Jan 19, 2008 1:43 pm
Posts: 11
Has anyone else tried this yet?


Top
   
PostPosted: Thu Feb 14, 2008 8:48 pm 
Offline
Site Admin
User avatar

Joined: Sun Jul 17, 2005 4:34 pm
Posts: 5332
I haven't, but my recent kernels are all patched patch! Remember to start ap_servd manually and check if it's really running (inhibited on 2.6 according to the upgradehelper's /etc/init.d/apservd).


Top
   
PostPosted: Mon Sep 01, 2008 4:06 pm 
Offline
Newbie

Joined: Sun Aug 31, 2008 11:07 pm
Posts: 48
tonyo wrote:
The 2.6 kernel flash driver, "/dev/mtd" does not work on my LinkStation HG, which has a M29DW324DB STMicro flash chip.

The following change fixes the problem, but in an odd way.

I tested this on my LS-HG and on my Kuro-HG.
(...)


Does this issue exist in the standard Kuro? Also, has a variant of this patch (perhaps, protecting the assignment with some ifdefs) been pushed upstream? This way, it would make life easier for people that want to use recent kernels (compile their own) and also guarantee that the driver continues working in the kernels present in the distant future.

Thanks, Rogério Brito.


Top
   
PostPosted: Mon Sep 01, 2008 4:27 pm 
Offline
Site Admin
User avatar

Joined: Mon Aug 28, 2006 1:15 am
Posts: 2606
I don't know. I do know that when I experienced the problem, it was a matter of just booting into a 2.4.33.3 firmimg.bin to do the flashing. Or I flashed whatever from the uboot side.

I thought it was a kernel-dependent problem, rather than a machine dependent problem.

_________________
LS1 (foonas, nfs, Tranmission & p910nd print server, Firefly for my Roku)
LS-HG500 (Lenny)
Various LS-Pros v1,v2 (unbricked w/ serial & jtag)
KuroPro, LS2 & KuroHG (foonas)
Working on davysweather.dyndns.org lately...

=> wooohooo!
wooohooo!
Unknown command 'wooohooo!' - try 'help'


Top
   
PostPosted: Thu May 14, 2009 9:13 pm 
Offline
Newbie

Joined: Sun Aug 31, 2008 11:07 pm
Posts: 48
davy_gravy wrote:
I don't know. I do know that when I experienced the problem, it was a matter of just booting into a 2.4.33.3 firmimg.bin to do the flashing. Or I flashed whatever from the uboot side.

I thought it was a kernel-dependent problem, rather than a machine dependent problem.


Right. Perhaps this could be pushed upstream, to see what comments the MTD people might have regarding the patch and how it could be addressed.

Regards, Rogério Brito.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 14 posts ] 

All times are UTC+01:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited