Hello everyone,I have a Terastation Live (HS-DHTGL), and I'm curious about installing a netconsole-enabled u-boot. These forums and the wiki talk about running a patched u-boot 1.1.4 on Linkstations, and I was wondering if anyone has tried this on the Terastations. Are there any differences between the boards that might prevent 1.1.4 from working?

Also, the wiki mentions running a RAM build with a uloader kernel module, but it looks like this was a 2.4 module and I can't find any other details on it. Does uloader or anything like it still exist?

AFAIK, no one has had success w/ a true RAM build, but I think bbradley was working on something similar/related. I don't remember details on exactly what he was doing.

About a year ago I began tinkering w/ uboot for ARM, and have managed to make a successful set of patches that enable netconsole on LSPro and LSLIve.

If you look at the source, you will see that it mentions the TS, IIRC. It was alway my understanding that it was "one uboot for all ARM stations", at least of a given generation. If you look at the source you will see what I mean. That said, I don't know anyone that has ever dumped a TS uboot and compared it to a uboot dumped out of an LS Pro.

There is an article in the Article section, UBoot for LSPro... that gives details.

IIRC, I may have disabled a few lines of code to quell some panicky alarms. This may have inadvertently turned of the LCD display as well.

I would not install the netconsole uboot for LSPro into a TS as is. It would have to be revisited and check thoroughly, recompiled. Then you'd need JTAG and some time for testing whatever you built, and some luck. A TS would make one impressive yet prohibitively expensive Brick.(!)

The u-boot.bin that comes compiled in the vanilla u-boot-1.1.1_buf109.tar.gz is different from the one in the stock firmware, but I don't know how much of it is important, or if the stock firmware even uses the same u-boot sources. Recompiling actually seems to reduce the difference, leaving a handful of scattered bytes, perhaps the build time, and a different source path for mv_main.c compiled in. Earlier, in a particularly brash moment, I did write the new u-boot.bin to /dev/mtdblock0 and rebooted, and I seem to be suffering no ill effects, so at least that's promising.

If I do end up doing something stupid and it goes wrong, how difficult is it to add the JTAG port? The reason I'm looking into this at all is because I'd like to keep the board and my fingertips away from the searing dangers of the soldering iron; I haven't installed a serial console, but I'd like some access to boot messages so I can maybe figure out why a mostly-vanilla kernel built for a Terastation Prov2 (http://buffalo.nas-central.org/forums/viewtopic.php?f=22&t=8496) doesn't seem to work on the Live. Would I be better off soldering in the serial console instead?

The u-boot.bin that comes compiled in the vanilla u-boot-1.1.1_buf109.tar.gz is different from the one in the stock firmware, but I don't know how much of it is important, or if the stock firmware even uses the same u-boot sources. Recompiling actually seems to reduce the difference, leaving a handful of scattered bytes, perhaps the build time, and a different source path for mv_main.c compiled in. Earlier, in a particularly brash moment, I did write the new u-boot.bin to /dev/mtdblock0 and rebooted, and I seem to be suffering no ill effects, so at least that's promising.

You are a brave man, but it worked apparently. When you say "the new u-boot.bin", do you mean the one you compiled, or the one that was already in the tarball? (they should be essentially the same except, as you say, some differences attributable to date and compile environment...)

What you say here is valuable, I believe, as (as far as I know) it is a first.

Quote:

If I do end up doing something stupid and it goes wrong, how difficult is it to add the JTAG port? The reason I'm looking into this at all is because I'd like to keep the board and my fingertips away from the searing dangers of the soldering iron; I haven't installed a serial console, but I'd like some access to boot messages so I can maybe figure out why a mostly-vanilla kernel built for a Terastation Prov2 (http://buffalo.nas-central.org/forums/viewtopic.php?f=22&t=8496) doesn't seem to work on the Live. Would I be better off soldering in the serial console instead?

To be honest, the serial connection is as useful or more useful than the netconsole connection, as it is (more) impervious to network problems that a kernel might have... although, yes, serial is physically more intrusive.

itimpi may know more about the serial headers soldering info, as well as details on soldering on jtag headers for the TSProv2.

When you say "the new u-boot.bin", do you mean the one you compiled, or the one that was already in the tarball? (they should be essentially the same except, as you say, some differences attributable to date and compile environment...)

itimpi & mindbender: do we have a record of anyone jtagging these ARM TS units/boards before? Same for serial on these specific boards? Maybe kuroguy tried this/these?

mindbender: nice pix

all: If I see what I think I see, the holes on J1 (serial) look like they are not in the customary "straight line" - are there actually 4 holes there? If not, would leads have to be attached?. What is CN29? ( bottom center of this shot : CIMG3089_resize.JPG )

Do I see it correctly that CN17 (what is labeled as "ARM standard 20 pin") doesn't have the normal sized holes (by normal I mean the size that we are accustomed to for header pins - and that fit standard jtag connectors)?

Who is online

Users browsing this forum: No registered users and 2 guests

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