Date   

Re: Minimal Zephyr build

Benjamin Walsh <benjamin.walsh@...>
 

On Wed, Mar 29, 2017 at 03:17:16PM -0600, David Brown wrote:
At the past mini summit (Austin), a few of us had discussions about
making builds using Zephyr that are more minimal. My specific use
case is about the boot loader, which has very few requirements:

- It needs a flash driver.
- It may need a UART.
- It may need access to crypto hardware (not currently).

Currently, there is quite a bit of code brought in by this that isn't
really needed (for example, there is only a single thread). (A mynewt
build of mcuboot ends up about 10K smaller than a Zephyr build).
If you disable CONFIG_MULTITHREADING, the scheduler goes away. The
kernel operates in coop-mode only with a single thread, which is
basically "never preempt me, except by interrupts and when that
happens, always go back to what I was doing after handling it".

Vincenzo Frascino did a little work to conditionalize some of this,
but I was wondering what people think might be the best approach.

The approach taken by Mynewt (where mcuboot comes from), is to
separate the kernel from the HAL. They are able to build mcuboot with
just the HAL.

Are there other uses for a more minimal version of Zephyr. I realize
we got rid of the nano kernel, but perhaps being able to work without
the scheduler, or timers, etc might be more generally useful.
We merged the two actually.

If I want to get pedentic, we got rid of the microkernel, not the
nanokernel, and brought necessary features of the microkernel into the
nanokernel. :)

Cheers,
Ben

Thanks,
David
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
--
Benjamin Walsh, SMTS
WR VxWorks Virtualization Profile
www.windriver.com
Zephyr kernel maintainer
www.zephyrproject.org


Re: BLE attribute handle

Luiz Augusto von Dentz
 

Hi Anila,

I guess you are not familiar with GATT/ATT, the attribute handle comes
from the discovered (bt_gatt_discover) attributes, in zephyr we
represent them as bt_gatt_attr which happens to contain the handle.
Btw, it just the handle we use so in case you want to cache the
attributes, or you know the attribute handle before hand, you can pass
it directly instead of discovering it again or having to create an
instance of bt_gatt_attr manually.

For more info you can take a look at our documentation:

https://www.zephyrproject.org/doc/1.7.0/api/bluetooth.html

On Thu, Mar 30, 2017 at 8:19 AM, Anila Sri <anilasri.y1995@gmail.com> wrote:
Hello,

I wanted to know what is meant by attribute handle in
bt_gatt_write_without_response

Thanks and Regards,
Anila

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
--
Luiz Augusto von Dentz


Re: undefined reference to `_legacy_sleep'

kk <pinganddu90@...>
 

Thanks all, it works

Inline image 1

I just flash again and again.

On Thu, Mar 30, 2017 at 2:09 PM, kk <pinganddu90@...> wrote:
The white line is Tx, so it should connect to the arduino 101's RX<-0 pin, we can check it at:
and I have test for the exchange, it didn't work as well.

On Thu, Mar 30, 2017 at 1:57 PM, Cui, YanX <yanx.cui@...> wrote:

Hi :

 

                The white line is Tx, the green line is Rx. I think you have a mistake.

 

Thanks

Cuiyan

 

Web QA

Mobile: 13610934250

 

 

 

From: zephyr-devel-bounces@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of kk
Sent: Thursday, March 30, 2017 1:38 PM
To: Buriez, Patrice <patrice.buriez@...>; zephyr-devel@...ct.org
Subject: Re: [Zephyr-devel] undefined reference to `_legacy_sleep'

 

Hi Buriez, thanks first!

 

1. Yes I have set the 115200 for minicom.

 

Inline image 1

 

2. I have export the "ZEPHYR_FLASH_OVER_DFU=y" and on zephyr git master

 

Inline image 2

 

but nothing on minicom

 

Inline image 3

 

My connect picture:

 

Inline image 4

 

Why I can't write a string to serial?




Re: undefined reference to `_legacy_sleep'

kk <pinganddu90@...>
 

OK, thanks.

On Thu, Mar 30, 2017 at 1:32 AM, Nashif, Anas <anas.nashif@...> wrote:

You should not include legacy.h directly, just include zephyr.h

 

legacy.h will be dropped for 1.8 and you should be using new APIs, not a legacy API like task_sleep.

 

 

Anas

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of kk
Sent: Wednesday, March 29, 2017 12:34 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] undefined reference to `_legacy_sleep'

 

Hi all

When I use the "task_sleep" function, I include the file legacy.h, but the compiler tells:
    undefined reference to `_legacy_sleep'

I search the source code in zephyr, its definition in ./kernel/legacy_timer.c, how can I solve this problem?

Thanks



Re: undefined reference to `_legacy_sleep'

kk <pinganddu90@...>
 

Hi Buriez, thanks first!

1. Yes I have set the 115200 for minicom.

Inline image 1

2. I have export the "ZEPHYR_FLASH_OVER_DFU=y" and on zephyr git master

Inline image 2

but nothing on minicom

Inline image 3

My connect picture:

Inline image 4

Why I can't write a string to serial?


Zephyr file system

Ani
 

Hello, 

Can't we use the file system both in arc and x86 at the same time
It is giving spinning error. Is there any way to solve this problem


Thanks and Regards, 
Anila


BLE attribute handle

Ani
 

Hello, 

I wanted to know what is meant by attribute handle in bt_gatt_write_without_response

Thanks and Regards, 
Anila


Re: Minimal Zephyr build

Andy Gross
 

On 29 March 2017 at 16:17, David Brown <david.brown@linaro.org> wrote:
At the past mini summit (Austin), a few of us had discussions about
making builds using Zephyr that are more minimal. My specific use
case is about the boot loader, which has very few requirements:

- It needs a flash driver.
- It may need a UART.
- It may need access to crypto hardware (not currently).

Currently, there is quite a bit of code brought in by this that isn't
really needed (for example, there is only a single thread). (A mynewt
build of mcuboot ends up about 10K smaller than a Zephyr build).

Vincenzo Frascino did a little work to conditionalize some of this,
but I was wondering what people think might be the best approach.
Do we have a rough analysis of the cost of different features with
regards to space? That would make targeting of things to remove a
little easier. Low hanging fruit and what not.

The approach taken by Mynewt (where mcuboot comes from), is to
separate the kernel from the HAL. They are able to build mcuboot with
just the HAL.

Are there other uses for a more minimal version of Zephyr. I realize
we got rid of the nano kernel, but perhaps being able to work without
the scheduler, or timers, etc might be more generally useful.

Andy


Re: Minimal Zephyr build

Nashif, Anas
 

David,
If I am not mistaken we have done some changes to address this and were able to get similar footprint on one of the platforms. Can you share some more details how you got the 10k difference and what are the configurations/boards you are using? A quick test I have done with minimal configuration and single thread shows the kernel taking 18%, this will need to be replaced by some logic if you decide to do a split, so I am no sure if this is a big gain.

Anas

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of David Brown
Sent: Wednesday, March 29, 2017 5:17 PM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Minimal Zephyr build

At the past mini summit (Austin), a few of us had discussions about making builds using Zephyr that are more minimal. My specific use case is about the boot loader, which has very few requirements:

- It needs a flash driver.
- It may need a UART.
- It may need access to crypto hardware (not currently).

Currently, there is quite a bit of code brought in by this that isn't really needed (for example, there is only a single thread). (A mynewt build of mcuboot ends up about 10K smaller than a Zephyr build).

Vincenzo Frascino did a little work to conditionalize some of this, but I was wondering what people think might be the best approach.

The approach taken by Mynewt (where mcuboot comes from), is to separate the kernel from the HAL. They are able to build mcuboot with just the HAL.

Are there other uses for a more minimal version of Zephyr. I realize we got rid of the nano kernel, but perhaps being able to work without the scheduler, or timers, etc might be more generally useful.

Thanks,
David
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Minimal Zephyr build

David Brown
 

At the past mini summit (Austin), a few of us had discussions about
making builds using Zephyr that are more minimal. My specific use
case is about the boot loader, which has very few requirements:

- It needs a flash driver.
- It may need a UART.
- It may need access to crypto hardware (not currently).

Currently, there is quite a bit of code brought in by this that isn't
really needed (for example, there is only a single thread). (A mynewt
build of mcuboot ends up about 10K smaller than a Zephyr build).

Vincenzo Frascino did a little work to conditionalize some of this,
but I was wondering what people think might be the best approach.

The approach taken by Mynewt (where mcuboot comes from), is to
separate the kernel from the HAL. They are able to build mcuboot with
just the HAL.

Are there other uses for a more minimal version of Zephyr. I realize
we got rid of the nano kernel, but perhaps being able to work without
the scheduler, or timers, etc might be more generally useful.

Thanks,
David


Re: undefined reference to `_legacy_sleep'

Nashif, Anas
 

You should not include legacy.h directly, just include zephyr.h

 

legacy.h will be dropped for 1.8 and you should be using new APIs, not a legacy API like task_sleep.

 

 

Anas

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of kk
Sent: Wednesday, March 29, 2017 12:34 PM
To: zephyr-devel@...
Subject: [Zephyr-devel] undefined reference to `_legacy_sleep'

 

Hi all

When I use the "task_sleep" function, I include the file legacy.h, but the compiler tells:
    undefined reference to `_legacy_sleep'

I search the source code in zephyr, its definition in ./kernel/legacy_timer.c, how can I solve this problem?

Thanks


Re: undefined reference to `_legacy_sleep'

Patrice Buriez
 

Did you set the speed (baud rate) at 115200 for minicom?

Did “make flash” actually work?

- You need a Flyswatter2 for JTAG method.

- You need to export “ZEPHYR_FLASH_OVER_DFU=y” for the DFU (USB) method, only available for now on Zephyr git master (i.e. not in Zephyr v1.7).

- Any error message reported?

If using DFU method, did you reset the board again after flashing?

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of kk
Sent: Wednesday, March 29, 2017 6:54 PM
To: Briano, Ivan <ivan.briano@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] undefined reference to `_legacy_sleep'

 

Thanks very much!

Actually, I want to write a string to serial (I want to see "Hello World! x86" on minicom), base on the sample "hello world", my board is arduino 101, it did not work, but it works on board qemu_x86.

~~~~~~~~~~~~~~~~~~~~~~
I connect my arduino 101 to minicom, I have set the serial port:
    ttyUSB0 8N1

I use the Adafruit 4 pin cable (PL2303)

    black Ground connect GND on arduino 101

    green Receive connect TX->1 on arduino 101

    white Transmit connect  RX->1 on arduino 101

I run the hello_world program:
    make BOARD=arduino_101 flash
~~~~~~~~~~~~~~~~~~~~~~

How can I write a string to minicom?

 

On Thu, Mar 30, 2017 at 12:40 AM, Briano, Ivan <ivan.briano@...> wrote:

On Thu, 2017-03-30 at 00:34 +0800, kk wrote:

Hi all

When I use the "task_sleep" function, I include the file legacy.h, but the compiler tells:
    undefined reference to `_legacy_sleep'

I search the source code in zephyr, its definition in ./kernel/legacy_timer.c, how can I solve this problem?

 

Add CONFIG_LEGACY_KERNEL=y to your prj.conf

 

 

Thanks

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

 

Intel Corporation NV/SA
Kings Square, Veldkant 31
2550 Kontich
RPM (Bruxelles) 0415.497.718.
Citibank, Brussels, account 570/1031255/09

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.


Re: undefined reference to `_legacy_sleep'

kk <pinganddu90@...>
 

Thanks very much!
Actually, I want to write a string to serial (I want to see "Hello World! x86" on minicom), base on the sample "hello world", my board is arduino 101, it did not work, but it works on board qemu_x86.

~~~~~~~~~~~~~~~~~~~~~~
I connect my arduino 101 to minicom, I have set the serial port:
    ttyUSB0 8N1
I use the Adafruit 4 pin cable (PL2303)
    black Ground connect GND on arduino 101
    green Receive connect TX->1 on arduino 101
    white Transmit connect  RX->1 on arduino 101
I run the hello_world program:
    make BOARD=arduino_101 flash
~~~~~~~~~~~~~~~~~~~~~~

How can I write a string to minicom?


On Thu, Mar 30, 2017 at 12:40 AM, Briano, Ivan <ivan.briano@...> wrote:
On Thu, 2017-03-30 at 00:34 +0800, kk wrote:
Hi all

When I use the "task_sleep" function, I include the file legacy.h, but the compiler tells:
    undefined reference to `_legacy_sleep'
I search the source code in zephyr, its definition in ./kernel/legacy_timer.c, how can I solve this problem?

Add CONFIG_LEGACY_KERNEL=y to your prj.conf


Thanks
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: undefined reference to `_legacy_sleep'

Briano, Ivan <ivan.briano@...>
 

On Thu, 2017-03-30 at 00:34 +0800, kk wrote:
Hi all

When I use the "task_sleep" function, I include the file legacy.h, but the compiler tells:
    undefined reference to `_legacy_sleep'
I search the source code in zephyr, its definition in ./kernel/legacy_timer.c, how can I solve this problem?

Add CONFIG_LEGACY_KERNEL=y to your prj.conf


Thanks
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


undefined reference to `_legacy_sleep'

kk <pinganddu90@...>
 

Hi all

When I use the "task_sleep" function, I include the file legacy.h, but the compiler tells:
    undefined reference to `_legacy_sleep'
I search the source code in zephyr, its definition in ./kernel/legacy_timer.c, how can I solve this problem?

Thanks


i2c_burst_write API

Erwan Gouriou
 

Hi all,


I'm having trouble using i2c_burst_write to configure several registers
in one shot in a sensor (using i2c_stm32lx.c driver).

According to API description, it seems to be the adequate use:
" This routine writes multiple bytes to an internal address of an
I2C device synchronously."

Following implementation, it generates 2 messages as follow:
Slave ADdress|Write * SUB-Address (register of the sensor where I'd like to start writing)
Slave ADdress|Write * DATA
It doesn't work for me since sensor is expecting one single message:
SAD|W * SUB * ADD

I've found several examples of sensor supporting the later but not the former.
Though, in Zephyr code, I've found some uses of i2c_burst_write API,
hence I tend to think it should work somehow in some cases.

Hence my questions to you:

Are there actually several ways to address an I2C slave for burst write?
> If yes, I'll just avoid using this API. But it might be worse specifying that
it might not fit all slaves implementations.

Is that due to underlying I2C drivers that do some messages concatenation
magic before sending to slave devices?
> If yes, maybe this is a sign API should be adapted to be more transparent

Any other possibility that I don't have in mind right now?


Thanks
Erwan



 







Re: RFC: BSD Socket (like) API

Luiz Augusto von Dentz
 

Hi Paul,

On Wed, Mar 29, 2017 at 1:31 AM, Paul Sokolovsky
<paul.sokolovsky@linaro.org> wrote:
Hello Luiz Augusto,

On Tue, 28 Mar 2017 23:34:25 +0300
Luiz Augusto von Dentz <luiz.dentz@gmail.com> wrote:

[]

net_context). (We might need a queue per context to properly
emulate the read() API, though, so the reference might not be
exactly to a net_context pool, but the same idea applies.)
Indeed we would have to put a queue per net_context which quickly adds
up to the memory footprint,
As I point in the reply to Leandro, these additions would be #ifdef'ed
on CONFIG_NET_BSD_SOCKETS or something, so application developers will
have a choice whether save memory or have more familiar API. Putting
the queue, etc. into yet different structure (and waste some memory to
link this new structure to net_context) is yet another choice.

luckily we can use k_poll and avoid having
extra threads for each context.
Note that the work I'm going to do is based on the previous experience
with implement BSD-Sockets like pull-style API on top of push-style
native ("raw") lwIP API. There, we were able to achieve that without
any threads (indeed, even with a cooperative RTOS underneath). So, no
planning of having extra threads on the initial stage of work
(push-to-pull "impedance conversion"). And presence of k_poll makes me
positive that we'll be able to implement even poll() or epoll() without
them (but that's 2nd stage of work).

But I guess the fundamental problem is
this is probably intended to interface with real BSD socket/posix
applications/components, which I guess will not be enough for most, so
at the end will it be worth adding this code? What are the things we
want to port on top, can someone present at the mini-summit make a
list?
As my initial RFC message pointed, the initial target is MicroPython
with its "usocket" (micro-socket) module. That's a single app, but it
wraps a large chunk of BSD Sockets API for Python language. And of
course, this RFC is to see what other projects people are interested to
port.
I suppose you need much more than sockets to make a python program to
work on top of zephyr. Now I do agree having python would be very
useful to prototype, or js, but for products it might be a different
story.

Casting a pointer to an integer as suggested might work, but will
most likely be an issue with the common pattern of checking for
error by just comparing the sign of the return value, instead of
the (technically correct) comparison with -1.
We can check if there are any paddings on net_context, if there is it
might not be a bad idea to add an id to them, or really make them
compatible with k_poll.

In general Im much more concern about the stack fragmentation, though.
Adding compatibility layers and offloading works against the stack
itself,
Well, I don't see how proper, configurable (on/off) layering works
against the stack. I'd say, vice-versa, it allows to leverage it for
more usecases. Offloading, let me skip that part ;-).
I was referring to APIs like net_buf or application layer protocols
like coap, while I agree we can make all configurable that doesn't
dismiss the fact these interfaces might be reimplemented on top of the
socket layer. In fact the case of net_buf there is probably no
solution since the BSD Socket interface will most likely be using
plain pointers or iovec, so we lose zero copy and possible add yet
another buffer pool on top.

as they either eat the available memory for enabling features
in the stack
Let users select whether they want to save memory or development
effort by using a conventional API ;-).

or reimplement part of the stack in other layers,
Well, here I, as present at the mini-summit, can quote what Anas said
on this: he literally said - don't do that. If "higher level wrapper"
needs to reimplement or otherwise put upside-down what native layer
does, let's just rework native layer to be (more) POSIX/etc.
compatible. And well, that's pretty much how we already do it, with
several features for 1.7 done to make it closer to POSIX spirit, and
there're more such things in queue (here's the latest merged:
https://gerrit.zephyrproject.org/r/12455). So, no worries, or rather,
we all are aware of the problem, and ready to do homework on it.

not to mention this takes a lot of time that could be spend in other
areas like security and proper accelerators for heavy tasks like for
example crypto.
As a maintainer in other projects, I can easily relate to that thought
(that I, a maintainer, know better what contributors rather be working
on ;-) ). But here's how it works at Linaro: our aim is to reduce/avoid
fragmentation among ARM vendors (and not at the expense of more
fragmentation with other architectures). So if a member comes to us and
says "we'll use Zephyr if ...", we'd better listen, because there's no
lack of alternatives to Zephyr, and if interested parties select
something else instead, there won't be anything good from that to
Zephyr, or to the industry at all, which will continue in a chaos of
several dozens of adhoc (vs full-featured) RTOSes. And yeah, BSD
Sockets is a frequent request we heard for a while. Other things you
mention are in the plans (ours including) too.
That is a fair point, but ultimately the memory constraint comes from
the very same vendors. So are there new boards coming with more
memory? 128 K or more ram and a fair bit more flash? Because I can
tell you in most boards memory is already quite tight and that is
without debug enable, in fact echo server don't even work with qemu
when all debugs options are enabled:

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-zephyr-elf/gcc/i586-zephyr-elf/6.2.0/real-ld:
zephyr_prebuilt.elf section `noinit' will not fit in region `RAM'
/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/libexec/i586-zephyr-elf/gcc/i586-zephyr-elf/6.2.0/real-ld:
region `RAM' overflowed by 5520 bytes


--
Luiz Augusto von Dentz


Re: RFC: BSD Socket (like) API

Tomasz Bursztyka
 

Hi Gil,

2) Enable TCP/IP offload from the socket layer.

The TI CC3220 completely offloads the TCP/IP stack onto a
co-processor, by marshalling BSD socket API calls over SPI to the
network coprocessor.

The current NET_OFFLOAD support in the Zephyr IP stack provides a hook
to call an offload engine. For the TI CC3220, this mapping of
net_context APIs to BSD socket APIs adds some overhead and code
complexity.

However, now that we're talking about adding a BSD socket layer to
Zephyr, offloading directly from the socket layer would be more
natural (something similar to the MyNewt solution, as pointed out by
Sterling).

Otherwise, we have to map BSD sockets -> net_context -> BSD sockets,
with all the required extra overhead of data structures, sync
primitives, and server thread(s) to handle mapping between the two
different networking API usage models.

By doing so, I understand we could potentially bypass the (TBD)
routing table. But that is a use case, AFAIK, not really needed for
the CC3220 typical client IoT node devices.
While I understand your point, I still have to point out this is a very specific product use case
that have to fit within a generic solution, not the other way round.

That said, there is still a solution: a Kconfig option that would allow BSD socket API
bypassing net_context/nbuf if - and ONLY if - your offload device is the unique network
device wired up.

But I don't want to push that right now: Let's get first an offload net device working
withing net_context, let's get Paul having first patches for the BSD socket on top of
net_context. And then, we'll see. My point being if we put to much features/expectations
on first round, it will take too much time to get even the basic feature working.

Then again, the POSIX socket standard specifies that sockets shall
support routing, so maybe we can just make that work somehow?
It will, on top of net_context.

Br,

Tomasz


Re: RFC: BSD Socket (like) API

Marcus Shawcroft <marcus.shawcroft@...>
 

On 27 March 2017 at 12:16, Paul Sokolovsky <paul.sokolovsky@linaro.org> wrote:

2- FDs just waste memory, add locking and make things harder to
debug, use socket structures.
Agree. That was one of the 1st question I got at the minisummit, and my
answer was: "well, we could waste some memory by adding the FD table to
map small integers to underlying structures, but why?". Indeed, by just
casting pointers to integers, we can go a long, long way of using this
API and porting existing apps.
Casting pointers to and from integers is legal, but implementation
defined (c99 6.3.2.3 p5 p6). We should avoid implementation defined
behaviour in the language where possible, especially in public APIs.

/Marcus


Re: RFC: BSD Socket (like) API

Daniel Thompson <daniel.thompson@...>
 

On 28/03/17 22:26, Paul Sokolovsky wrote:
So, now the concern is that we are left with two "BSD-like" APIs doing
essentially the same thing, one purporting to use less data space,
though shifting more complexity and code-space up to the application,
and allowing applications to be written one of two (or both?) ways.
Let me start with the latter - I may imagine a particular application
will want to use either "BSD Socket like API" or "native Zephyr API",
but not both at the same time. If this idea is sound, it may help us
to better structure additions for new API (make them less (least)
intrusive).
I'm afraid I *don't* think this idea is sound!

The very reason we want BSD(-like) sockets is because we are importing a big pile of third party library code into our application.

Importing third-party library code must not impose additional requirements on application code (or *other* third party library code) or integration will be a nightmare.


Daniel.

4981 - 5000 of 7679