On 05/25/2011 05:38 PM, Michael Jones wrote:
> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more
> devices when probing an i2c bus". It detects more devices indeed, such
> as some that don't even exist. Ev
Hello Michael,
Michael Jones wrote:
> On 05/25/2011 05:38 PM, Michael Jones wrote:
>> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
>> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more
>> devices when probing an i2c bus". It detects more devices indeed
hill all
I encountered an error
libgcc.a(_divsi3.oS) uses hardware FP, whereas u-boot uses software FP
when I compile u-boot
How do I solve this problem and I am very confused with that gcc's soft's float
and glibc's soft float
who can help me or show me the Information where can i find
Best reg
Michael,
> On 05/25/2011 05:38 PM, Michael Jones wrote:
>> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
>> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more
>> devices when probing an i2c bus". It detects more devices indeed, such
>> as some that don't
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Minkyu,
Le 26/05/2011 08:24, Minkyu Kang a écrit :
>> Rather than a merge, could you please do a rebase (onto f14a522a
>> (Beagleboard: fixed typo in typecast) as indicated in
>> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees#BEFORE_Requesting_a_Pull)?
>
> I already did a rebase.
> Any
Dear Graeme Russ,
In message you wrote:
>
> and then start banging on arch maintainers heads to implement the trivial
> ISR to kick the prescaler:
I guess a lot of my confusion could be removed if you could think of a
better name for this function. For me a "prescaler" has a very
definitive mea
Dear =?gb2312?B?vaq6o7fh?=,
In message you wrote:
>
> hill all
valley you!
> I encountered an error
> libgcc.a(_divsi3.oS) uses hardware FP, whereas u-boot uses software FP
> when I compile u-boot
> How do I solve this problem and I am very confused with that gcc's soft's
> float and glibc's s
Hi all
I did a patch for broken at91sam9263ek board and it fixes the u-boot
compilation errors due to rework.
If anybody uses the board, please test it and let me know the bugs.
Waiting for ur response.
Thanks & Regards
vicky
at91sam9263.patch
Description: Binary data
___
On Thursday, May 26, 2011, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you wrote:
>>
>> and then start banging on arch maintainers heads to implement the trivial
>> ISR to kick the prescaler:
>
> I guess a lot of my confusion could be removed if you could think of a
> better name for
Hi,
With 2011.03 uboot, I am adding firmware flashing feature to our
arm cortex a9 soc platform via usb, in which the data firstly be
uploaded to memory wholly (more than 200MB, thanks our 512MB physical
memory), then burned.
By my understanding, after relocation the successive memory ra
On 26/05/11 08:03, Michael Jones wrote:
> On 05/25/2011 05:38 PM, Michael Jones wrote:
>> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
>> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more
>> devices when probing an i2c bus". It detects more devices ind
Dear Albert ARIBAUD,
On 26 May 2011 17:13, Albert ARIBAUD wrote:
> Hi Minkyu,
>
> Le 26/05/2011 08:24, Minkyu Kang a écrit :
>
>>> Rather than a merge, could you please do a rebase (onto f14a522a
>>> (Beagleboard: fixed typo in typecast) as indicated in
>>>
>>> http://www.denx.de/wiki/view/U-Boot
Dear Albert ARIBAUD,
The following changes since commit f14a522a6cb6b843d31fd099b5af6a57142f2364:
BeagleBoard: fixed typo in typecast (2011-05-23 09:04:39 +0200)
are available in the git repository at:
ssh://gu-sams...@git.denx.de/u-boot-samsung master
Chander Kashyap (4):
S5P: GPIO M
Hi Minkyu,
Le 26/05/2011 12:43, Minkyu Kang a écrit :
> Dear Albert ARIBAUD,
>
> The following changes since commit f14a522a6cb6b843d31fd099b5af6a57142f2364:
>
>BeagleBoard: fixed typo in typecast (2011-05-23 09:04:39 +0200)
>
> are available in the git repository at:
>ssh://gu-sams...@git
Hi,
Le 26/05/2011 11:04, Yuping Luo a écrit :
> Hi,
>
> With 2011.03 uboot, I am adding firmware flashing feature to our
> arm cortex a9 soc platform via usb, in which the data firstly be
> uploaded to memory wholly (more than 200MB, thanks our 512MB physical
> memory), then burned.
>
Modifies CPU Frequency to 1GHz and removes hard coding of mmc_pre_ratio for
MMC Channel2 in FSYS2 register.
Signed-off-by: Chander Kashyap
---
board/samsung/smdkv310/lowlevel_init.S |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/samsung/smdkv310/lowlevel_init.S
Hi Wolfgang,
On Wednesday 18 May 2011 11:36 AM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd352ea.3090...@ti.com> you wrote:
>>
>>> What you are doing here is defining an image format. Such an image
>>> format must be good enough not only for OMAP4 and for loading U-Boot
>>> as second
Hi Alexander Holler,
is EHCI on omap3 already working?
On my beagleboard xM
usb start
hangs at this position in method ehci_hcd_init:
+ /* perform TLL soft reset, and wait until reset is complete */
+ writel(OMAP_USBTLL_SYSCONFIG_SOFTRESET,
+ OMAP3_USBTLL_BASE + OMAP_
On 05/26/2011 11:23 AM, Nick Thompson wrote:
> On 26/05/11 08:03, Michael Jones wrote:
>> On 05/25/2011 05:38 PM, Michael Jones wrote:
>>> While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
>>> bus. I tracked it to commit 0e57968a215d1b, "I2C: OMAP: detect more
>>> devices whe
On 26/05/11 12:38, Michael Jones wrote:
> On 05/26/2011 11:23 AM, Nick Thompson wrote:
>> On 26/05/11 08:03, Michael Jones wrote:
>>> On 05/25/2011 05:38 PM, Michael Jones wrote:
While running v2011.06-rc1, I noticed some new behavior on my OMAP3 i2c
bus. I tracked it to commit 0e57968a2
On May 20, 2011, at 1:06 AM, Kumar Gala wrote:
> We assumed that only a small set of compatiable strings would be needed
> to find the PCIe device tree nodes to be fixed up. However on newer
> platforms the simple rules no longer work. We need to allow specifying
> the PCIe compatiable string f
Hello Everyone,
OK - Starting a new thread to discuss implementation details. This is a
heads-up for arch/platform maintainers - Once this is a bit more stable, I
will put it on the wiki
Assumed Capabilities of the Platform
- Has a 'tick counter' that does not rely on software to increment
- ti
Hi Wolfgang,
On Tuesday 17 May 2011 06:23 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd26b36.4050...@ti.com> you wrote:
>>
>> And how do you distinguish between the two cases at the top level
>> Makefile? Using a CONFIG flag or on a per platform basis?
>
> The decision should not b
Hello everybody,
Prafulla Wadaskar wrote:
>
>> -Original Message-
>> From: Wolfgang Denk [mailto:w...@denx.de]
>> Sent: Friday, May 20, 2011 6:36 PM
>> To: Valentin Longchamp
>> Cc: Prafulla Wadaskar; albert.u.b...@aribaud.net; u-boot@lists.denx.de;
>> holger.bru...@keymile.com; Ashish Ka
I know there has been a lot of activity related to other things in the U-Boot
source, but has anyone had a chance to review this patch?
Regards,
Alex
--
Alex Waterman
Computer Engineer
Phone: 215-896-4920
Email: awater...@dawning.com
___
U-Boot mail
Hi Wolfgang,
On Tuesday 17 May 2011 01:46 PM, Wolfgang Denk wrote:
> Dear Aneesh V,
>
> In message<4dd21cd8.2080...@ti.com> you wrote:
>>
>>> There are common, board independent parts both in spl/nand and
>>> spl/onenand.
>>
>> How about having them at the root level in 'spl/' ?
>
> Why? It seems
The SHARP LQ084S3LG01 is a TFT LCD used on the P1022DS (revision "C") board.
This device only supports 800x600 resolution, so if that resolution is selected,
assume that this is the device. The device is attached to the LVDS port
on the P1022DS board.
The existing 800x600 entry (for the PDM360NG
The following changes since commit 7a82c208143bbc774ffcb4e53239410f867a0794:
Prepare v2011.06-rc1 (2011-05-19 22:23:50 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-mpc85xx.git master
Kumar Gala (1):
powerpc/fsl_pci: Fix device tree fixups for newer platforms
Am 26.05.2011 13:30, schrieb Christian Spielberger:
> Hi Alexander Holler,
>
> is EHCI on omap3 already working?
>
> On my beagleboard xM
>
> usb start
>
> hangs at this position in method ehci_hcd_init:
>
> + /* perform TLL soft reset, and wait until reset is complete */
> + writel(OMAP_USBTLL_SYS
Hi Graeme,
Thanks very much for doing this. I have been following the discussion
and am very happy that you have continued with it.
On Thu, May 26, 2011 at 6:27 AM, Graeme Russ wrote:
> Hello Everyone,
>
> OK - Starting a new thread to discuss implementation details. This is a
> heads-up for arc
On Thu, 26 May 2011 09:40:46 -0400
Alex Waterman wrote:
>
> I know there has been a lot of activity related to other things in the U-Boot
> source, but has anyone had a chance to review this patch?
Looks mostly OK to me -- I was going to consider it for next, rather than
master, as despite "f
Hi,
I tried to upgrade my 2010/09 version of u-boot for our i.MX31
board, fixed the stuff needed for the new relocation scheme and ...
nothing, ... no prompt, so I compiled for mx31pdk (without any change of
source code) as it is very similar (RAM setup, etc.) and this also shows
no actio
On 5/26/2011 6:27 AM, Graeme Russ wrote:
> Hello Everyone,
>
> OK - Starting a new thread to discuss implementation details. This is a
> heads-up for arch/platform maintainers - Once this is a bit more stable, I
> will put it on the wiki
>
> Assumed Capabilities of the Platform
> - Has a 'tick co
i.MX51 PLL1 seems to have stability problems. It is advised to not use it,
although it is unclear whether all boards and/or chip revisions have this
problem. Using PLL2 for the core and DDR2 seems to fix the problem.
No official errata yet.
Signed-off-by: David Jander
---
arch/arm/cpu/armv7/mx5/
Dear Aneesh V,
In message <4dde34c5.1050...@ti.com> you wrote:
>
> 1. I see that size is at offset 0xC in this header. Is this a standard?
> 2. I see that the header is 64 bytes. Is that again a standard for
> mkimage.
Both are not really "standards" in the sense that any standardization
group l
Dear Simon Glass,
In message you wrote:
>
> Can we have a microsecond one also please? Some sort of microsecond
I guess you cannot, at least not in general. In worst case that would
mean we have to process 1e6 interrupts per second, which leaves little
time for anything useful.
Best regards,
Dear Helmut Raiger,
In message <4dde7bae.7020...@hale.at> you wrote:
>
> On the other hand I found several patches in the last months about
> changes in the mx31pdk code which suggest a running uboot port for mx31pdk.
I canot comment on the mx31pdk, but top-of-tree is running fine on
some i.MX3
Dear Graeme Russ,
In message <4dde5548.3020...@gmail.com> you wrote:
>
> Assumed Capabilities of the Platform
> - Has a 'tick counter' that does not rely on software to increment
I think we should delete the "does not rely on software to increment"
part. It is not really essential.
> - tick i
Hi all,
I was working on enabling the watchdog timer in the U-Boot for MIPS
based platform. I set up the timer and watchdog. when the timer expires, I
need to kick the watchdog until the user timeout period expires.
I see that for ARM we have do_irq function which gets called when there is
int
Dear "J. William Campbell",
In message <4dde8639.3090...@comcast.net> you wrote:
> I think it is the task of get_ticks to return the hardware tick counter
> as an increasing counter, period. The counter may wrap at some final
> count that is not all ones. That is ok. Sync_timebase deals with
On Thu, 26 May 2011 19:00:14 +0200
David Jander wrote:
> i.MX51 PLL1 seems to have stability problems. It is advised to not use it,
> although it is unclear whether all boards and/or chip revisions have this
> problem. Using PLL2 for the core and DDR2 seems to fix the problem.
> No official errat
Scott,
> Looks mostly OK to me -- I was going to consider it for next, rather than
> master, as despite "fix" in the name it's really adding new hardware support.
Ahh, yeah, that makes sense. I will change "Fixes" to "Adds" for next
submission.
> You may want to use an #ifdef for bus width in
On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4dde8639.3090...@comcast.net> you wrote:
>
>> I think it is the task of get_ticks to return the hardware tick counter
>> as an increasing counter, period. The counter may wrap at some final
>> count that is
Helmut,
On Thu, May 26, 2011 at 2:30 PM, Wolfgang Denk wrote:
> Dear Helmut Raiger,
>
> In message <4dde7bae.7020...@hale.at> you wrote:
>>
>> On the other hand I found several patches in the last months about
>> changes in the mx31pdk code which suggest a running uboot port for mx31pdk.
>
> I ca
Dear "J. William Campbell",
In message <4ddea165.9010...@comcast.net> you wrote:
>
> >> I think it is the task of get_ticks to return the hardware tick counter
> >> as an increasing counter, period. The counter may wrap at some final
> >> count that is not all ones. That is ok. Sync_timebase dea
On 5/26/2011 12:16 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ddea165.9010...@comcast.net> you wrote:
I think it is the task of get_ticks to return the hardware tick counter
as an increasing counter, period. The counter may wrap at some final
count that
Dear "J. William Campbell",
In message <4ddeafe0.8060...@comcast.net> you wrote:
>
> I certainly agree using 64 bits for all calculations is vast overkill.
> In fact, I think using 64 bit calculations on systems that have only a
> 32 bit or less timer register is probably overkill. :-) However,
On 5/26/2011 1:27 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4ddeafe0.8060...@comcast.net> you wrote:
>> I certainly agree using 64 bits for all calculations is vast overkill.
>> In fact, I think using 64 bit calculations on systems that have only a
>> 32 bit or less tim
Hello,
I am trying to get tftp working on the pandaboard; I am testing Simon's v6
patch series and Gilles EHCI patches
doc/README.sub claims that the SMSC driver supports usbethaddr, I do not
see this
smsc95xx_init_mac_address() fails to get the hwaddr from eeprom and then
it should do
i
Hello,
I am trying to get tftp working on the pandaboard; I am testing Simon's v6
patch series and Gilles EHCI patches
doc/README.sub claims that the SMSC driver supports usbethaddr, I do not
see this
smsc95xx_init_mac_address() fails to get the hwaddr from eeprom and then
it should do
i
Hi there,
I am experiencing reading NAND flash failure, that nand_do_read_ops() function
returns an error -117 (EUCLEAN) in file nand_base.c.
If I comment out this line and hardcoded to "return 0" like this:
// return mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
return 0;
Then
Hi,
It is a little tricky to know what you are applying as this is not in
the tree yet AFAIK.
I have a small change request so will make that and send out another
patch to the list which will hopefully be applied.
However...this doesn't look good:
EHCI timed out on TD - token=0x88008d80
It mig
On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message you wrote:
>>
>> Can we have a microsecond one also please? Some sort of microsecond
>
> I guess you cannot, at least not in general. In worst case that would
> mean we have to process 1e6 interrupts per sec
On Fri, May 27, 2011 at 3:49 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4dde5548.3020...@gmail.com> you wrote:
>>
>> Assumed Capabilities of the Platform
>> - Has a 'tick counter' that does not rely on software to increment
>
> I think we should delete the "does not rely on soft
On Fri, May 27, 2011 at 4:52 AM, J. William Campbell
wrote:
> On 5/26/2011 10:53 AM, Wolfgang Denk wrote:
>>
>> Dear "J. William Campbell",
>>
>> In message<4dde8639.3090...@comcast.net> you wrote:
>>
>>> I think it is the task of get_ticks to return the hardware tick counter
>>> as an increasin
From: york
EEPROM requires tWR for write cycle time. Since there is no other way to
poll if the internal programming ends, wait for 5ms which is the max timing
for AT24C01/02/04/08/16 by default. It can be overridden by defining
CONFIG_I2C_TWR in configuration file if the slowest device has diffe
From: york
If the bus width is 32-bit, burst chop should be disabled and burst length
should be 8. Read from SPD or other source to determine the width.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/options.c | 24
1 files changed, 20 insertions(+), 4 dele
From: york
Only use DDR DIMM part number if SPD has valid length, to prevent from
display garbage in case SPD doesn't cover these fields.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/ddr3_dimm_params.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/
Add support for 16-bit DDR bus. Also deal with system using 64- and 32-bit
DDR devices.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/main.c | 14 +-
arch/powerpc/cpu/mpc8xxx/ddr/options.c |3 ++-
arch/powerpc/include/asm/fsl_ddr_sdram.h |3 +++
3 files ch
In case of empty SPD or checksum error, fallback to raw timing on
supported boards.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/main.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/main.c
b/arch/powerpc/cpu/mpc8xxx/ddr/
From: york
We used to have fixed parameters for soldered DDR chips. This patch enables
calculation based on raw timing data, implemneted in board-specific file.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc85xx/cpu.c|4 +++-
arch/powerpc/cpu/mpc8xxx/ddr/Makefile | 13 +
Adding controller number so board implementation can distinguish.
Signed-off-by: York Sun
---
arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |4 +++-
arch/powerpc/cpu/mpc8xxx/ddr/main.c |2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ddr.h
b/arch/
Hi Bill,
On Fri, May 27, 2011 at 2:56 AM, J. William Campbell
wrote:
> On 5/26/2011 6:27 AM, Graeme Russ wrote:
>>
>> Hello Everyone,
>>
>> OK - Starting a new thread to discuss implementation details. This is a
>> heads-up for arch/platform maintainers - Once this is a bit more stable, I
>> will
Adding byte 32 and 33
Signed-off-by: York Sun
---
include/ddr_spd.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/ddr_spd.h b/include/ddr_spd.h
index e895d61..40a0463 100644
--- a/include/ddr_spd.h
+++ b/include/ddr_spd.h
@@ -219,7 +219,9 @@ typedef struct d
York Sun wrote:
> From: york
You should fix this so that it includes your full name.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Thu, 2011-05-26 at 17:20 -0700, Tabi Timur-B04825 wrote:
> York Sun wrote:
> > From: york
>
> You should fix this so that it includes your full name.
>
> --
Sure. I can fix it along with other feedback.
York
___
U-Boot mailing list
U-Boot@list
On 5/26/2011 4:28 PM, Graeme Russ wrote:
> Hi Bill,
>
> On Fri, May 27, 2011 at 2:56 AM, J. William Campbell
> wrote:
>> On 5/26/2011 6:27 AM, Graeme Russ wrote:
>>> Hello Everyone,
>>>
>>> OK - Starting a new thread to discuss implementation details. This is a
>>> heads-up for arch/platform main
Hi Bill,
On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
wrote:
> On 5/26/2011 4:28 PM, Graeme Russ wrote:
>>
>> Why mess around with bit shifting (which you would then have to cludge
>> into
>> your platform code) when carting around a 64-bit value is relatively
>> cheap,
>> transparent a
Hi, Albert
Thanks for your help.
I found the root cause: In our implementation, the RomCode
initialises the mmu with one hardcode page table address (0x014F8000)
to store the 16KB table, however, it's rewritten by the data. we may
refer to the uboot way of using the dynamically generate
On 5/26/2011 6:51 PM, Graeme Russ wrote:
> Hi Bill,
>
> On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
> wrote:
>> On 5/26/2011 4:28 PM, Graeme Russ wrote:
>>> Why mess around with bit shifting (which you would then have to cludge
>>> into
>>> your platform code) when carting around a 64-b
Hi Bill,
On Fri, May 27, 2011 at 1:54 PM, J. William Campbell
wrote:
> On 5/26/2011 6:51 PM, Graeme Russ wrote:
>>
>> Hi Bill,
>>
>> On Fri, May 27, 2011 at 11:26 AM, J. William Campbell
>> wrote:
>>>
[snip]
>>>
>>> Yes, that is the problem. I have come to the view that two 32 bit words
>>>
On Thu, May 26, 2011 at 3:44 PM, Graeme Russ wrote:
> On Fri, May 27, 2011 at 3:28 AM, Wolfgang Denk wrote:
>> Dear Simon Glass,
>>
>> In message you wrote:
>>>
>>> Can we have a microsecond one also please? Some sort of microsecond
>>
>> I guess you cannot, at least not in general. In worst ca
Hello York,
York Sun wrote:
> From: york
>
> EEPROM requires tWR for write cycle time. Since there is no other way to
> poll if the internal programming ends, wait for 5ms which is the max timing
> for AT24C01/02/04/08/16 by default. It can be overridden by defining
> CONFIG_I2C_TWR in configura
On 05/26/2011 10:52 PM, Peter Meerwald wrote:
> Hello,
>
> I am trying to get tftp working on the pandaboard; I am testing Simon's v6
> patch series and Gilles EHCI patches
>
> doc/README.sub claims that the SMSC driver supports usbethaddr, I do not
> see this
>
> smsc95xx_init_mac_address() f
On Fri, 2011-05-27 at 08:04 +0200, Heiko Schocher wrote:
> Hmm.. you add this timeout in the i2c driver, which will result in
> adding this default 5 ms delay for *all* i2c writes, not only for
> eeprom devices ... why you didn;t add this timeout in cmd_eeprom,
> where it seems to me is the better
On 5/26/2011 9:33 PM, Graeme Russ wrote:
> Hi Bill,
>
> get_ticks() does not care about the clock rate - It simply looks at the
> current value of the hardware tick counter and the value of the hardware
> tick counter the last time get_ticks() was called, calculates the difference
> and adds that
On Fri, May 27, 2011 at 4:33 PM, J. William Campbell
wrote:
> On 5/26/2011 9:33 PM, Graeme Russ wrote:
>>
>> Hi Bill,
>>
>
>>
[massive snip]
OK, you have my ears pricked - Can you give me code samples for:
- get_ticks()
- sync_timbase() (no need to implement the whole lot if that is too
m
78 matches
Mail list logo
