Date: Sun, 25 Apr 1999 11:31:55 +0200 From: Stefan Esser <se@mi.uni-koeln.de> To: Doug Rabson <dfr@nlsystems.com> Cc: Rich Payne <rdp@talisman.alphalinux.org>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, Alpha List <alpha@freebsd.org>, "Daniel J. Frasnelli" <dfrasnel@csee.wvu.edu>, Stefan Esser <se@freebsd.org> Subject: Re: your mail Message-ID: <19990425113155.A424@dialup124.mi.uni-koeln.de> In-Reply-To: <Pine.BSF.4.05.9904241522530.28665-100000@herring.nlsystems.com>; from Doug Rabson on Sat, Apr 24, 1999 at 03:28:12PM %2B0100 References: <Pine.LNX.4.10.9904240806560.32246-100000@talisman.mv.com> <Pine.BSF.4.05.9904241522530.28665-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1999-04-24 15:28 +0100, Doug Rabson <dfr@nlsystems.com> wrote: > On Sat, 24 Apr 1999, Rich Payne wrote: > > > The particular problem which I have with the Samsung board is that its > > > firmware is not AlphaBIOS but instead is a modified ARC style system. I > > > need information on what specific differences the Samsung firmware > > > programming interface has compared to Digital's AlphaBIOS firmware. My > > > test programs which work on AlphaBIOS do not work with the Samsung > > > firmware. I believe that Linux also needs a specially modified version of > > > their loader for this board. > > > > Which Samsung board? > > It was the UX board as far as I know. I bought a number of Samsung UX boards (aka DeskStation Ruffian). These boards were the test base when I tried to get the first step of ARC booting of FreeBSD going (based on work by Doug and others). Anyway, my finding was, that I could only call ARC functions that take no arguments (or at least no arguments that are pointers to the actual data to be passed). I quickly came to a state where I could Halt or Reboot the system by executing a program compiled with gcc under FreeBSD (and fixed-up to conform to the EXE format expected by ARCSBIOS). But even writing a single character to STDOUT failed. this is definitely a result of the BIOS supplied with the "Ruffian" not being ARC compliant. Even the pre-compiled sample binaries that come with the ARC Developers Kit donīt work ... Since I had a little spare time a few months back, I looked at both the NT boot disk that came with the main-boards and the Linux boot disk available from some web site (should have a bookmark somewhere). Both these binaries do call Vendor functions outside the range that is specified in the ARC BIOS document. Arguments passed appear to be arrays of NOOP functions, which take no argument and either return (int) 0 or (void) ... I tried to re-code that initialization sequence in C and have it go before a call of Write(), but with no success. There must be more that I missed, but the code is not easy to follow. (I only used objdump to disassemble the binaries, and the split loading of 32bit constants and addresses does not really make things easier, especially if there are tens of instruction in between ;-) If somebody is interested, I can supply: 1) The binaries I tried to analyze 2) Annotated objdump output > > The specially modified loader you are talking about is ldmilo.exe (instead > > of linload.exe). I don't know if the source is available for that, > > presumably DeskStation still holds the copyright. So it would be best to > > take it up with them. Ahh, yes, ldmilo.exe is one of the two binaries I looked at ... The code I talked about (apparent calls to init functions at undefined vendor vector positions) is not identical but quite similar in both the NT loader and ldmilo.exe. > Since I wasn't the person trying to get things working on this board (it > was Stefan Esser <se@freebsd.org>), I don't know exactly what the firmware > looks like. According to Stefan, it had a completely different look and > feel from AlphaBIOS though. The Samsung UX boots into a setup screen that is quite different from that of an AlphaBios based system. Even the BIOS upgrade functions and required data formats are completely different (not that I think it is a good idea to flash a DEC BIOS on a DeskStation main-board anyway ;-) > I believe that Stefan contacted both Samsung and DeskStation to try to get > programming information with no luck. I think Samsung asked for an NDA and > I'm not sure if DeskStation even replied. Stefan would know for sure; > since I don't think he reads this list, I have Cc'ed him. No, I don't think I'm on the Alpha list, but I guess I should ... I just returned from a vacation, last week, and sent another mail to Samsung and a first one to DeskStation tech-support. Neither of them replied, but it has only been a few days, since. In my first mail to Samsung I had mentioned FreeBSD, but in my mail to DeskStation I just asked about a way to get ADK compliant binaries loaded in an "embedded environment". Seems that many vendors do not consider Linux to be commercially interesting, now, but have no plans at all to support other "open software" projects. And in the case of DeskStation I'm quite sure, that even the sources to ldmilo.exe are considered "confidential" and have not been published. But the required additional startup code could be part of a modified ADK they use, and thus there might be no visible changes to the boot loader. It will just require that (DeskStation private) version of the ADK ... Anyway, I think that the UX is a well designed board (though there was rumour of stability problems in a news-group that I searched for articles that mentioned "Ruffian"). We should be able to support that board and its BIOS (well, I have to ;-) I think we can reverse engineer the missing information from available information (especially ldmilo.exe) and get the ARC start-up code to do the right thing with the UX (i.e. identify it through ARC data structures and only try to invoke the additional code for the UX). Is there any good disassembler (better than objdump. at least ;-) I already spent to much time over the silly output generated by objdump, but might be talked into trying again, if there is a tool that provides me with text that looks more like Alpha Assembler than like GDB output ... Only question is, who can and should do the reverse engineering, mostly for legal reasons. In the EC there is a very strict law against disassembly of code (simplified statement, I know), except for the case, where this is required to "interface to own products". Well, and that appears to be the case here ;-) But the problem with EC law is, that you are not allowed to publish the results of reverse engineering, just use it with your particular product. And that seems to be a problem, if we want to publish sources that are based on the results of reverse engineering. (Not surprisingly, it was the big hardware and software vendors that demanded that ruling.) (I'm no lawyer, correct me if I'm wrong. But it looks like there might be better places in the world, at least as locations for a reverse-engineering project.) I'm currently busy to get all the paper work done for my project, which will keep me busy for another few weeks. (The company just got bought by its biggest competitor, twice our size, and things may change very quickly now. I have got to convince the new management that the project is still worthwhile, and that will require a lot of heavy documents, nobody is ever going to read ;-) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990425113155.A424>