DIY - KeK

[knc1]

It will be nice when we get a few more people to take an active part in this thread.

But "working in public" is not suited to just anyone -
Like "dancing naked on the beach" isn't suited for just everyone.
(naked != suited) I made a joke, but did not intend to, need more coffee.

[twobob]

Originally Posted by knc1

The other "gotcha" - There is something about multiple mount points of the same (loop) device that isn't working correctly.

So don't mount the system image outside of the emulator while QEMU has it mounted inside of the emulator.
I.E: exit the emulator before:
sudo mount -o loop hdb.img /mnt/hdb
When you want to read/write things into/out of the /home image file.

Just to spare someone asking howto run e2fsck on the image:
sudo losetup /dev/loop1 hdb.img
sudo e2fsck -f /dev/loop1
sudo losetup -d /dev/loop1

Yeah, actually now I dig some more Qemu more or less states this in
http://en.wikibooks.org/wiki/QEMU/Im...ge_on_the_host

Under the tiny caveat 'NB: never mount a QEMU image while QEMU is using it (unless -snapshot is used), or you are likely to corrupt the filesystem on the image.'

Sneaky little message. One might have thought BOLD would have been a good choice

[knc1]

Using an NFS export for the main file system will "fix" that problem.
The NFS system is intended to handle multiple mounting gracefully at the server end.

Similar to our WEBdav::kloud - which looks like a remote (or local) directory but is really a MySQL database with a funny (for MySQL) looking view showing.
In the "background" the MySQL server is handling concurrent activity with locked transactions.

[twobob]

Originally Posted by knc1

... need more coffee.

Now that is the best idea I have heard all morning.

*goes about beverage imbibing*

[twobob]

Originally Posted by knc1

Using an NFS export for the main file system will "fix" that problem.
The NFS system is intended to handle multiple mounting gracefully at the server end...

Hmm yeah. now if only I could get qemu to swallow it.. hrmmm

[twobob]

And it died again.

me@dev ~/BLDS/buildroot $ qemu-system-arm -M versatilepb -kernel /home/me/BLDS/buildroot/images/zImage -hda ./images/rootfs.ext2 -nographic
oss: Could not initialize DAC
oss: Reason: No such file or directory
audio: Failed to create voice `lm4549.out'
Uncompressing Linux... done, booting the kernel.
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf000f0)
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf0)
qemu: terminating on signal 15 from pid 3243

I think this may be a known issue... reading around.

Spoiler:

http://www.spinics.net/lists/arm-kernel/msg177442.html <-- this one perhaps
OR:
(err it's in Chinese so perhaps just trust me http://www.eetop.cn/blog/html/49/t-224249.html)
here's and autotranslation of 3 very helpful techniques I thought
http://translate.google.com/translat...Ft-224249.html

and here http://lists.gnu.org/archive/html/qe.../msg03452.html

looks like I need to patch qemu for versatile flash support.

now just need to find the right patch.
EDIT:
http://thomas.enix.org/pub/qemu-vers...-flash-support
versatilepb-add-flash-support | patch-p1

from the list here: http://thomas.enix.org/pub/qemu-vers...ash-emulation/ but I'm not sure if this is still current yet

It's never simple ey : )

now where did you leave that building Qemu from source there AH HERE

diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c
index 4ae4fc8..aeb7b60 100644
--- a/arch/arm/mach-versatile/pci.c
+++ b/arch/arm/mach-versatile/pci.c
@@ -305,7 +305,7 @@ int __init pci_versatile_setup(int nr, struct pci_sys_data *sys)
 
 void __init pci_versatile_preinit(void)
 {
-	pcibios_min_io = 0x44000000;
+	pcibios_min_io = 0x100;
 	pcibios_min_mem = 0x50000000;
 
 	__raw_writel(VERSATILE_PCI_MEM_BASE0 >> 28, PCI_IMAP0);

And:

On Thursday 31 May 2012, Rob Herring wrote:
> I've resurrected your patch from ~2 years ago and that does fix it. Any
> reason it was never merged? I could go with a more simple fix which just
> restore IO_SPACE_LIMIT to ~0, but yours is more in the direction we want
> to go with PCI mappings.

It was only my fault for not pushing the patches enough. I think they should
really go in now.

Arnd

So I'm not going mad.

Happy days

[knc1]

The **next** time we build qemu, let us include the {32bit,64bit} info in the archive name.
Oh, wait, we both tossed out our 64bit systems, didn't we? Not an issue any longer.

[twobob]

Originally Posted by knc1

The **next** time we build qemu, let us include the {32bit,64bit} info in the archive name.
Oh, wait, we both tossed out our 64bit systems, didn't we? Not an issue any longer.

And I haven't looked back.

I see no hardcore video-crunching, 3d rendering or hyper-log-parsing in my near future (god willing)

64 bits? you can keep the extra addresses, there isn't enough tea in the world to make me walk that path for another decade.

[twobob]

I think all these patches

pflash-cfi01-after-erase-confirm-reset-wcycle 02-Oct-2008 15:35 1.0K
pflash-cfi01-improve-debug-msgs 02-Oct-2008 15:35 1.1K
pflash-cfi01-increase-write-buffer-size 02-Oct-2008 15:35 1.4K
versatilepb-add-flash-support 02-Oct-2008 15:35 3.6K

Have value, I'll go root through the source and see what's there and what isn't.

The add flash support I suspect is the only critical one as reflected in the Chinese post I linked to.

[twobob]

Hmm possibly not.

Got a bit further without them

Need to sort out that drive call..

simon@dev ~/BLDS $ qemu-system-arm -M versatilepb -nographic -no-reboot -kernel zImage -hda rootfs.squashfs -append "root=/dev/sda rw init=/sbin/init.sh panic=1 PATH=/bin:/sbin console=ttyAMA0 HOST=armv6l"

Spoiler:

oss: Could not initialize DAC
oss: Failed to open `/dev/dsp'
oss: Reason: No such file or directory
oss: Could not initialize DAC
oss: Failed to open `/dev/dsp'
oss: Reason: No such file or directory
audio: Failed to create voice `lm4549.out'
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Linux version 3.4.7 (simon@dev) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #1 Sat Aug 11 03:49:07 BST 2012
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00093177
CPU: VIVT data cache, VIVT instruction cache
Machine: ARM-Versatile PB
Memory policy: ECC disabled, Data cache writeback
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: root=/dev/sda rw init=/sbin/init.sh panic=1 PATH=/bin:/sbin console=ttyAMA0 HOST=armv6l
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126184k/126184k available, 4888k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xc8800000 - 0xff000000   ( 872 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .text : 0xc0008000 - 0xc034641c   (3322 kB)
      .init : 0xc0347000 - 0xc0363000   ( 112 kB)
      .data : 0xc0364000 - 0xc0387780   ( 142 kB)
       .bss : 0xc03877a4 - 0xc03a1338   ( 103 kB)
NR_IRQS:192
VIC @f1140000: id 0x00041190, vendor 0x41
Console: colour dummy device 80x30
Calibrating delay loop... 395.67 BogoMIPS (lpj=1978368)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0x28fb50 - 0x28fba8
NET: Registered protocol family 16
Serial: AMBA PL011 UART driver
dev:f1: ttyAMA0 at MMIO 0x101f1000 (irq = 12) is a PL011 rev1
console [ttyAMA0] enabled
dev:f2: ttyAMA1 at MMIO 0x101f2000 (irq = 13) is a PL011 rev1
dev:f3: ttyAMA2 at MMIO 0x101f3000 (irq = 14) is a PL011 rev1
fpga:09: ttyAMA3 at MMIO 0x10009000 (irq = 38) is a PL011 rev1
bio: create slab <bio-0> at 0
Switching to clocksource timer3
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP: reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
NetWinder Floating Point Emulator V0.97 (double precision)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 246
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
clcd-pl11x dev:20: PL110 rev0 at 0x10120000
clcd-pl11x dev:20: Versatile hardware, VGA display
Console: switching to colour frame buffer device 80x60
brd: module loaded
physmap platform flash device: 04000000 at 34000000
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf000f0)
physmap-flash.0: Found 1 x32 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x000000
Intel/Sharp Extended Query Table at 0x0031
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0xf0)
Using buffer write method
smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@fluxnic.net>
eth0: SMC91C11xFD (rev 1) at c8886000 IRQ 25 [nowait]
eth0: Ethernet addr: 52:54:00:12:34:56
mousedev: PS/2 mouse device common for all mice
TCP: cubic registered
NET: Registered protocol family 17
VFP support v0.3: implementor 41 architecture 1 part 10 variant 9 rev 0
input: AT Raw Set 2 keyboard as /devices/fpga:06/serio0/input/input0
input: ImExPS/2 Generic Explorer Mouse as /devices/fpga:07/serio1/input/input1
VFS: Cannot open root device "sda" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
1f00           65536 mtdblock0  (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[<c0019d38>] (unwind_backtrace+0x0/0xf0) from [<c028c3bc>] (panic+0x74/0x1a8)
[<c028c3bc>] (panic+0x74/0x1a8) from [<c0347c1c>] (mount_block_root+0x178/0x22c)
[<c0347c1c>] (mount_block_root+0x178/0x22c) from [<c0347eb0>] (mount_root+0xe4/0x10c)
[<c0347eb0>] (mount_root+0xe4/0x10c) from [<c0348038>] (prepare_namespace+0x160/0x1b8)
[<c0348038>] (prepare_namespace+0x160/0x1b8) from [<c03478d8>] (kernel_init+0x16c/0x1a8)
[<c03478d8>] (kernel_init+0x16c/0x1a8) from [<c0014f50>] (kernel_thread_exit+0x0/0x8)
Rebooting in 1 seconds..simon@dev ~/BLDS $

or with -hda

VFS: Cannot open root device "hda" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
1f00 65536 mtdblock0 (driver?)

Hmm. I wish buildroot would spit out an img ; ) Guess I'll have to spew it into a qemu-img one

[knc1]

Try this one on for size if you haven't read it yet:
http://www.linuxforu.com/2011/06/qem...opment-part-1/

Skip on down the page and pick up the story at "Modified Kernel for U-Boot"
(Buildroot can generate a uImage format kernel file for you.)

When you get to part 3, use the Freescale repository of u-boot (and the kernel if desired) that are indexed in our own "Tools Index" under source resources (bottom of page).

Edit:
I seem to be losing track, the Freescale kernel source releases are here:
http://drpbox.knetconnect.com/fscale/
But I didn't do the same for the Freescale u-boot releases, maybe I should.

That first section ends with running a hello world program from initramfs.
(Buildroot can generate an intial ramfs system for you or a filesystem image - if you need both (to duplicate a Kindle's behavior you do) then you get to run Buildroot twice).

The "recommended practice" on the BR mailing list has been: make clones for each purpose, I.E:
git clone <the public repo> br.git
git clone br.git br-ramfs.git
git clone br.git br-sysfs.git

That gives you three repos -
the br.git repo you can keep up to date with "git pull" (does not effect the other two)
each of the other two provide places for the two sets of (very different) configure options and file.

[twobob]

Originally Posted by knc1

Try this one on for size if you haven't read it yet:
http://www.linuxforu.com/2011/06/qem...opment-part-1/

Skip on down the page and pick up the story at "Modified Kernel for U-Boot"
(Buildroot can generate a uImage format kernel file for you.)

When you get to part 3, use the Freescale repository of u-boot (and the kernel if desired) that are indexed in our own "Tools Index" under source resources (bottom of page).

Edit:
I seem to be losing track, the Freescale kernel source releases are here:
http://drpbox.knetconnect.com/fscale/
But I didn't do the same for the Freescale u-boot releases, maybe I should.

Thanks mate! Great info.

[twobob]

Hmm. I followed the instructions, to the letter.

Got the relevant Git repo of the freescale Das U-boot.

me@dev ~/BLDS/kindle $ git clone http://git.freescale.com/git/cgit.cg...uboot-imx.git/

Activated my chain

export PATH=~/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin:$PATH

Configured the repo via the chain

me@dev ~/GIT/u-boot $ make versatilepb_config arch=ARM CROSS_COMPILE=arm-none-linux-gnueabi-

made it with the chain

me@dev ~/GIT/u-boot $ make versatilepb_config arch=ARM CROSS_COMPILE=arm-none-linux-gnueabi-

cp'd it to the kindle BLDS dir

me@dev ~/BLDS $ cd kindle/
me@dev ~/BLDS/kindle $ ls
rootfs.cpio u-boot.bin uImage

but it dies:

me@dev ~/BLDS/kindle $ qemu-system-arm -M versatilepb -nographic -no-reboot -kernel u-boot.bin

oss: Could not initialize DAC
oss: Failed to open `/dev/dsp'
oss: Reason: No such file or directory
oss: Could not initialize DAC
oss: Failed to open `/dev/dsp'
oss: Reason: No such file or directory
audio: Failed to create voice `lm4549.out'
qemu: fatal: Trying to execute code outside RAM or ROM at 0xffff06dc

R00=fffcbf70 R01=ffff0000 R02=00000000 R03=0101bf60
R04=ffff0000 R05=fffcbf70 R06=ffff0000 R07=00000000
R08=008fff78 R09=feff0000 R10=0101bf60 R11=00000000
R12=fffcbfe8 R13=fffcbf60 R14=ffff06dc R15=ffff06dc
PSR=600001d3 -ZC- A svc32
Aborted
me@dev ~/BLDS/kindle $

Fail.

Not sure about this one. Perhaps I should rebuild my qemu? hrmm. dunno.
I will ruminate upon it.

added bin tar geezedded for extra interested people

EDIT: I should probably go on about being certain you know what this is before you do anything with it. There, I did.

[knc1]

That looks a lot like:
http://balau82.wordpress.com/2010/03...r-arm-on-qemu/

The only difference I see is your missing: -m 128M
Which might explain the complaint about the start address (our build of qemu defaults to -m 256M).

[twobob]

Originally Posted by knc1

That looks a lot like:
http://balau82.wordpress.com/2010/03...r-arm-on-qemu/

The only difference I see is your missing: -m 128M
Which might explain the complaint about the start address (our build of qemu defaults to -m 256M).

It is the same article more or less from what I see too. heh.

http://git.savannah.gnu.org/cgit/qem.../versatilepb.c is where the info on the call lies so I´m looking in that. possibly may resort to building a custom elf. I think I will spend today playing with custom buildroot skeletons however. If the output can be convinced to place ´the stuff´in the right location in the first place; the emulation stage may prove to be a nice-to-have but not ´required´ for developing native kindle binaries ¨In one hit¨. Of course as a testing platform it´s still awesome.

anyways, revisit this in the medium term now I´m thinking.
It´s more critical I start developing tools I can use natively, in the short term, is my thought process.

See what todays MAKE machinations bring : )

EDIT: I did try the alternate memory settings and just about every relevant setting I could think of in the 6ish hours yesterday spent poring through the manual and a host of help documents.