Click here to go to the forum index Click here for the home page
 
Author Message

<  TAP and patch development  ~  linux

Page 22 of 23
Goto page Previous  1, 2, 3 ... , 21, 22, 23  Next
tom3q
Posted: Sat Apr 12, 2008 2:10 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
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.
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 2:18 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
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.
View user's profile Send private message
tom3q
Posted: Sat Apr 12, 2008 2:37 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
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.
View user's profile Send private message
bdb
Posted: Sat Apr 12, 2008 2:43 pm Reply with quote
Frequent contributor Joined: 18 Oct 2005 Posts: 499
mine also burst back into life last night ...
- it took this (ide-probe.c):
Code:
   /*
    * 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:
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:
//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
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 2:45 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
SUCCESS!!!

I found the root cause of the problem - the Linux loader TAP we all have used did not load the BSS:
Code:
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!
View user's profile Send private message
tom3q
Posted: Sat Apr 12, 2008 2:52 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
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).
View user's profile Send private message
bdb
Posted: Sat Apr 12, 2008 3:13 pm Reply with quote
Frequent contributor Joined: 18 Oct 2005 Posts: 499
- 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
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 10:12 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
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.
View user's profile Send private message
tom3q
Posted: Sat Apr 12, 2008 10:47 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
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.
View user's profile Send private message
DeadBeef
Posted: Sat Apr 12, 2008 10:58 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
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. Confused

The DMA transfer rate of my Samsung HDD measured by "hdparm -t" is 5.5 MB/s.
View user's profile Send private message
bdb
Posted: Sun Apr 13, 2008 2:43 pm Reply with quote
Frequent contributor Joined: 18 Oct 2005 Posts: 499
arrh - that seems to help. Why Confused

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
View user's profile Send private message
tom3q
Posted: Sun Apr 13, 2008 2:54 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
bdb wrote:
arrh - that seems to help. Why Confused

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...
View user's profile Send private message
DeadBeef
Posted: Sun Apr 20, 2008 11:10 am Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
I've got a very strange behavior when adding the following lines to the end of emma_setup():
Code:
   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:
CPU revision is: 00000c72
Primary instruction cache 16kB, physically tagged, direct mapped, linesize 16 bytes.
Primary data cache 8kB, direct mapped, linesize 16 bytes.
Confused
View user's profile Send private message
tom3q
Posted: Sun Apr 20, 2008 12:51 pm Reply with quote
Regular contributor Joined: 06 Mar 2008 Posts: 53
DeadBeef wrote:
I've got a very strange behavior when adding the following lines to the end of emma_setup():
Code:
   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:
CPU revision is: 00000c72
Primary instruction cache 16kB, physically tagged, direct mapped, linesize 16 bytes.
Primary data cache 8kB, direct mapped, linesize 16 bytes.
Confused


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.
View user's profile Send private message
DeadBeef
Posted: Sun Apr 20, 2008 2:34 pm Reply with quote
Frequent contributor Joined: 09 Jan 2006 Posts: 264
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.
View user's profile Send private message

Display posts from previous:  

All times are GMT + 1 Hour
Page 22 of 23
Goto page Previous  1, 2, 3 ... , 21, 22, 23  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum