Custom Query (1948 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1 - 3 of 1948)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#1 fixed kernel is running way too slow laforge@… laforge@…
Description

The 2.7.17.7 kernel is running way too slow at the moment. Overal system performance is about 10% of what is to be expected.

during kernel bootup we clearly see that clocks are configured correctly: S3C2410: core 202.800 MHz, memory 101.400 MHz, peripheral 50.700 MHz

but then:

Calibrating delay loop... 4.39 BogoMIPS (lpj=10976)

Comparison with other S3C2410 systems shows that bogomips should be at about 100 (at 200MHz cpu core clock).

I've already checked SDRAM timings, bus access mode (async/sync) and cache enabled status without finding a cause for the problem.

#2 fixed SD card driver unstable laforge@… laforge@…
Description

The SD card driver is not very stable and causes file system corruption.

I'm working on this with the original driver author (who's also here in Germany). Expect news soon, but be warned that mounting SD-Cards read/write is not a good ide at this point.

#3 fixed Debug Board trying to control GSM_EN / FA_19 sean_chiang@… laforge@…
Description

Looking at the debug board schematics, there is a transistor with some resistors connected to GSM_EN (called X_FA19 in that schematic).

The way the transistor is being used, it has a pull-up resistor to +3.3V, making it pull GSM_EN to ground.

Only if CEN_FUNC0 is pulled to ground, the transistor Q1 is switched 'off' and thus the pull-up resistor R106 becomes active, pulling GSM_EN to high level.

CEN_FUNC0 is only present on pin 16 of the JTAG connector. IF your JTAG probe grounds that pin, and it is connected, then the serial port will work. otherwise it won't. Since my USB-JTAG doesn't ground that pin, and I only use the wiggler for flashing (but disconnect it before booting), it never worked for me.

Sean seems to have connected the wiggler at all time, thus the serial port works for him. Am I right, Sean? Can you verify my analysis by disconnecting your JTAG probe and checking whether the serial port still works?

I think this is a general mis-design between the debug board and the GTA01. The question is: Who drives that signal? To my understanding, it has always been the S3C2410. Configuring GPF2 as output, and then deciding whether to enable the GSM Modem, or to use the port as a serial console. Basically whenever we power-up GSM, we also switch the serial port to GSM. If GSM is powered down (such as during early bootup), we can use it as serial console.

However, such operation collides with the notion that the debug board seems to take: It thinks, it owns the signal and thus drives it.

The debug board either pulls the signal high (10kOhms) or drives it to low using Q1. There is no possibility to set it in "high reststance" (like tri-state).

Therefore, a conflict (short-circuit) is basically pre-programmed. Most likely the GPIO of S3C2410 will die before Q1 does (in case of a conflict).

My proposed interim solution is:

  • Disconnect FA_19 on the debug board (unsolder R105 and R106)
  • Use u-boot to initialize GPF2 as output
  • initally set the GPF2(GSM_EN) level to high, enabling serial console
  • use kernel-level driver to switch GPF2 to low, once GSM is powered up and kernel has made sure this UART is no longer used for debug messages (switched off system console on /dev/ttyS0)

This has been verified to work.

1 2 3 4 5 6 7 8 9 10 11
Note: See TracQuery for help on using queries.