k3flasher, a USB download mode utility

[knc1]

Originally Posted by qlob

Now would probably be a good time to mention that I deleted the other kernel because I thought we didn't need it... whoops....

Its back now.

Oh, and take a look-see if that dump script was able to create any of the various files.
You might have gotten at least part of something.

[knc1]

#define MX35    4
#define MEM_BASE_ADDR    0x80000000
#define MEM_BOTTOM_ADDR    0x87FFFFFF
/* watch dog registers */
#define WDOG_BASE_ADDR    0x53FDC000
#define WDOG_WCR    (WDOG_BASE_ADDR)
#define WDOG_WSR    (WDOG_BASE_ADDR + 0x2)

and even with those pretty defines, the magic addresses are hard coded (again):

#define WD_TIMEOUT 0x20
static void inline watchdog_service(void)
{
    if (*(volatile u16 *)0x53FDC000 & 0x04) {
        *(volatile u16 *)0x53FDC002 = 0x5555;
        *(volatile u16 *)0x53FDC002 = 0xAAAA;
    }
}

and then we have a little programmed delay loop (on a variable clock speed device):

/*!
 * delay
 */
static void delay(void)
{
    int i;
    for (i=0;i<300;i++) {
    } 
}

And this thing could be made a lot more reliable:

/*!
 * Function to send data to host through channel
 *
 * @buf  buf to send
 * @count  send data size
 *
 * @return 0
 */
u32 atk_channel_send(const u8 *buf, u32 count)
{
    u32 size;
    u32 i;
    u32 to = WD_TIMEOUT;
    usb_buffer_descriptor_t  buf_desc;
    usb_status_t status = USB_FAILURE;

    if (channel == CHAN_USB) {
        
        watchdog_service();
        while (count) {
                     
            size = count > BULK_BUFFER_SIZE ? BULK_BUFFER_SIZE : count;
            /* FIXME: if the buffer is messed by the USB, use static buffer arrary */
            buf_desc.buffer = (u8 *)buf;
            buf_desc.size = size;
            buf_desc.bytes_transfered = 0;
            status = (usb_status_t )tl_send_data(&buf_desc);

            count -= size;
            buf += size; /* update buffer addr */
            if (--to <= 0) {
                watchdog_service();
                to = WD_TIMEOUT;
            }
        }
        
    } else {

        watchdog_service();
        for (i = 0; i < count; i++) {
            delay();
            /* put data to UART transmit fifo */
            uart_putchar(buf[i]);
            /* wait for TF empty */
            while (!(*(volatile u32 *)UART1_USR2_1 & 0x4000)) {
                if (--to <= 0) {
                    watchdog_service();
                    to = WD_TIMEOUT;
                }
            }
            if (--to <= 0) {
                watchdog_service();
                to = WD_TIMEOUT;
            }
        }
    }

    return 0;
}

Somewhere in the reading, Freescale wrote that this ATK code wasn't for "production use".
It does begin to look like we will have to build our own.

At least the license allows us to make derivatives and distribute them in object code form for use on "licensed i.MX devices".

On the "up side" - all of the defines and most of the code to use the OTG port looks like it is in the ATK source code.

[geekmaster]

That "delay loop" with no body would get optimized out. It should minimally do a sleep call, preferably timer based. Very amateur, even for "non-production" code.

However, I am very happy to have even "mostly working" code as a guide to get us started on this new path of development.

Those signed compares such as <=0 are bad practice on u32 numbers.

In the code shown above, serial I/O services the watchdog timer every character, but USB only services it every 32 packets. That seems awfully long, especially if not on a USB 2.0 port. I would try 8 packets instead, or perhaps even every packet just to be safe (especially if you are using a USB mass storage device on your host PC, which could suck a lot of shared USB bandwidth).

[knc1]

Sounds like good suggestions to me.

Plus, a USB transfer can "stall" or "delay", it can't be assumed it is a continuous stream. So in real life, outside of the Freescale lab, that routine may be even less reliable than you suggest.

I didn't quote the "write" routine but it has the same problems.

If this really has to be done, why not a bit of design change tossed in?
Set aside a few words of iRAM for a "parameter area" of critical values like the counts and watchdog settings.
Then those could be "poked" from the host to "tweak" the timing of things rather than re-building the RAM kernel.
Just like GM was hoping that Freescale had done to begin with in an earlier post.

Let me see now, how could that be made to work while the system was running ...
There are two watchdog values and at least two counter values ...
Set aside 8 u32 words; 4 + 3 "to be discovered" + 1 simple checksum.
If the all 8 words sum to zero (or other known value) then the first 7 values are valid and the run-time copies can be updated.
If they don't, then they have never been set or are in the process of being changed and the run-time copies are not modified.

For the host, that means poking all eight values, the checksum value last.
For the client (Kindle RAM kernel) that means summing 8 words and testing for 0. It should be able to do that even during a high speed transfer with the slowest of clocks.

Thoughts on that any one?

Has anyone read the SoC hardware manual? Does the SoC have another hardware counter/timer that we could use in place of that programmed delay loop?

What I saw in that routine was I think what GM saw in it - -

The watchdog is not testing for a "hung kindle side code" it is testing if the outside world can transfer xyz USB packets in time.
And in real life, you just can't count on the outside world to behave.

I am not all that certain about that watchdog service routine - -

Why the test? Why the counter? The ARM is a load/store machine, it can't take all that much time to poke two memory register values **every pass**.

We could get extra ambitious and see if we can fix the i.MX31 problem also. Just in case anyone ever discovers how to put a DX(G) in USB downloader mode.

[knc1]

@GM : I PM'd you the access details for the "my k3 is broke" kloud.

[knc1]

@qlob : Don't try to re-flow the solder just yet. This is certainly a firmware error.

Trivia:
While reading the specs on a 3G card (same assembly method) I saw it was rated to withstand a one-time shock of 5,000Gs in any direction.
????
Oh, it was also listed as an automotive part - -
Nice to know that your car can still call on-star with the details of where to send the mop & sponge clean-up crew after a 5,000G collision.

[knc1]

Originally Posted by knc1

@GM : I PM'd you the access details for the "my k3 is broke" kloud.

Because this "RAM Kernel" code can use all of the opinions and consulting it can get while at the same time respecting Freescale's "don't publish this" license.

This way everyone can be looking at the same code and reference materials.

This source (1.71) handles the i.MX 25, 27, 31, 32, 35, 37, 51 and 53 (no mention of the 503 - but maybe it only needs a loader script).

I plan to start by pulling the existing client code (device_program/*) out of that VC project build system and getting it to build like any other Linux glob of code.

[geekmaster]

Originally Posted by knc1

Because this "RAM Kernel" code can use all of the opinions and consulting it can get while at the same time respecting Freescale's "don't publish this" license.

I just installed konquerer. Apparently the Freescale license lets us publicly distribute modified binaries, but not modified source code. So this private repo would be needed to honor the Freescale license requirements. Thanks for sharing with invited "team mates".

[hawhill]

I really can't help much, you're now officially a few steps ahead of me on this matter :-) I need the last two weeks of my vacation time badly so I can work on some of these issues....

qlob: [[The "wrong transfer length" errors are in most cases irrelevant. I just was a bit too lazy to make the error more verbose.]] Edit: sorry, that was a bit hasty. I misread -- of course, those errors would be irrelevant if they would indicate that the RAM kernel is running (receiving 8 bytes instead of 4 bytes), but the other way around it means that it is dropping out of the RAM kernel mode over and over again. But that's what the posts of knc1+geekmaster are about.
The disappearing USB device is a bummer, though -- but I think knc1 and geekmaster are right on track here, the culprit might be the RAM kernel.

I do agree, most of the code of ATK I looked at didn't really feel like production-grade code. On the other hand, a lot of existing production-grade code doesn't feel like such either :-)

As a last short note, before I will be able to contribute something more important: I was in most cases using the RAM kernel from ATK 1.67. Not sure if it changed at all from there on, though.

[knc1]

@Hawhill I don't expect to make any protocol changes, just do code clean-up of the "RAM kernel".

I will PM you the access details so you can stare at the same references we are looking at in your free time.

Consulting opinions are welcome - this is one piece of code that needs to "be right".

[knc1]

Originally Posted by geekmaster

I just installed konquerer. Apparently the Freescale license lets us publicly distribute modified binaries, but not modified source code. So this private repo would be needed to honor the Freescale license requirements. Thanks for sharing with invited "team mates".

Yeah, it is sort of like a "private label GPL" they get rights to any of your changes and you have keep copies of the changes available for 5 years.

But there have been enough recent: "My K3 is broke" reports that I guess I can learn to live with that (since I have a K3 myself).

[geekmaster]

Originally Posted by knc1

Yeah, it is sort of like a "private label GPL" they get rights to any of your changes and you have keep copies of the changes available for 5 years.

But there have been enough recent: "My K3 is broke" reports that I guess I can learn to live with that (since I have a K3 myself).

I did not read the license (yet). Can the modified source be published openly or not (with their license included)? Or is there some restriction about registering at their website and downloading the original source from them and modifying it yourself?

[hawhill]

A short addendum: In k3flasher, I do the "mDDR init limbo" - as a straight reimplementation of what ATK does. That said, I never looked into the SoC reference manual to actually look up _what_ they are doing there. It might be that the timing they use is specifically suited for Freescale's iMX development board, but needs to be just a tad bit different for a Kindle - so what we experience here is a RAM running a bit out of its specified timing (which might work or not). This is just poking with a stick in the dark, however.

[knc1]

Originally Posted by hawhill

A short addendum: In k3flasher, I do the "mDDR init limbo" - as a straight reimplementation of what ATK does. That said, I never looked into the SoC reference manual to actually look up _what_ they are doing there. It might be that the timing they use is specifically suited for Freescale's iMX development board, but needs to be just a tad bit different for a Kindle - so what we experience here is a RAM running a bit out of its specified timing (which might work or not). This is just poking with a stick in the dark, however.

Worth taking a look at, once we have "clean code" in the RAM kernel.
Thanks for the suggestion, we should be able to get the DDR settings out of the U-Boot source or out of the DDR rom.

[geekmaster]

The freescale license agreement:
http://www.freescale.com/webapp/sps/..._TOOL_STD_1_67

This is of particular interest:

PUBLIC SOFTWARE RESTRICTION. Your license rights to the Freescale Software are conditioned upon your not using the Freescale Software with other software which was not provided by Freescale hereunder when such other software is licensed pursuant to terms that directly or indirectly (i) create, or purport to create, obligations for Freescale or it’s licensors with respect to the Freescale Software or derivative work thereof or (ii) grant, or purport to grant, to any third party any rights or immunities under Freescale’s or its licensor’s intellectual property or proprietary rights in the Freescale Software or derivative work thereof. Such other software includes, without limitation, any software that requires as a condition of use, modification and/or distribution of such software that other software incorporated into, derived from or distributed with such software be (i) disclosed or distributed in source code form; (2) be licensed for the purpose of making derivative works; or (3) be redistributable at no charge.

It sounds like they forbid mixing it with GPL (except under careful conditions, such as called in a script file).

And of course, what knc1 mentioned:

CONFIDENTIAL INFORMATION. The Freescale Software will be treated by you as confidential information and you agree to retain the Freescale Software in confidence perpetually for with respect to Freescale Software in source code form (human readable), or for a period of 5 years from the date of termination of this Agreement, with respect to all other Freescale Software. During this period you may not disclose the Freescale Software to others than employees or contractors who have a need to know of the Freescale Software and who have executed written agreements obligating them to protect such Freescale Software. You agree to use the same degree of care, but no less than a reasonable degree of care, with the Freescale Software as you do with your own confidential information. You may disclose Freescale Software to the extent required by a court or under operation of law or order provided that you notify Freescale of such requirement prior to disclosure, that you only disclose information required, and that you allow Freescale the opportunity to object to such court or other legal body requiring such disclosure.

Which says you can only share the source code with others who have agreed to the freescale license agreement (electronically or in writing). In otherwords, you can share your modified freescale software source code with people who COULD download the original source code from freescale.com using their own freescale login account.

But if you read the rest of the license agreement, it appears that we are free to publicly distribute the modified binary executable at no charge. At least that is how I see it.