For discussions about development of TAPs, patches and other software for the Toppy

Moderator: Technical

Post Reply
tom3q
Regular contributor
Posts: 53
Joined: Thu Mar 06, 2008 6:25 pm

Post by tom3q »

DeadBeef wrote:
tom3q wrote:Maybe the Toppy firmware stores the data in wrong byte order?
I don't see how it should be possible. The Toppy is configured for big endian. For performance reasons the firmware does not changes byte order of received DVB data. So the data must have been stored in big endian.
tom3q wrote:Is it correct when reading in PIO mode?
Reading in PIO mode also returns wrong byte order because the byte order is changed in emma_ide_inw().
So something is wrong on the Toppy. May it have some IDE data lines swapped? On the Kaon, with my driver i can normally read a disk formatted on my PC and boot the system from it.
DeadBeef
Frequent contributor
Posts: 264
Joined: Mon Jan 09, 2006 7:28 pm

Post by DeadBeef »

Could you provide me a copy of your directory tree with busybox binaries? I would like to see whether it is more stable than mine.
tom3q
Regular contributor
Posts: 53
Joined: Thu Mar 06, 2008 6:25 pm

Post by tom3q »

DeadBeef wrote:Could you provide me a copy of your directory tree with busybox binaries? I would like to see whether it is more stable than mine.
Check your PM.
bdb
Frequent contributor
Posts: 499
Joined: Tue Oct 18, 2005 10:50 pm

Post by bdb »

mine also burst back into life last night ...
- it took this (ide-probe.c):

Code: Select all

	/*
	 * We must always disable IRQ, as probe_for_drive will assert IRQ, but
	 * we'll install our IRQ driver much later...
	 */
	irqd = hwif->irq;
printk("%sirqd=%d, disable_irq()\n", indent_str, irqd);
	if (irqd)
		disable_irq(hwif->irq);

//bdb
 	*(volatile unsigned char *)0xb0012d5b = 2; // Disable IDE interrupt.

	local_irq_set(flags);
However, similar to deadbeef, this kernel still crashes with long a dd:

Code: Select all

kernel BUG at page_alloc.c:274!
Break instruction in kernel code in traps.c::do_bp, line 592:
I suspect these interrupts are the crux of the problem. Clearly as the kernel boots the disk can leave the interrupt asserted, causing chaos when interrupts are enabled. The kernel is full of comments about hacks to try to make irq work ...

On the endian issue - I think topfield screwed up the wiring, and swapped bytes over a 32 bit word, rather than a 16 bit word; but I think that the emma dma mode supports this (there is no byte swapping code in the topfield firmware) . My original ide code had thi in ide_geninit():

Code: Select all

//bdb
printk("forcing bswap\n");
drive->bswap = 1;
printk("forcing 32bitio\n");
drive->io_32bit = 1;


I also noted that 'emma_ide_tuneproc()' never gets called, so it seems to startup in pio mode 0; is this expected behaviour?

bdb
DeadBeef
Frequent contributor
Posts: 264
Joined: Mon Jan 09, 2006 7:28 pm

Post by DeadBeef »

SUCCESS!!!

I found the root cause of the problem - the Linux loader TAP we all have used did not load the BSS:

Code: Select all

loading      : vmlinux
Discarding                       : 00000000+     0 type=0 flags=0
                           .text : 00000800+16f0b8 bytes to mem: 80b00000+16f0b8
                          .fixup : 0016f8b8+   e78 bytes to mem: 80c6f0b8+   e78
                        .kstrtab : 00170730+  4958 bytes to mem: 80c6ff30+  4958
                      __ex_table : 00175090+  1558 bytes to mem: 80c74890+  1558
                       __ksymtab : 001765e8+  2290 bytes to mem: 80c75de8+  2290
                 .data.init_task : 00179000+  2000 bytes to mem: 80c7a000+  2000
                      .text.init : 0017b000+ 1498c bytes to mem: 80c7c000+ 1498c
                      .data.init : 0018f98c+   fd8 bytes to mem: 80c9098c+   fd8
                     .setup.init : 00190970+    f0 bytes to mem: 80c91970+    f0
                  .initcall.init : 00190a60+    90 bytes to mem: 80c91a60+    90
         .data.cacheline_aligned : 00191000+  18e0 bytes to mem: 80c92000+  18e0
Discarding              .reginfo : 001a7000+    18 type=70000006 flags=0
                           .data : 00193000+ 14000 bytes to mem: 80c94000+ 14000
Discarding                  .bss : 001a7000+ 2d5b8 type=8 flags=3
Discarding                  .pdr : 001a7018+ 1ef80 type=1 flags=0
Discarding             .shstrtab : 001c5f98+    b8 type=3 flags=0
Discarding               .symtab : 001c6348+ 202e0 type=2 flags=0
Discarding               .strtab : 001e6628+ 23484 type=3 flags=0
Once I removed the check if(s->sh_type == SHT_PROGBITS) in load_elf() transfers from disk stopped crashing the Toppy!
tom3q
Regular contributor
Posts: 53
Joined: Thu Mar 06, 2008 6:25 pm

Post by tom3q »

DeadBeef wrote:SUCCESS!!!

I found the root cause of the problem - the Linux loader TAP we all have used did not load the BSS:
...
Once I removed the check if(s->sh_type == SHT_PROGBITS) in load_elf() transfers from disk stopped crashing the Toppy!
Good to hear that it's working.
The .bss section should actually be not loaded but zeroed, but this is what you probably mean by "loading".

Also, i'm making progress in porting my drivers for 2.6 kernel, so soon we'll have a 2.6.24.4 kernel with all the things which were working on my 2.4.29 (and even more, because i've got the flash memory read/write to work).
bdb
Frequent contributor
Posts: 499
Joined: Tue Oct 18, 2005 10:50 pm

Post by bdb »

- that doesn't work for me; I also tried zeroing the .bss section. I still get - the 'kernel BUG at page_alloc.c:274!'

bdb
DeadBeef
Frequent contributor
Posts: 264
Joined: Mon Jan 09, 2006 7:28 pm

Post by DeadBeef »

tom3q wrote:The .bss section should actually be not loaded but zeroed, but this is what you probably mean by "loading".
At the time of writing I meant loading. But you are right - there is not data in .bss not even zeros. That is, the sections behind .bss have been copied to the specified location. Another thing which comes to my mind is that I have used an embedded initrd instead of an external in my last tests. Maybe that made the difference. To be investigated ...
tom3q wrote:Also, i'm making progress in porting my drivers for 2.6 kernel, so soon we'll have a 2.6.24.4 kernel with all the things which were working on my 2.4.29 (and even more, because i've got the flash memory read/write to work).
I clearly see the benefits of a 2.6 kernel but will it work with the 2.4 modules (rtos, dma, demux etc.)? Unless you already have an open source equivalent.
bdb wrote:On the endian issue - I think topfield screwed up the wiring, and swapped bytes over a 32 bit word, rather than a 16 bit word; but I think that the emma dma mode supports this (there is no byte swapping code in the topfield firmware) .
I still don't see how it is possible that reading/writing HDD using Toppy's firmware provides correct data endianess and running Linux on the same hardware does not. I cannot recall that the firmware performs byte swapping.
tom3q
Regular contributor
Posts: 53
Joined: Thu Mar 06, 2008 6:25 pm

Post by tom3q »

DeadBeef wrote:I clearly see the benefits of a 2.6 kernel but will it work with the 2.4 modules (rtos, dma, demux etc.)? Unless you already have an open source equivalent.
Not really already, but i'm going to write an open source equivalent.
DeadBeef
Frequent contributor
Posts: 264
Joined: Mon Jan 09, 2006 7:28 pm

Post by DeadBeef »

DeadBeef wrote:SUCCESS!!!

I found the root cause of the problem - the Linux loader TAP we all have used did not load the BSS:

Once I removed the check if(s->sh_type == SHT_PROGBITS) in load_elf() transfers from disk stopped crashing the Toppy!
I have to apologize. I made wrong conclusions. It is indeed the embedded initrd which provides a stable IDE interface. :?

The DMA transfer rate of my Samsung HDD measured by "hdparm -t" is 5.5 MB/s.
bdb
Frequent contributor
Posts: 499
Joined: Tue Oct 18, 2005 10:50 pm

Post by bdb »

arrh - that seems to help. Why :?

My usb network also seems more (but not completely) stable now (to a pc running xp). I'm getting a transfer rate of ~17Mbps (2.2MB/s); so similar to the toppy firmware...

what is behind the usb port on the kaon?

bdb
tom3q
Regular contributor
Posts: 53
Joined: Thu Mar 06, 2008 6:25 pm

Post by tom3q »

bdb wrote:arrh - that seems to help. Why :?

My usb network also seems more (but not completely) stable now (to a pc running xp). I'm getting a transfer rate of ~17Mbps (2.2MB/s); so similar to the toppy firmware...

what is behind the usb port on the kaon?

bdb
There is a CY7C68300A (EZ-USB AT2 USB 2.0 to ATA/ATAPI Bridge) in the kaon, which is an independent device using the IDE bus. To use the USB connection, the IDE controller of EMMA must be disabled/tristated and IDE_EN pin of the bridge has to be asserted. At the moment i don't know how to disable/tristate the IDE controller...
DeadBeef
Frequent contributor
Posts: 264
Joined: Mon Jan 09, 2006 7:28 pm

Post by DeadBeef »

I've got a very strange behavior when adding the following lines to the end of emma_setup():

Code: Select all

	emma2_mpeg_mem = alloc_bootmem(16*1024*1024);
	emma2_mpeg_mem_size = 16*1024*1024;
	printk("emma2_mpeg_mem = %08x\n",emma2_mpeg_mem);
The kernel does not output anything at all if the lines are present. That is, not even the first lines:

Code: Select all

CPU revision is: 00000c72
Primary instruction cache 16kB, physically tagged, direct mapped, linesize 16 bytes.
Primary data cache 8kB, direct mapped, linesize 16 bytes.
:?
tom3q
Regular contributor
Posts: 53
Joined: Thu Mar 06, 2008 6:25 pm

Post by tom3q »

DeadBeef wrote:I've got a very strange behavior when adding the following lines to the end of emma_setup():

Code: Select all

	emma2_mpeg_mem = alloc_bootmem(16*1024*1024);
	emma2_mpeg_mem_size = 16*1024*1024;
	printk("emma2_mpeg_mem = %08x\n",emma2_mpeg_mem);
The kernel does not output anything at all if the lines are present. That is, not even the first lines:

Code: Select all

CPU revision is: 00000c72
Primary instruction cache 16kB, physically tagged, direct mapped, linesize 16 bytes.
Primary data cache 8kB, direct mapped, linesize 16 bytes.
:?
Hmm, we already have some memory allocated for MPEG/DMA/etc. and it's done with a macro defining low memory (EMMA_LOW_MEM_START or something similar). And also i don't think that alloc_bootmem should be used in _setup() routine, because it's too late for it. It should be used rather in prom.c.
DeadBeef
Frequent contributor
Posts: 264
Joined: Mon Jan 09, 2006 7:28 pm

Post by DeadBeef »

tom3q wrote:Hmm, we already have some memory allocated for MPEG/DMA/etc. and it's done with a macro defining low memory (EMMA_LOW_MEM_START or something similar). And also i don't think that alloc_bootmem should be used in _setup() routine, because it's too late for it. It should be used rather in prom.c.
I just tried to mimic the Gigaset kernel. Its modules require this two symbols.
Post Reply