How to erase a faulty flashbank ? - Hewlett Packard

This is a discussion on How to erase a faulty flashbank ? - Hewlett Packard ; On Sat, 10 Nov 2007 22:15:13 -0600, Claudio Lapilli kindly wrote: > most DOEXTn are still unused When considering ability to "dispatch" on object type, I see at most one free type, now that Font, Minifont, and Integer types have ...

+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast
Results 41 to 60 of 66

Thread: How to erase a faulty flashbank ?

  1. Re: ARMCODE object

    On Sat, 10 Nov 2007 22:15:13 -0600, Claudio Lapilli kindly wrote:

    > most DOEXTn are still unused


    When considering ability to "dispatch" on object type,
    I see at most one free type,
    now that Font, Minifont, and Integer types
    have each claimed a prolog
    which might have been free on 48 series:

    Object Dispatch Type Codes (for 49/50 series)

    1 % 7 LAM D TAG 4F C%% AF LDT
    2 C% 8 ::; E UNIT 5F L[] BF ACP
    3 $ 9 ALG 0F ROMP 6F CHR CF FON
    4 [] A SYC 1F # 7F COD DF MFO
    5 {} B HXS 2F RRP 8F LIB EF EX4
    6 ID C GRO 3F %% 9F BKP FF INT

    So is it dispatched as #EF (EX4)?

    > [on unmodified ROMs]
    > It will push the contents on the stack,
    > just like a regular non-executable object.


    > [on unmodified ROMs]
    > No issues with SKIPOB, since this object exists since the 48 series.


    Something has to tell SKIPOB how to determine the object's length,
    and this must have existed, the same way, before your new definition,
    or else there would be a problem on any unmodified ROM.

    "all RPL objects can be copied, compared, embedded in composite objects,
    and skipped. The latter property implies that the memory length
    of any object is predetermined or can be computed from the object.
    For atomic objects such as real numbers, the size is invariant.
    For a more complicated atomic object such as a numerical array,
    the size can be computed from the array dimensions
    that are stored in the body of the array object.
    (RPL arrays are not composite--the elements do not
    have individual prologues and hence are not objects.)
    Composite objects may include a length field
    or they may end with a marker object." [RPLman.doc]

    So, what is the structure of this object?
    Is it the same structure as a CODE object?
    Did the replaced object have that same structure?
    (and means of determining its length?)

    > The object can be embedded in lists and sysRPL programs,
    > and any other composite object without problems.


    Certainly so, in your modified ROM,
    but I'm still wondering about unmodified ROM,
    which sooner or later is going to come up,
    when people load something requiring a modified ROM
    into an unmodified ROM.

    If there turns out to be any problem with that,
    then it would be ideal if authors who use ARMCODE objects
    have a way to detect whether the calculator can support them,
    and to make sure if not that it won't attempt to use them,
    if at all possible, much as an HP48
    recognizes incompatible HP49/50 binary objects as "foreign,"
    and avoids transferring them from a computer or another calculator.

    Is there some harmless test which can detect whether a calculator
    contains a ROM which supports ARMCODE objects (and other features
    which you might be adding)?

    >> What type will CK&DISPATCHx etc. consider it to be?

    > DOEXT4 prolog, shown as EXT3 in MASD.


    Dispatch type #EF ?

    > I gave it the name ARMCODE,
    > and it shows the string "ARM/C Code" when pushed on the stack
    > (it will show "External" on a machine that doesn't have hpgcc3 installed).


    As to stack display, so do TRUE and FALSE (and almost anything

    How about when flag -85 is set?

    What does \->S2 make of it (with and without flag -92 set)?

    Thanks!

    [r->] [OFF]

  2. Re: Does xSTO handles storing in Port 2 properly ?

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    TW wrote:

    <..>

    >> But selling it as *closed source* without making available the complete
    >> sources violates the GPL, that's the point.

    >
    > They are there for download with the updates, and they are on a hard
    > medium of every unit that ships. What is in violation?


    Maybe you have to learn to read carefully.
    I just visited your web site and inspected the update zip.
    Included in it are three C files and the GPL text.
    Is that what you call conforming to the license terms ?
    I tell you, that it's not and therefore you have violated the HPGCC
    license, on which you agreed by using the HPGCC libraries and
    infrastructure utilities.

    Some folks might be bored to read this all over again, but obviously it
    has not yet reached it's destination ( yes, that is *you* TW )

    < quote from the hpgcc.org web site >

    This entire project, including the libraries, is released under the GPL.
    Under the terms of the GPL, you are required to release any software
    that uses these libraries under the GPL as well.

    Understandably, a large number of developers would prefer to keep their
    source code private. To solve this issue, additional rights are granted
    to non-profit developers. For non profit use only, you may use HPGCC
    without putting your code under the GPL



    We agree that this NG is not the right place to discuss license
    internals and disputes arising from them. So you are probably well
    advised to contact me my email.


    - --
    Ingo Blank

    http://hpgcc.org
    http://blog.hpgcc.org

    To reply by email, please substitute "spam" with my first name in the
    reply-to address.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFHOOhDr9bi0BQTf30RAs7eAKCcVFTWhVTqH21z6/OqzO4ubPiV/ACeM8KY
    0rVLFF/+tnpOvCfcBQz9p8w=
    =Bp/h
    -----END PGP SIGNATURE-----

  3. Re: Does xSTO handles storing in Port 2 properly ?

    "Ingo Blank" wrote:
    > Maybe you have to learn to read carefully.
    > I just visited your web site and inspected the update zip.
    > Included in it are three C files and the GPL text.
    > Is that what you call conforming to the license terms ?
    > I tell you, that it's not and therefore you have violated the HPGCC
    > license, on which you agreed by using the HPGCC libraries and
    > infrastructure utilities.


    Ingo,

    Before you publicly chastise others, please remember that the GPL simply
    requires that the source be made available. It doesn't say it has to be
    included with the download, even though that is a common practice. Notice
    that it is also acceptable to provide the full source code upon request.

    Also, Tim may still be obeying the GPL by your very narrow interpretation.
    To the best of my knowledge, you have not purchased their product.
    Therefore, how do you know that they don't include the full source code with
    the product, and the updates include only the updated source files to
    minimize the download size? In other words, the updates are simply a patch,
    both to the binary application and to the source code. This appears to be
    what Tim is doing, and it fully meets the spirit of the GPL.

    I am not a lawyer, but my advice to Tim here is that he make the download of
    the update.zip file password-protected so it is only available to those who
    have purchased the software. I think we can consider the current public
    existence of update.zip to be inadvertent and not an intentional public
    release.

    Regards,

    Eric Rechlin




  4. Re: ARMCODE object

    On Nov 12, 6:26 pm, "John H Meyers" wrote:
    <...>
    >
    > So is it dispatched as #EF (EX4)?


    Yes, I just checked, and it's 0xEF, according to OT49+.


    <...>

    > Something has to tell SKIPOB how to determine the object's length,
    > and this must have existed, the same way, before your new definition,
    > or else there would be a problem on any unmodified ROM.


    <...>

    > So, what is the structure of this object?
    > Is it the same structure as a CODE object?
    > Did the replaced object have that same structure?
    > (and means of determining its length?)


    The object behaves like ZINTS, HXS, CODE, etc. objects. There's a 5-
    nibble offset to the end of the object immediately after the prolog. I
    didn't define this, it was always there from the 48 series.

    And that should answer all your other concerns as well.

    <...>
    > How about when flag -85 is set?


    I wanted to change that too, to decompile as ARMC 00005 00000, etc. I
    got decompilation working, but I was unable to change the compilation
    in MASD (MASD data is BZ compressed or something like that), so I had
    to leave it unchanged. MASD will show EXT3.

    Claudio


  5. Re: Does xSTO handles storing in Port 2 properly ?

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Eric Rechlin wrote:

    > Ingo,
    >


    <...>

    > To the best of my knowledge, you have not purchased their product.
    > Therefore, how do you know that they don't include the full source code with
    > the product, and the updates include only the updated source files to
    > minimize the download size? In other words, the updates are simply a patch,
    > both to the binary application and to the source code. This appears to be
    > what Tim is doing, and it fully meets the spirit of the GPL.
    >


    Yes, that's a very prudent thought.
    If I understand you correct, I should have some professional act as a
    test buyer?
    Let's hope your assumption is correct.


    - --
    Ingo Blank

    http://hpgcc.org
    http://blog.hpgcc.org

    To reply by email, please substitute "spam" with my first name in the
    reply-to address.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFHOP0Cr9bi0BQTf30RAmXNAJ90DqGdk2Qn6BWaml28co xQw4zM8gCglb5b
    i/oMv24UV0YTY+0J+25jV9k=
    =aPV1
    -----END PGP SIGNATURE-----

  6. Re: ARMCODE object

    Thanks a bunch, Claudio.

  7. Re: Does xSTO handles storing in Port 2 properly ?

    Hi

    On 2007-11-09 03:45:57 +1100, "manjo" said:
    >
    > If and when somone whould take care to write such garbage
    > collector/defragmenter
    > care should be taken to keep the files on aligned addresses.


    AFAIK, there is such collector/reorganisation in the flash when it is required.
    Cyrille's work

    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  8. Re: Does xSTO handles storing in Port 2 properly ?

    Hi
    On 2007-11-09 12:43:13 +1100, "manjo" said:
    > Very nice,
    > Good work !!! :-)
    > so you're actualy sugesting we would use flash for code and RAM as
    > variables (data) segment and temporary memory allocation/use.
    > -i belive i can live with that



    please note that for a while ; whenever you store something in flash ;
    space is added so it can be aligned easily to a 32 bits address.

    one of the first thing we thought of.


  9. Re: Does xSTO handles storing in Port 2 properly ?

    Hi

    On 2007-11-12 12:13:05 +1100, Ingo Blank said:

    >
    > I believe your own legal issues with selling GPL protected software,
    > which is using the HPGCC libraries, are reason enough to worry.


    Ouch with the venom !!

    You seem to confuse what GPL is all about.
    It's not about free as in "free beer" but free as in Freedom.

    You can do GPL software and sell it ; What do you think RedHat business
    is all about ?

    Tim has complied with the term of the GPL by releasing the source code
    of his application that is using HPGCC library.

    I thought this issue had been sorted out a while ago.

    >
    > There are no obvious reasons by the way, why we would consider to
    > discuss legal or other things regarding HPGCC3 with you or in a public
    > forum.



    Re-distributing a patched ROM ; without the proper okay from HP will
    attract you serious problems. HP is very touchy about this. For once
    it's an obvious copyright infringement.

    Jean-Yves


  10. Re: Does xSTO handles storing in Port 2 properly ?

    Hi
    On 2007-11-11 06:42:19 +1100, Ingo Blank said:
    'FACT.EX3' calculates 5000! with 16326 significant digits in ~1.8 sec.
    > The executable's size is exactly 472 bytes.
    >
    > Something better, anyone ?



    Looking forward to this noew hpgcc3 ; would be happy to test it too.

    Currently, the smallest program I can make is about 24kB ; and that's
    for a two lines source code !

    Jean-Yves


  11. Re: Does xSTO handles storing in Port 2 properly ?

    > > If and when somone whould take care to write such garbage
    > > collector/defragmenter
    > > care should be taken to keep the files on aligned addresses.

    >
    > AFAIK, there is such collector/reorganisation in the flash when it is

    required.
    > Cyrille's work


    Of course, respect to Cyrille ! :-)
    it would be nice if it would recognise and respect the new ARMCODE object
    type
    and align properly.

    The idea i had for MASD and ARM programs in RAM
    different approach for new ARM based objects :
    SystemRPL command similar to TakeOver would be introduced which would
    indicate the garbage collector and flash defragmenter to keep the object on
    aligned address.

    inside that object at some point there could be ARM data or code with ARM!
    pseudo opcode
    MASD would align relative to object start thus ARM data or code would always
    be on 32bit
    aligned address that way it would available for access and executed directly
    in ARM domain.

    --
    manjo
    http://fly.srk.fer.hr/~manjo/openfire
    | 49G+ | ROM 2.09 | hw serial:CN40213309 | sw serial:CN40701165 |



  12. Re: Does xSTO handles storing in Port 2 properly ?

    On Nov 13, 7:45 pm, "manjo" wrote:
    <...>

    > Of course, respect to Cyrille ! :-)
    > it would be nice if it would recognise and respect the new ARMCODE object
    > type
    > and align properly.


    But it's already done! Maybe I wasn't clear, but I already added a
    hook for automatic alignment when storing an object in flash, and
    another hook for automatic realignment during bank repacking. So
    ARMCODE objects are stored with the proper alignment by simply
    installing it in flash. And if the flash is ever reorganized, code is
    kept aligned.

    Claudio


  13. Re: Does xSTO handles storing in Port 2 properly ?

    On Nov 13, 7:03 pm, JYA wrote:
    > Hi
    > On 2007-11-09 12:43:13 +1100, "manjo" said:
    >
    > > Very nice,
    > > Good work !!! :-)
    > > so you're actualy sugesting we would use flash for code and RAM as
    > > variables (data) segment and temporary memory allocation/use.
    > > -i belive i can live with that

    >
    > please note that for a while ; whenever you store something in flash ;
    > space is added so it can be aligned easily to a 32 bits address.
    >
    > one of the first thing we thought of.


    Unfortunately, C requires non-relocatable code to be 100% compliant
    with static pointers, and therefore needs page-aligned code. We
    couldn't take any advantage of automatic word-alignment, but assembler
    programmers may.

    Claudio


  14. Re: Does xSTO handles storing in Port 2 properly ?

    JYA wrote:
    >
    > With our EDGE code for example ; our math libraries are compiled
    > completely without using any of the hpgcc library.
    >
    > The code that make it work on the HP50 are using hpgcc libraries ; as


    Does EDGE code finally link with the hpgcc code to make it work? If so, then
    techincally, if EDGE is not GPL'ed, then the act of running EDGE (linking
    everything) voilates GPL.

    > such the source code of that wrapper is distributed with the program.
    > Does that force our math library to be distributed under the GPL ?
    > certainly not. why should it?


    Because that would be the conditions of linking to the GPL code. If you
    don't like it, then you should not use the GPL code - end of story.

    If I understand correctly....

    The wrapper must link with hpgcc, so it must be GPL'ed. EDGE must link
    with the wrapper, which is GPL'ed. If EDGE can exist stand alone without
    the GPL'ed wrapper, then it doesn't need to be GPL'ed. *However*,
    the act of the user installing and running EDGE would violate GPL. So, it
    is kind of a ****ty way of violating GPL since the final intent is to link
    to a GPL library.

    nVidia pulls this trick of a wrapper for their kernel modules (drivers in
    Windows speak), violating GPL. But, luckily no one complains because most of
    us are just happy they are supporting Linux.

    - Kurt

  15. Re: GPL and hpgcc

    Hi

    On 2007-11-14 14:52:35 +1100, ~kurt said:
    > Does EDGE code finally link with the hpgcc code to make it work? If so, then
    > techincally, if EDGE is not GPL'ed, then the act of running EDGE (linking
    > everything) voilates GPL.



    EDGE is a math library.
    it works on all platform and has been linked on pretty much all
    platforms we have access to (we have prototype on mac, windows, linux,
    bsd, ti nspire and hp50). it exists on its own and make no use of any
    of the hpgcc code.
    It is written in C++ and do need a standard C,C++ and libm libraries (I
    use newlib on the hp50)

    > Because that would be the conditions of linking to the GPL code. If you
    > don't like it, then you should not use the GPL code - end of story.
    >
    > If I understand correctly....
    >
    > The wrapper must link with hpgcc, so it must be GPL'ed. EDGE must link
    > with the wrapper, which is GPL'ed. If EDGE can exist stand alone without
    > the GPL'ed wrapper, then it doesn't need to be GPL'ed. *However*,
    > the act of the user installing and running EDGE would violate GPL. So, it
    > is kind of a ****ty way of violating GPL since the final intent is to link
    > to a GPL library.


    EDGE only need to link with the GUI/wrapper to return its result. This
    is not done using any of the hpgcc code nor is the memory allocation
    (we link against newlib for this)

    if that is indeed the case, you could very well change the way the code
    is linked.
    Rather than linking all the parts alltogether you use reference
    pointers from the GUI (the wrapper) to the library using static
    pointer. Just like calling code with system.

    As such , both are compiled independantly, and the EDGE library do not
    rely on the HPGCC code in
    anyway.

    Your interpretation of the GPL is I believe incorrect. Otherwise it
    would mean for example any code compiled with gcc must be GPL'ed.
    Pretty much all code compiled with gcc is linked with their crt.s
    program , which itself is GPL.
    it doesn't make your compiled code GPL'ed.

    My intention is to release the source code of everything that is
    specific to the HP50: reading arguments from the stack, drawing the
    graph, managing the keyboard etc...
    but not of our math library (which will be a commercial product)

    >
    > nVidia pulls this trick of a wrapper for their kernel modules (drivers in
    > Windows speak), violating GPL. But, luckily no one complains because most of
    > us are just happy they are supporting Linux.


    I certainly only buy nvidia card for that exact reason... ATI do not
    work well enough with linux

    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  16. Re: Does xSTO handles storing in Port 2 properly ?

    On 2007-11-14 14:52:35 +1100, ~kurt said:

    >
    > Because that would be the conditions of linking to the GPL code. If you
    > don't like it, then you should not use the GPL code - end of story.



    From the gnu.org web site :
    "As usual, the GNU GPL does not restrict what people do in software, it
    just stops them from restricting others."

    Also:
    http://www.gnu.org/licenses/gpl-faq....ortProgramToGL

    --
    They who would give up an essential liberty for temporary security,
    deserve neither liberty or security (Benjamin Franklin)


  17. Re: GPL and hpgcc

    Hi

    After a careful and long review of the GPL and their FAQ, I believe my
    case fall under what is explained there:

    http://www.gnu.org/licenses/gpl-faq.html#FSWithNFLibs
    http://www.gnu.org/licenses/gpl-faq....compatibleLibs

    It is my intention that the EDGE demo grapher will be free to use.

    We just fall under the case of writing free software, using a free
    library but using a non-free license.

    Jean-Yves


  18. Re: GPL and hpgcc

    JYA wrote:
    >
    > Your interpretation of the GPL is I believe incorrect. Otherwise it


    I'll admit interpretation plays a big role in it - use of the GPL for
    a library leads to some contradictions in my opinion. The use of
    GPL for an application, and LGPL for a library, is fairly straightforward.

    > would mean for example any code compiled with gcc must be GPL'ed.
    > Pretty much all code compiled with gcc is linked with their crt.s
    > program , which itself is GPL.
    > it doesn't make your compiled code GPL'ed.


    gcc is GPL'ed. glibc, the GNU standard C library, is LGPL'ed. Yes, you
    can use a GPL'ed program to create non-GPL'ed products. And, you can use
    a GPL'ed compliler to create non-GPL'ed applications because they link to
    non-GPL'ed libraries (such as the LGPL'ed glibc). The LGPL was designed for
    libraries, and does not restrict what type of license can be used to link to
    it. Unfortunately, the Free Software Foundation has been discouraging the use
    of LGPL since open source has gained so much momentum. I believe the use
    of GPL'ed libraries over LGPL'ed ones leads to nothing but problems and
    confusion, as we can see here (and only helps support Microsoft's propaganda
    that open source is nothing but a virus that destroys intellectual property).

    The question here is if the hpgcc libraries are GPL'ed, or LGPL'ed. If they
    are LGPL'ed, then there is no issue at all. hpgcc could be used to compile
    and link a completely closed source proprietary application. If the libraries
    provided are GPL'ed, then it would violate the GPL to compile and distribute
    a version that is built to work with the hpgcc libraries. It would not
    matter if a wrapper was used. I'm guessing EDGE needs to be compiled with
    hpgcc in this case? If not, and if only the wrapper needs to be compiled
    with hpgcc, then, technically, I think it does not violate GPL.

    GPL doesn't really seem to restrict what the end user can do (individual,
    corporation, government, etc...). It only affects those who redistribute
    the code. So, assuming the libraries EDGE needs on the HP are GPL'ed, and
    assuming EDGE is a stand alone application that works on many platforms, a
    user can install hpgcc, and EDGE, run it - and technically there should be no
    legal issues even though the FSF would claim it violates the spirit of GPL.
    However, if an EDGE package was distributed with the intent of running
    on a HP, and there is no alternative but GPL'ed libraries supplied by hpgcc,
    then I'm sure a case could be built against such distribution. That would
    be where the judge comes in to interpret the law.

    This entire mess exists because a library is distributed under GPL instead
    of LGPL.

    - Kurt

  19. Re: GPL and hpgcc

    JYA wrote:
    >
    > EDGE only need to link with the GUI/wrapper to return its result. This
    > is not done using any of the hpgcc code nor is the memory allocation
    > (we link against newlib for this)


    OK, I re-read this. I take it only the wrapper is linked using hpgcc and
    its associated libraries, and EDGE doesn't link against any of this when
    compiled.

    Given the hpgcc libraries appear to use GPL, I don't think there is an
    easy answer.

    When run, everything dynamically links, and is considered a single application
    by the FSF. By the GPL, everything that links to it should be GPL'ed.
    If the end user installs EDGE, the wrapper, and hpgcc, and runs this,
    this doesn't really violate the GPL as I have read it because the end
    user is not distributing the code. But, as I said in the previous message,
    a case could probably built if a package was made specifically for the HP.
    Basically, someone would have to get a bug up their ass about it, take
    it to court, and then see what the judge says.

    I'm more curious now - I'll have to go back and re-read the license, and
    go through the FAQ tomorrow. This actually makes me feel better about
    choosing LGPL for a library I'm working on - its use is very straighforward
    and much more free in my opinion....

    - Kurt

  20. Re: GPL and hpgcc

    On Nov 14, 4:06 am, ~kurt wrote:
    <...>

    > Given the hpgcc libraries appear to use GPL, I don't think there is an
    > easy answer.


    The answer is much easier than you think. Read HPGCC license again.
    There's clearly an exception that says the GPL restrictions don't
    apply if you release the software for free. As long as the program for
    the calculator is not sold, there's no GPL infection problem. As
    simple as that.

    End of discussion.
    Claudio



+ Reply to Thread
Page 3 of 4 FirstFirst 1 2 3 4 LastLast