09-26-2012, 04:23 PM | #241 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Thanks @all for the helpful input! I actually got the "unlocking" of the DRAM done, so I can read and write to it from USB downloader mode - it's essentially a copy of yifanlu's / Amazon's commands.
Next problem is: when I try to access it from u-boot, the data isn't there anymore. I'm heavily customizing the u-boot image now to understand what might be happening. I even disabled DRAM initialization in the u-boot code, so that u-boot crashes (hangs) unless the memory had previously been initialized using USB mode. This works "correctly" - in the sense that if (and only if) I initialize the DRAM prior to launching u-boot, the device will actually boot. So since u-boot should not be messing with the DRAM (at least not too much), I don't understand why my data is always getting lost. I tried to put it at the beginning of the DRAM, at the "end", etc - no luck. I'm now even trying to scan the entire address space, because it could just have been "logically" relocated somewhere - no luck either. Hell, all I want to do is
If it was working, this would be the easiest solution to simply upload a kernel and run it, so that we could focus on the actual kernel/initrd (= "almost userland") functionality instead of all the bootstrapping. @eureka: I'll look at the newest links you provided, thanks! @knc1/geekmaster: I looked into the k3launcher thread - actually I read all of it - but I still don't know whether it can also handle K4/K5. In the long run, it would definitely be best to have a single tool which can handle the needs of all devices. For the time being, I'll stick with the imx_usb because I now understand what it is doing and how to use it (this does not go for the Kindle beast though ). Again, any help is more than welcome. |
09-26-2012, 04:52 PM | #242 | |
Carpe diem, c'est la vie.
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
|
Quote:
I am VERY happy to see you doing this. It looks like something I would enjoy hacking on. I want a combined MfgTool/ATK replacement too, even if it is just both tools hacked together, with whichever parts active that the VID/PID says it needs. |
|
Advert | |
|
09-26-2012, 05:24 PM | #243 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
We know that the device comes out of the i.ROM code with a single, 32bit, identity mapped entry. It is very likely that the TLB entries have been changed (perhaps even by the CSF commands you have run) so that the mapping no longer an identity mapping (or might even not be limited to the lower 32bits of the address space). For instance, we know the main DRAM and main flash is relocated to 0x04.... and 0x08.... portions of the 36bit address space. Plus, you may be switching address spaces along the way (out of the supervisory address space). So read the TLB registers before and after "losing" your data. And check what address mode your running in before and after. (Sorry, can't give ARM specifics, now if this was MIPS ...) |
|
09-26-2012, 06:02 PM | #244 |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
@ixtab, well, you're a pioneer, and I now know less than you (in empirical sense), but I can't stand the feeling that U-Boot actions are definitely messing the whole thing. Well, it could just reconfigure DDR clock (with other peripheral clocks, in bunch) in some internal initialization procedure and voila! all data will be lost.
But, again, this is not a confidence or supposition and not even wild guessing (I don't know U-Boot internals at all and don't know whether reconfiguring of DRAM clock is really done and/or will it really erase data). Just feeling. BTW, I could've been wrong at pointing to DDR initialization code and it's calling point. There is following chunk of code in board/imx50_yoshi/flash_header.S : Code:
#ifndef CONFIG_IRAM_BOOT #if defined(CONFIG_LPDDR2) bl lpddr2_init #elif defined(CONFIG_MDDR) bl mddr_init #endif #endif Then, there is Code:
{ .id = "005", .name = "Whitney", .mem_type = MEMORY_TYPE_MDDR, .mem_size = (256 * 1024 * 1024), }, So, it's needed to look after label mddr_init: in board/imx50_yoshi/ram_init.S (but not after lpddr2_init: ). At last, I didn't found relevant CONFIG_MDDR or CONFIG_LPDDR2 defines in yoshi board configs. But at lib_arm/board.c there is mention of dram_init in init_sequence structure. And there is function dram_init at board/imx50_yoshi/imx50_yoshi.c, where MEMORY_TYPE_MDDR define is used (dram_init just calls mddr_init or lpddr2_init). Last edited by eureka; 09-26-2012 at 06:15 PM. |
09-26-2012, 06:31 PM | #245 | |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Quote:
Given that I have been exploring the inner workings of embedded devices for less than 24 hours now, I guess I can be proud of the fact that I understand about 1/3 of this (the english words, that is ). No offense intended - this is just massively overwhelming for someone who never had to deal with the device at that level and is just trying to use it. I'm fine with looking up all the TLAs, but it would really help if you could provide links (or pointers) for those "we know that..." statements. This is exactly the kind of knowledge that is important, and that you have, because you have been dealing with embedded devices for years - but it's almost impossible to find for a newcomer, especially if the documentation spans thousands of technical pages. For two concrete examples: could you please pinpoint the chapters/sections/other material where relocations and address space switching are described? This would be tremendously helpful and very much appreciated - thanks! |
|
Advert | |
|
09-26-2012, 06:49 PM | #246 |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
MMU is disabled before Linux kernel loading on ARM. It's a strict requirement. And bootm command (which has been used by ixtab) is designated for loading Linux kernel, so it's reasonable to not consider any value of TLB registers as sign of problems.
Last edited by eureka; 09-26-2012 at 06:54 PM. Reason: Oh God, I knew so little about meaning of TLB |
09-26-2012, 06:59 PM | #247 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
@eureka:
that's pretty much what I have looked into as well. If you comment out the #define CONFIG_IRAM_BOOT 1 line, you essentially take away all DRAM initialization, so the uboot image will only run correctly if the DRAM had been configured before running uboot (because it will [at least] try to write the kernel to 0x70800000), and it will (rightfully) just crash, because the memory isn't accessible. The question that remains is why the DRAM, if it has been initialized before uboot, is not seen unaltered within uboot. There probably is some other (in this case, unwanted) magic happening between initialization and use - but where? Maybe we'll know better once we understand the relocation stuff... (and yes, maybe avoiding u-boot altogether could be a solution. Then again, u-boot contains all the device-specific initialization that is needed to even make a Kindle come alive at all, so dropping u-boot for something custom is probably not a good idea ) |
09-26-2012, 07:03 PM | #248 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
1) I do not know ARM down to the bit level and arch description. I would have to do the same as any other mortal, look it up in that 3,000+ page technical reference manual. 2) These ARM cores include a MMU (memory management unit). The core comes up in the innermost level of the layers of protected memory spaces (supervisor level - anything goes). To simplify the silicon (in MIPS and ARM) the MMU can not be turned on / turned off once its is initially loaded. The i.ROM code enables the MMU by loading a single descriptor into the TLB (translation look-aside buffer). From then on, all your addresses are virtual, not physical. None of that is much different than the complex instruction set computer that you are probably using every day. A "pc" style computer has a "BIOS" as a legacy of the evolution of the devices from micro-controllers. Other computer systems do not have a "BIOS" in the sense that a "pc" style computer has. They use what is termed a "boot monitor" - common ones being Redboot, U-boot, and manufacturer's variations on the theme. A link to the first thing to grab (at least for its color picture) is the Freescale publication AN3996.pdf. I was wrong, you don't have to sign for it, it is available to everyone: http://cache.freescale.com/files/dsp...ote/AN3996.pdf Yes, I know that doc pertains to the i.MX35 - but the internal (burnt into the silicon) code does not differ in its external behavior enough to matter on the other SoC parts. One thing that does differ on the i.MX31 (DX, DXG) is that SoC has some "program once" internal ROM in addition to the burnt-in code ROM. (and some of the early mask versions burnt-in code errors. Amazon doesn't use those early parts, so toss that into the trivia bin.) I really do not know ARM arch in detail enough other than to give the sort of over-view that I have been providing. Not that I am being difficult, I just know the internals of non-ARM devices in more detail. Last edited by knc1; 09-26-2012 at 07:15 PM. |
|
09-26-2012, 07:07 PM | #249 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
Only DRAM initialization is required (and one UART initialization is desirable if there is a need to look at booting log at serial console). |
|
09-26-2012, 07:22 PM | #250 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Test files
Ah well, attached are the files that I'm using for testing.
There's no point in hiding them away from you, right?(*) The command I'm using to run these is: for i in `seq 1 5`; do cp mx50_usb_work.conf.part$i mx50_usb_work.conf; sudo ./imx_usb; sleep 1; done If at all, I'm only really editing the last file (mx50_usb_work.conf.part5). The reason why these are split into several files stems from yifanlu's code. There originally was a "sleep 10", but one second works fine (*) Note: "development" quality. Hardcoded paths, no explanation, and all that. But I guess you can bear it |
09-26-2012, 07:22 PM | #251 |
Carpe diem, c'est la vie.
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
|
Umm... attached to WHAT? Where?
Last edited by geekmaster; 09-26-2012 at 07:26 PM. |
09-26-2012, 07:23 PM | #252 | |
Going Viral
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
|
Quote:
ixtab described data written to DRAM before loading u-boot as not being able to be found at the same address as after loading u-boot. So yes, looking at the TLB entries would give us some information with which to replace the guesses with. And ixtab is correct, we don't need U-boot to do the DRAM initialization - sending i.ROM a CSF list of address, data, data size will get all of that I/O done before it executes the downloaded application. For instance, the "RAM kernel" (that's en_Freescale for client command processor). It that case the off-chip resources are started by the files sent prior to downloading the "RAM kernel" itself. And we got into this long thread because this suggested alternative code passes "null" for the DCD and then blindly uses some binary objects borrowed from Freescale utiliites. Last edited by knc1; 09-26-2012 at 07:28 PM. |
|
09-26-2012, 07:26 PM | #253 |
(offline)
Posts: 2,907
Karma: 6736094
Join Date: Dec 2011
Device: K3, K4, K5, KPW, KPW2
|
Waaa! Can't you just wait 1 minute before i figure out that .tgz is an invalid file extension, while .tar.gz is accepted ?!
Last edited by ixtab; 09-26-2012 at 07:47 PM. |
09-26-2012, 07:31 PM | #254 |
Carpe diem, c'est la vie.
Posts: 6,433
Karma: 10773668
Join Date: Nov 2011
Location: Multiverse 6627A
Device: K1 to PW3
|
I see you labelled it as "KindleTouch". The K5 DRAM init works for the K4 too.
|
09-26-2012, 07:35 PM | #255 | |
but forgot what it's like
Posts: 741
Karma: 2345678
Join Date: Dec 2011
Location: north (by northwest)
Device: Kindle Touch
|
Quote:
Also note that i.MX3x is based on the ARM11 core (ARMv6 architecture), while i.MX5x is based on the newer Cortex-A8 core (ARMv7 architecture). |
|
Tags |
debricking, kindle mx50 select boot |
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Bricked Kindle Touch; Won't boot into diags/fastboot | kerotan | Kindle Developer's Corner | 3 | 05-19-2012 10:58 AM |
Kindle Touch does not boot | marmomr | Kindle Developer's Corner | 38 | 05-16-2012 01:19 PM |
Kindle Touch select text, copy paste? | Zimmy | Amazon Kindle | 3 | 02-18-2012 08:45 AM |
Kindle Touch Won't Boot | teekay | Kindle Developer's Corner | 3 | 12-10-2011 12:51 AM |
Opus cannot boot, stuck on boot screen | baloma | Bookeen | 35 | 11-13-2010 04:20 AM |