posted by bluelimn 2018.07.02 14:24

1. cannot get permission for fastboot.

< waiting for any device >


solution:


a. 관련 링크

https://github.com/96boards-hikey/tools-images-hikey960/ 


b. update fastboot

sudo apt install android-tools-adb android-tools-fastboot



c. add usb vendor to the driver(나의 경우엔 이걸로 해결)


$lsusb

Bus 003 Device 007: ID 2232:1045 Silicon Motion

Bus 003 Device 010: ID 18d1:d00d Google Inc.

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub



$sudo vi /etc/udev/rules.d/51-android.rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="18d1", ATTRS{idProduct}=="d00d", MODE="0666", GROUP="plugdev"


$sudo service udev restart

posted by bluelimn 2018.06.25 12:06

#STOP


혐오가 넘쳐나는 세상.

조금 더 살기 좋은 세상을 위해 투쟁하는 것도 좋지만

우선은 혐오를 중단하는 것부터 시작했으면 좋겠다.


남자,여자,동성,이민자,외국인,종교,인종...

혐오와 배척과 경쟁보다 존중을 바탕으로 해결을 찾아나갈 수 있으면 좋겠다.

쉽진 않겠지만.

'bluelimn's > 일상과이상' 카테고리의 다른 글

#STOP  (0) 2018.06.25
Tiwan and Tibet  (0) 2016.01.18
후배  (0) 2015.05.07
이건 뭐지...스팸 경로에 등록된건가?  (0) 2011.12.14
바쁜 와중에 게으름  (0) 2011.02.02
2010 사자성어 ‘장두노미(藏頭露尾)’  (0) 2010.12.19
단풍  (0) 2010.11.14
일상  (1) 2010.09.19
잊어버린다.  (0) 2010.07.23
이건 뭐지?  (1) 2010.05.25
할게 너무 많다  (0) 2010.05.24
TAG
posted by bluelimn 2018.06.18 15:28

./source build/envsetup.sh



select 1

Lunch menu... pick a combo:

     1. aosp_angler-userdebug



Download vendor images

https://developers.google.com/android/blobs-preview



chmod +x extract-qcom-angler.sh

chmod +x extract-huawei-angler.sh


./extract-qcom-angler.sh

./extract-huawei-angler.sh


==========================================

merge 3 fix

https://groups.google.com/forum/#!topic/android-building/JfgzeR_S9N4


prebuilts/tools:

git fetch https://android.googlesource.com/platform/prebuilts/tools refs/changes/02/682002/1 && git cherry-pick FETCH_HEAD

 

external/e2fsprogs/

git fetch https://android.googlesource.com/platform/external/e2fsprogs refs/changes/05/683305/1 && git cherry-pick FETCH_HEAD

 

external/f2fs-tools

git fetch https://android.googlesource.com/platform/external/f2fs-tools refs/changes/06/683306/1 && git cherry-pick FETCH_HEAD



make -j16




=================== Error======================

Error message: 

ninja: error: 'out/host/common/obj/JAVA_LIBRARIES/javapoet-prebuilt-jar_intermediates/classes.jar', needed by 'out/target/common/obj/APPS/Dialer_intermediates/classes-full-debug.jar', missing and no known rule to make it

 

Solution:

https://android-review.googlesource.com/c/platform/external/e2fsprogs/+/683305 

https://android-review.googlesource.com/c/platform/external/f2fs-tools/+/683306 

 

With those 3 patches (first one was 

https://android-review.googlesource.com/c/platform/prebuilts/tools/+/682002 

for anyone who missed that), android-p-preview-2 builds and mostly 

works (tried on Nexus 6P with latest blobs from 

https://developers.google.com/android/blobs-preview ). 

TAG
posted by bluelimn 2018.02.09 15:57

[형제라도 누가 잘 되면 너무 배가 아파]


[그런데 안 되면 마음이 아파]


[마음이 아픈 것 보단 배가 아픈 게 나으니까 차라리 잘 되길 바라는 거야]


'bluelimn's > novel_돼지와바보' 카테고리의 다른 글

배와 마음  (0) 2018.02.09
발랑발랑  (1) 2012.03.09
# 술잔가득  (0) 2008.07.27
# 아르바이트  (0) 2008.07.14
posted by bluelimn 2018.01.30 14:13

원문 : http://www.openssh.com/legacy.html


If the client and server are unable to agree on a mutual set of parameters then the connection will fail. OpenSSH (7.0 and greater) will produce an error message like this:


Unable to negotiate with legacyhost: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1 



For the case of the above error message, OpenSSH can be configured to enable the diffie-hellman-group1-sha1 key exchange algorithm (or any other that is disabled by default) using the KexAlgorithms option - either on the command-line:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@legacyhost 



or in the ~/.ssh/config file:


Host somehost.example.org 

KexAlgorithms +diffie-hellman-group1-sha1 


OpenSSH 7.0 이상에서는 해당 옵션이 기본으로 enable 되어 있지 않기 때문에

옵션을 넣어줘야 한다.

항상 넣기 귀찮으니 config를 만들어서 넣고 쓰도록 하자.

config파일이 없으면 그냥 생성하면 적용 됨.

'Programming > linux왕초보' 카테고리의 다른 글

ssh사용 시 diffie-hellman-group1-sha1 관련  (0) 2018.01.30
pthread min, max priority on linux  (0) 2017.06.12
use vim like as source insight  (0) 2016.04.06
[ubuntu] change default shell  (0) 2016.03.22
GDB를 사용한 CORE 파일의 분석  (0) 2016.02.05
kernel make menuconfig error  (0) 2016.01.21
Caching your GitHub password in Git  (0) 2016.01.08
Serial ports usage on Linux  (0) 2016.01.08
process 종료  (0) 2015.05.28
fork  (0) 2015.05.26
Linux SSD 최적화  (0) 2015.04.17
posted by bluelimn 2017.10.17 17:03

 http://www.ledsmagazine.com/articles/print/volume-13/issue-3/features/smart-lighting/bluetooth-mesh-what-s-that-noise-about.html

Bluetooth Mesh - What's that noise about? (MAGAZINE)

    

Coming Bluetooth extensions will make the wireless technology a better fit for smart lighting, explains MAREK WIERZBICKI, while mesh extensions will retain the low power, ease of use, and reliability of the proven radio technology.

 

Smart lighting might be the biggest revolution the lighting industry has seen in decades, but the multitude of available wireless communication technologies can cause a real headache for manufacturers willing to delve into this new, exciting market. Bluetooth is the latest talk of the town with its mesh networking support to be adopted later this year. We at Silvair have been deeply involved in the Bluetooth Smart Mesh Working Group's efforts aimed at standardizing a Bluetooth-based mesh architecture, and this examination of the basic concepts behind one approach to a Bluetooth Mesh implementation will give you an idea as to what Bluetooth Smart mesh networking is all about.

Interested in more articles & announcements on smart lighting?

Lighting standards we've all known for years are now being challenged by the next generation of lighting systems that promise to deliver so much more than just a well-lit space. The transition toward digital lighting is happening right in front of our eyes, and while a couple of months ago many had doubts as to whether smart lighting could be a real deal, it now seems that there is no turning back. Over the last 12 months, we've seen multiple heavyweight lighting manufacturers spinning off big chunks of their traditional businesses to put more focus on connected technologies (See LEDs Magazinecoverage of Osram). Smart lighting promises new business models with a steady stream of revenue from value-added features and services, which is exactly what lighting companies need to overcome the challenges resulting from the impressive longevity of LEDs and razor-thin margins in the LED market.

SPONSORED CONTENT BY Bluetooth®‎ ?

Bluetooth Mesh Shows Wireless Connectivity in a Whole New Light

Many of today’s wireless platforms—especially those supported by a Bluetooth® mesh network—ensure greater flexibility and extensibility at a much lower cost than a wired system can provide.

FIG. 1. There were a number of Bluetooth-based, mesh-enabled lighting products at the Consumer Electronics Show (CES) in 2016 including a lamp from Girard Sudron and a switch from NodOn.

FIG. 1. There were a number of Bluetooth-based, mesh-enabled lighting products at the Consumer Electronics Show (CES) in 2016 including a lamp from Girard Sudron and a switch from NodOn.

Moving to networks

It is therefore not surprising that virtually every week we are hearing news about lighting manufacturers entering into agreements with companies that can relatively swiftly implement smart technologies into their products, or even straightforwardly acquiring providers of wireless connectivity, cloud services, or advanced data analytics. Things have gone so far that we've already seen Goldman Sachs downgrading its rating on one of the leading lighting manufacturers, citing concerns over the company's deteriorating earnings and emphasizing its low exposure to connected technologies. The trend is clear: Lighting systems are becoming digital, and a wide variety of smart lighting products (Fig. 1) presented at CES (Consumer Electronics Show) 2016 only confirms this.

That said, there is still no consensus regarding the wireless communication protocol that could be the go-to technology for lighting applications, let alone the entire Internet of Things (IoT). Countless times has it been said that the lack of interoperability is a major obstacle to mass adoption of connected solutions, but instead of some sort of standardization, we're only seeing things getting more and more fragmented. New technologies keep emerging, each claiming to have exactly what it takes to enable seamless, robust, and secure connectivity in the Internet of Things (IoT).

In the meantime, the more mature communication standards keep evolving to address the dynamically changing customer needs, as many of them were introduced to the market when expectations and hype surrounding the IoT and connected spaces were nowhere near as big as they are today. What's more, certain product categories did not even exist back then, with smart lighting being a perfect example of a segment that has come a long way from nonexistence to being one of the hottest smart building automation segments over just a couple of years.

One of those mature standards is Bluetooth, a wireless communication protocol that seems to have been around forever and thus enjoys unmatched brand recognition. However, for certain very specific reasons, it is currently not being considered a viable option for advanced building automation solutions. The Bluetooth Special Interest Group (SIG), a 28,000-member strong body that oversees the development of Bluetooth standards, claims this is about to change once the mesh networking support is introduced into the protocol's core specification. We are only a couple of months away from this release, so let's see what's coming.

Bluetooth Classic versus Bluetooth Smart

All that noise surrounding Bluetooth might be somewhat confusing for those not too familiar with the recent developments in the wireless communication landscape. After all, the protocol was first developed before the term "Internet of Things" was even coined. But what many are still not aware of is that the Bluetooth of today is something completely different than Bluetooth of the past.

FIG. 2. Legacy Bluetooth has relied on a hub-and-spoke topology while commercial smart lighting will require a mesh network for communications.

FIG. 2. Legacy Bluetooth has relied on a hub-and-spoke topology while commercial smart lighting will require a mesh network for communications.

The original Bluetooth, known as Bluetooth Classic, was designed as a short-range, cable-replacement technology for point-topoint communications. Initially, the main goal was to synchronize data between mobile phones, but the standard quickly became the default technology for wireless data exchange between personal computing equipment (mobile phones, PCs, PDAs) and peripherals (headsets, cordless keyboards and mice, printers, and such). Devices could form a tiny personal area network (PAN) called a piconet, whereby a single central device would coordinate the activity of up to seven active peripherals.

Fast-forward to 2010, the Bluetooth Core Specification version 4.0 is released, introducing Bluetooth Low Energy (BLE), more commonly known as Bluetooth Smart. This is where the story of Bluetooth in the IoT really begins. Bluetooth Smart was designed specifically to address the needs of a new generation of smart devices, many of which are battery-powered and therefore require fast connection times and efficient power management to reduce unnecessary energy consumption.

The new specification extended Bluetooth's usefulness to a whole new range of products, ultimately making it a default technology for all kinds of wearable devices. But despite some really outstanding features of the Bluetooth Smart radio, the protocol didn't make any significant impact in the building automation segment. Smart homes were dominated by other low-power technologies, mainly ZigBee and Z-Wave, and wireless communication never really took off in commercial spaces. Due to certain important drawbacks of the available low-power communication standards, building managers preferred to stick to wired solutions, considering them way more reliable.

The reason why Bluetooth Smart was never considered a serious contender for building automation purposes is because it was designed to support relatively simple hub-and-spoke networks (Fig. 2). Applications like smart lighting require much more than that. Peer-to-peer communication and extended range are among the must-have features enabling a robust network consisting of multiple smart bulbs, and the core specification of Bluetooth Smart simply didn't provide such capability. Its hub-and-spoke model couldn't match with the mesh topology of ZigBee or Z-Wave networks, and for this reason Bluetooth could never really compete with the two in the applications they were intended for.

Is this meshable?

Even though the support for mesh networking wasn't included in the core specification of Bluetooth Smart, several companies noticed that building a mesh network based on this particular communication standard might not be such a bad idea. In 2014, Silvair (operating as Seed Labs back then) started building a mesh architecture based on Bluetooth Smart. Transforming the protocol's single-hop topology into a robust multi-hop, peer-to-peer network was quite a challenge, but the potential reward was enormous.

A mesh network based on Bluetooth Smart also turned out to offer outstanding performance and the core features of the Bluetooth radio allowed us to overcome many of the challenges that other communication protocols have a hard time dealing with. Obviously, the technology developed by Silvair was proprietary, although we did manage to maintain compliance with Bluetooth Smart's core specification.

Having received a fair amount of input from Silvair and other companies working on their proprietary mesh solutions, the Bluetooth Special Interest Group realized that such an opportunity cannot be wasted. In February 2015, it announced the formation of the Bluetooth Smart Mesh Working Group. Its goal was to standardize mesh networking support and incorporate it into the protocol's core specification. Competing companies sat down to share their experiences and find the best way to implement the mesh architecture into Bluetooth Smart. Near the end of 2015, the SIG officially confirmed that it's on track with the development of the Bluetooth Mesh, and that the standard would be adopted at some point in 2016. Moreover, some major improvements with regard to both the data rate and range of Bluetooth Smart will be included in the new standard.

The standardized mesh architecture based on Bluetooth Smart is shaping up to be a powerful framework enabling robust and scalable implementations in some of the most challenging applications. Being part of that development process and seeing many of our concepts being incorporated into the global standard is a great feeling. We are currently among the leading contributors to the Bluetooth Smart Mesh Working Group. The details about the upcoming mesh standard remain strictly confidential until some official announcements are made by the SIG itself, but we can provide you with a sneak peek into the basic concepts behind our Silvair Mesh technology, which might give you a good idea of what Bluetooth-based mesh networking is all about.

Meet a mesh

Silvair Mesh has been developed to allow users to build their smart mesh networks in which one or more mobile devices (smartphones/tablets) can control one or more mesh-enabled peripheral devices (e.g., lamps, sensors, dimmers, switches, etc.). When equipped with the mesh software stack, essentially an enhanced Bluetooth Smart stack, these devices can communicate with each other and the central controller via the Bluetooth Smart radio using the protocol's standard mechanisms called GATT (Generic Attribute Profile). This means that all mesh-enabled peripherals can create their own autonomous mesh network that does not require any central device to operate.

FIG. 3. Smart mesh capabilities are added to Bluetooth devices in the network, transport, and application layers in software and don't impact the physical and link layers that are captured in radio ICs and modules.

FIG. 3. Smart mesh capabilities are added to Bluetooth devices in the network, transport, and application layers in software and don't impact the physical and link layers that are captured in radio ICs and modules.

The decision to base Silvair Mesh on Bluetooth Smart was intentional, as it meant that the ecosystem would be compatible with all existing Bluetooth Smart devices and chipsets. However, a mesh stack also requires numerous additional features to standard Bluetooth Smart. For instance, the Silvair Mesh includes a high-performance Bluetooth controller and a new Network Security Manager, as well as the secure OverThe-Air Update functionality, which means that a device can be upgraded to the newest version of the firmware at any time.

Such a carefully crafted mesh software stack can be installed on any compatible Bluetooth chip. Silvair also developed a reference design for modules to provide the best possible solution for large installations such as those found in commercial buildings. These modules consist of standard Texas Instruments CC254x Bluetooth modules with upgraded firmware, an amplifier, and an antenna. Operating at +10-dBm Tx (transmit) power and with -98-dBm Rx (receive) sensitivity, the modules provide a 108-dB link budget that translates to a range of 1500 ft (about 500m) in the open air. Inside buildings, this value will obviously be much lower and dependent on numerous factors, yet it still remains impressive.

An important thing to realize is that mesh is a purely software solution. This means that Bluetooth Smart chipsets found in today's smartphones can control devices employing proprietary technologies such as Silvair Mesh, and will remain perfectly suitable for controlling and managing mesh networks once the standard is adopted by the SIG. The aforementioned software stack is applied to the networking and application layers of the standard Bluetooth Smart protocol stack as shown in Fig. 3.

How the mesh works

Now let's consider how the mesh extension works. There are two types of communication within a Silvair Mesh network: central to peripheral and peripheral to peripheral. Once the mesh network is commissioned, there is no need for further central-peripheral communication.

Central devices are usually smartphones and tablets. Such devices would typically run some type of control software. In the Silvair case, we developed an app for iOS and Android devices. The central devices are used to configure and manage the network but can also perform a software update of peripheral devices. Central devices connect to peripherals using Bluetooth Smart's standard GATT services. While this type of connection is fully compatible with Bluetooth 4.0, it employs certain proprietary techniques to allow many smartphones to be used simultaneously to control more than eight peripheral devices with eight being the limit in standard Bluetooth 4.0.

Peripheral devices are the nodes of a mesh network. A robust mesh implementation must allow peripherals to talk to each other and act as relays that pass messages through the mesh. This is a radical departure from the original architecture of Bluetooth Smart, and it allows for controlling entire groups of devices using multicast (one to many) communications - e.g., dimming a group of ceiling lights in a hallway. The Silvair Mesh implementation allows a maximum of 63 hops, which enables it to cover very extensive areas out of the box, in contrast to other technologies that require setting up more complicated or more expensive networks.

One of the most significant concepts introduced in the Silvair implementation is connectionless communication, which means that every peripheral can advertise its status in the network. As a result, lights, fans, shades, and any other mesh-enabled device are displayed automatically in the app on the central device, not only as a simple list of available devices, but with very specific parameters that can be controlled by the user - e.g., on/off, color, temperature, fan speed, or shade position. Every status change made by the user is immediately advertised to the network, and every controlling device in the mesh is updated instantly with the new status.

Network setup

As will be required in commercial applications, the Silvair Mesh software allows networks of any size to be set up, but the way in which large and small networks are commissioned, is different. Small networks of up to about 30 devices can be commissioned and managed using just the app on a smartphone or a tablet. The plug-and-play nature of Bluetooth, and the fact that the protocol is natively supported by virtually all smartphones and tablets on the market, makes the entire process extremely simple and intuitive. The app detects and displays mesh devices in its vicinity. The user creates a mesh network by selecting which devices should be added, and by giving the network a name. Once added to the network, associations and relationships can be set up between the devices as desired. The smartphone can then be switched off and these connections will remain in place (Fig. 4).

FIG. 4. Silvair Mesh supports both smaller mesh networks controlled by a single smartphone and complex networks with dedicated cloud-connected servers.

FIG. 4. Silvair Mesh supports both smaller mesh networks controlled by a single smartphone and complex networks with dedicated cloud-connected servers.

Networks of over about 30 devices, or the ones requiring more sophisticated associations, scenarios, and network monitoring services, are best set up using some type of server or management appliance. In the case of Silvair, an embedded server called Silvair Logic hosts all the logic that controls the entire network, checks the status of all peripherals, and reports any issues and unusual events via a browser-based interface.

Other mesh needs

There are a few other key elements of a Bluetooth Mesh implementation that we will mention briefly here. There needs to be a concept of permissions for control devices that ensures proper management of devices in the network. The Silvair software stack implements four levels of permissions: 1) Administrator - can operate all devices within the network, as well as configure them and manage other users' permissions; 2) Family - can operate all devices within the network, but cannot configure or manage them; 3) Guest - has limited permission to operate selected devices within the network; 4) and AdHoc - can operate public devices only on a one-to-one basis (no access to the mesh network).

Likewise, the network nodes or peripherals require the ability to provide information on their operational status and programmability. The Silvair software stack defines three Peripheral Device States: 1) Factory Default - the device leaves the factory in this state and is ready for commissioning; 2) Private - all communication is encrypted, so only users with matching keys can decrypt the state information and control the device; and 3) Public - state information, as well as selected control functions, are not encrypted and can be accessed by anyone.

The Bluetooth difference

The question one might ask at this point is why the Bluetooth Smart mesh would be any better than other mesh protocols available on the market? Simply put, it's all about the radio. Out of all low-power, low-bandwidth communication standards, none is even close to having such impressive qualities as Bluetooth Smart. This allows the protocol to address some of the most difficult issues in such challenging applications as smart lighting, where multicast, synchronous operation and responsiveness are among the must-have features.

We've tested many other technologies inside out, and we know exactly why the existing mesh protocols have failed to deliver the smart lighting experience to environments where reliability and scalability are top priorities. And we firmly believe that this year's adoption of the Bluetooth Smart mesh standard might finally open the door for smart lighting networks to become widely deployed in professional applications.


'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.10.17 17:02

https://en.wikipedia.org/wiki/Bluetooth_mesh_networking


Bluetooth mesh networking, conceived in 2015,[1] adopted on July 13, 2017[2] is a protocol based upon Bluetooth Low Energy that allows for many-to-many communication over Bluetooth radio.

It has been defined in Mesh Profile Specification[3] and Mesh Model Specification.[4]

Overview[edit]

Communication is carried in the messages that may be up to 384 bytes long, when using Segmentation and Reassembly (SAR) mechanism, but most of the messages fit in one segment, that is 11 bytes. Each message starts with an opcode, which may be a single byte (for special messages), 2 bytes (for standard messages), or 3 bytes (for vendor-specific messages).

Every message has a source and a destination address, determining which devices process messages. Devices publish messages to destinations which can be single things / groups of things / everything.

Each message has a sequence number that protects the network against replay attacks.

Each message is encrypted and authenticated. Two keys are used to secure messages: (1) network keys – allocated to a single mesh network, (2) application keys – specific for a given application functionality, e.g. turning the light on vs reconfiguring the light.

Messages have a time to live (TTL). Each time message is received and retransmitted, TTL is decremented which limits the number of "hops", eliminating endless loops.

Bluetooth Mesh is a flood network. It's based on the nodes relaying the messages: every relay node that receives a network packet that authenticates against a known network key that is not in message cache, that has a TTL ≥ 2 can be retransmitted with TTL = TTL - 1. Message cache used to prevent relaying messages recently seen.

Bluetooth Mesh has a layered architecture, with multiple layers as below.

LayerFunctionality
Model LayerIt defines a standard way to exchange application specific messages. For example, a Light Lightness Model defines an interoperable way to control lightness. There are mandatory models, called Foundation Models, defining states and messages needed to manage a mesh network.
Access LayerIt defines mechanism to ensure that data is transmitted and received in the right context of a model and its associated application keys.
Upper Transport LayerIt defines authenticated encryption of access layer packets using an application (or device specific key). It also defines some control messages to manage Friendship or to notify the behavior of node using Heartbeat messages.
Lower Transport LayerThis layer defines a reliable (through a Block Acknowledgement) Segmented transmission upper layer packets, when a complete upper layer packet can't be carried in a single network layer packet. It also defines a mechanism to reassemble segments on the receiver.
Network LayerThis layer defines how transport packets are addressed over network to one or more nodes. It defines relay functionality for forwarding messages by a relay node to extended the range. It handles the network layer authenticated encryption using network key.
Bearer LayerIt defines how the network packets are exchanged between nodes. Mesh Profile Specification defines BLE advert bearer and BLE GATT bearer. Mesh Profile defines Proxy Protocol, through which mesh packets can be exchanged via other bearers like TCP/IP.

Theoretical limits[edit]

It's yet to be determined what are the practical limits of Bluetooth Mesh technology. There are some limits that are built into the specification, though:

Limit for a networkValueRemarks
Maximum number of nodes32 767The limit is 32768 addresses and while a node may occupy more than one address, practical limit is most likely lower
Maximum number of groups16 384

Number of virtual groups is 2128.

Maximum number of scenes65 535
Maximum number of subnets4 096
Maximum TTL127

Mesh models[edit]

As of version 1.0 of Bluetooth Mesh specification, the following standard models and model groups have been defined:

Foundation models[edit]

Foundation models have been defined in the core specification. Two of them are mandatory for all mesh nodes.

  • Configuration Server (mandatory)
  • Configuration Client
  • Health Server (mandatory)
  • Health Client

Generic models[edit]

  • Generic OnOff Server, used to represent devices that do not fit any of the model descriptions defined but support the generic properties of On/Off
  • Generic Level Server, keeping the state of an element in a 16-bit signed integer
  • Generic Default Transition Time Server, used to represent a default transition time for a variety of devices
  • Generic Power OnOff Server & Generic Power OnOff Setup Server, used to represent devices that do not fit any of the model descriptions but support the generic properties of On/Off
  • Generic Power Level Server & Generic Power Level Setup Server, including a Generic Power Actual state, a Generic Power Last state, a Generic Power Default state and a Generic Power Range state
  • Generic Battery Server, representing a set of four values representing the state of a battery
  • Generic Location Server & Generic Location Setup Server, representing location information of an element, either global (Lat/Lon) or local
  • Generic User/Admin/Manufacturer/Client Property Server, representing any value to be stored by an element
  • Generic OnOff Client & Generic Level Client
  • Generic Default Transition Time Client
  • Generic Power OnOff Client & Generic Power Level Client
  • Generic Battery Client
  • Generic Location Client
  • Generic Property Client

Sensors[edit]

  • Sensor Server & Sensor Setup Server, representing a sensor device. Sensor device may be configured to return a measured value periodically or on request; measurement period (cadence) may be configured to be fixed or to change, so that more important value range is being reported faster.
  • Sensor Client

Time and scenes[edit]

  • Time Server & Time Setup Server, allowing for time synchronization in mesh network
  • Scene Server & Scene Setup Server, allowing for up to 65535 scenes to be configured and recalled when needed.
  • Scheduler Server & Scheduler Setup Server
  • Time Client, Scene Client & Scheduler Client

Lighting[edit]

  • Light Lightness Server & Light Lightness Setup Server, representing a dimmable light source
  • Light CTL Server, Light CTL Temperature Server & Light CTL Setup Server, representing a CCT or "tunable white" light source
  • Light HSL Server, Light HSL Hue Server, Light HSL Saturation Server & Light HSL Setup Server, representing a light source based on Hue, Saturation, Lightness color representation
  • Light xyL Server & Light xyL Setup Server, representing a light source based on modified CIE xyY color space.
  • Light LC (Lightness Control) Server & Light LC Setup Server, representing a light control device, able to control Light Lightness model using an occupancy sensor and ambient light sensor. It may be used for light control scenarios like Auto-On, Auto-Off and/or Daylight Harvesting.
  • Light Lightness Client, Light CTL Client, Light HSL Client, Light xyL Client & Light LC Client

Provisioning[edit]

Provisioning is a process of installing the device into a network. It is a mandatory step to build a Bluetooth Mesh network.

In the provisioning process, a provisioner securely distributes a network key and a unique address space for a device. Provisioning protocol uses P256 Elliptic Curve Diffie-HellmanKey Exchange to create a temporary key to encrypt network key and other information. This provides security from a passive eavesdropper. It also provides various authentication mechanisms to protect network information, from an active eavesdropper who uses Man-In-The-Middle attack, during provisioning process.

A key unique to a device known as "Device Key" is derived from elliptic curve shared secret on provisioner and device during the provisioning process. This device key is used by the provisioner to encrypt messages for that specific device.

Terminology used in Bluetooth mesh networking specification[edit]

  • Destination: The address to which a message is sent.
  • Element: An addressable entity within a device.
  • Model: Standardized operation of typical user scenarios.
  • Node: A provisioned device.
  • Provisioner: A node that can add a device to a mesh network.
  • Relay: A node able to retransmit messages.
  • Source: The address from which a message is sent.


'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.10.16 17:54

원문보기: 
http://www.itworld.co.kr/news/105679#csidxa5d4a62d448be1a929a02c4376d2927 

by ItWord : Peter Sayer | IDG News Service



블루투스에 새로운 메시(mesh) 네트워킹 기능이 곧 구현된다. 무엇보다 좋은 점은 새로운 하드웨어가 없어도 활용이 가능하다는 것이다.

메시 네트워킹을 사용하면 산업 현장에서 센서를 연결하거나 스마트 홈 또는 건물 자동화 네트워크를 생성하는 과정이 더 간편해진다. 기기는 멀리 떨어진 게이트웨이까지 메시지를 전달할 필요없이 가까운 이웃에게 메시지를 전달하도록 요청하면 된다.


Credit: Stephen Lawson

이는 기기에서 사물인터넷에 참여할 수 있는 새로운 방법을 제공한다. 블루투스 표준을 관할하는 기구인 블루투스 SIG의 기술 프로그램 관리자 마틴 울리는 "예를 들어 건물에서 조명 제어 용도로 메시 네트워크를 구축할 경우 다른 기기에서 자산 추적, 길찾기 등 다른 분야를 위한 무선 인프라로 이 네트워크를 사용할 수 있다"고 말했다.

블루투스는 메시 네트워킹을 저전력 블루투스(Bluetooth Low Energy, BLE)에 구축된 네트워킹 토폴로지로 취급하므로 이를 지원하는 기기가 있다면 소프트웨어 업데이트를 통해 메시에 참여할 수 있을 가능성이 높다. 스마트폰과 태블릿도 마찬가지다. BLE를 지원한다면 앱만 있으면 바로 메싱을 시작할 수 있다.

지난 7월 18일, 블루투스 메시 네트워킹 표준 버전 1.0이 발표되어 호환 기기가 앞다퉈 등장하겠지만 이미 경주는 진행 중이다.

울리는 "일반적인 블루투스 SIG 워킹 그룹에 참여하는 기업 수가 10~20개 정도인데 반해 블루투스 메시 네트워킹 개발 워킹 그룹에는 120여 개의 기업이 참여한만큼 업계는 이미 이 사양의 요구사항을 잘 파악하고 있다"고 말했다.

요구사항 테스트도 이미 마쳤다. 울리는 "테스트를 해야 사양을 완성할 수 있다. 이미 15개의 테스팅 이벤트를 통해 전체 사양을 다뤘다"고 밝혔다. 울리는 블루투스 메시 스택이 있는 하드웨어 모듈이 몇 개월 내에 시장에 등장할 것이라고 말했다. 업체에서 부가적인 소프트웨어를 명분으로 더 높은 가격을 요구할 수 있지만 울리는 자신이 아는 한 새로운 기능을 이용하기 위해 필요한 부가적인 특허 라이선스는 없다고 전했다.

블루투스 메시 네트워크에서는 노드가 생성되는 방법이 각기 다르다. 조명 기구의 컨트롤러와 같이 전력이 충분히 공급되는 장치도 있고, 전등 스위치나 온도 센서와 같이 배터리 하나로 수년 동안 작동해야 하는 장치도 있기 때문이다. 사양은 이런 기기에서 에너지를 절약할 수 있는 두 가지 방법을 제공한다.

하나는 메시지 전송을 위한 "게시 및 가입(publish and subscribe)" 모델이다. 예를 들어 부엌 전등 스위치라면 켜고 꺼야 할 기기의 주소 목록을 유지하기 위해 전기를 소비할 필요가 없다. 대신 "부엌 조명" 목록에서 참고하도록 표시된 "켜기" 메시지만 게시하면 된다. 이 메시지는 메시를 따라 전달되고, 각 기기들은 그 목록에 가입되어 있는지 여부에 따라 메시지에 응해 작동할지 여부를 스스로 판단한다.

다른 방법은 에너지 공급이 제한된 기기에서 "친구"를 호출하는 것이다. 예를 들어 온도 센서에서 주기적으로 판독값을 전송할 필요없이 온도가 정해진 범위를 벗어날 때만 보고하면 된다고 가정해 보자. 이렇게 하면 드물게 발생하는 예외만 전송하면 되므로 전송에 사용되는 에너지를 절약할 수 있다.

그러나 설정 온도 범위 업데이트를 받기 위해 지속적으로 수신 대기를 하게 되면 배터리가 금방 소진될 수 있다. 전원이 충분히 공급되는 기기를 친구로 해서 기기를 설계하면 이 센서는 하루에 한 번(또는 원하는 간격으로) 라디오 수신기를 켜면 되고, 이때 친구가 센서 오프라인 동안 전송된 모든 메시지를 전달해준다. 휴가 중에 우편함을 확인하러 매일 집으로 다시 올 필요 없이 이웃이 우편물을 대신 받아두는 것이라고 생각하면 된다.

가입할 메시 네트워크를 선택하거나 친구로 설정할 기기를 선택하는 과정은 두 블루투스 기기를 페어링해 포인트 투 포인트 연결을 구성하는 것보다는 조금 더 복잡하다.

프로비저닝(provisioning)이라고 하는 이 프로세스에는 블루투스 지원 스마트폰, 태블릿 또는 컴퓨터에서 실행되는 앱이 필요하다. 전구, 산업용 센서 또는 보안 카메라와 같은 새 메시 기기는 프로비전되지 않은 상태로 제공되므로 네트워크에 노드로 가입하려면 앱에서 암호화 키를 다운로드해야 한다.

동일한 앱을 사용해 키를 폐기할 수도 있으므로 망가진 전구를 안전하게 버릴 수 있다. 이렇게 하면 누군가 쓰레기 더미를 뒤져 버려진 전구에서 키를 복구해 네트워크에 침입할 위험이 없다.

이 사양의 개발자들은 재전송 공격(replay attacks)으로부터 블루투스 메시 네트워크를 보호하기 위해 각 메시지에 고유한 시퀀스 번호가 있는지 확인하도록 했다.

또한 이 사양은 네트워크 인프라와 여기서 실행되는 애플리케이션에 대해 서로 다른 암호화 계층을 제공한다. 예를 들어 호텔의 스마트 조명 네트워크가 호텔 객실 도어 잠금을 여는 메시지를 전달할 수 있지만 애초에 이 메시지를 생성하는 데 필요한 암호화 키는 호텔의 스마트폰 앱에만 보관할 수 있다.

ABI 리서치(ABI Research)의 선임 분석가 앤드류 지그나니는 메시 네트워킹의 도입은 블루투스가 기존의 작동 범위와 네트워크 규모 제한을 극복하는 데 도움이 될 것으로 전망했다.

지그나니는 "메시 네트워킹은 블루투스 혁신의 새로운 단계이며, 블루투스가 개인 영역 네트워크 및 페어링(pairing) 기술에서 우리 주변의 사물에 연결하는 기능을 갖춘 더 넓은 범위의 강력한 저전력 IoT 연결 솔루션으로 전환하는 데 핵심적인 역할을 할 것"이라고 예상했다. editor@itworld.co.kr


'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.10.16 15:43

Mesh Profile


▪ Revision: v1.0

▪ Revision Date: 2017-Jul-13

▪ Group Prepared By: Mesh Working Group


1.3.2 Acronyms and abbreviations

Abbreviation or Acronym

Meaning

ACK

Acknowledgment

AD

Advertising Data

AES

Advanced Encryption Standard

AID

Application Key Identifier

AKF

Application Key Flag

ASCII

American Standard Code for Information Interchange

ATT

Attribute Protocol

ATT_MTU

Attribute Protocol Maximum Transmission Unit

BR/EDR

Basic Rate / Enhanced Data Rate

CCM

Counter with CBC-MAC

CID

Company Identifier

CMAC

Cipher-based Message Authentication Code

CTL

Network control message indication

DST

Destination

ECB

Electronic CodeBook

ECDH

Elliptic Curve Diffie-Hellman

FCS

Frame Check Sequence

FIPS

Federal Information Processing Standards

FSN

Friend Sequence Number

GAP

Generic Access Profile

GATT

Generic Attribute Profile

ID

Identifier

IEEE

Institute of Electrical and Electronics Engineers

IKM

Input Key Material

IVI

Initialization Vector Index

JSON

JavaScript Object Notation

LED

Light Emitting Diode

LSO

Least Significant Octet

MAC

Message Authentication Code

MD

More Data

MIC

Message Integrity Check

MSO

Most Significant Octet

MTU

Maximum Transmission Unit

NID

Network Identifier

OBO

On Behalf Of (another element)

OKM

Output Key Material

OOB

Out of Band

PDU

Protocol Data Unit

PID

Product Identifier

RFU

Reserved for Future Use

RPL

Replay Protection List

RSSI

Received Signal Strength Indicator

SAR

Segmentation And Reassembly

SEG

Segmentation indication bit

SEQ

Sequence Number

SIG

Special Interest Group

SRC

Source

SZMIC

Size of Message Integrity Check

TTL

Time To Live

URI

Uniform Resource Indicator

UUID

Universally Unique Identifier

VID

Version Identifier

WG

Working Group

 

1.3.3 Terminology

Term

Definition

Address

The identity of one or more elements in one or more nodes.

Configuration Client

A node that implements the Configuration Client model.

Destination

The address to which a message is sent.

Device

An entity that is capable of being provisioned onto a mesh network.

Element

An addressable entity within a device. A device is required to have at least one element.

Message

A sequence of octets that is sent from a source to a destination.

Neighbors

Nodes in direct radio range (single hop).

Network

A group of nodes sharing a common address space.

Node

A provisioned device.

Provision

The process of authenticating and providing basic information (including unicast addresses and a network key) to a device. A device must be provisioned to become a node. Once provisioned, a node can transmit or receive messages in a mesh network.

Provisioner

A node that is capable of adding a device to a mesh network.

Relay

A node that receives and then retransmits messages.

Source

The address from which a message is sent.

State

A value representing a condition of an element that is exposed by an element of a node.

Subnet

A group of nodes that can communicate with each other.


 

'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.09.08 15:24

 

 

Clock delta : 0x0c (12)

Time delta : 003750

Calc : 12  * 625 / 2

 

Clock 625/2 이유는 625μs 확인하기 위해서는 최소한 2배의 속도로 체크해야 하기 때문이다.

 

 

1.1 BLUETOOTH CLOCK
Every Bluetooth device shall have a native clock that shall be derived from a
free running reference clock. Offsets may be added to the reference clock to
synchronize the native clock with other non-Bluetooth systems. For
synchronization with other Bluetooth devices, offsets are used that, when
added to the native clock, provide temporary Bluetooth clocks that are mutually
synchronized. It should be noted that the Bluetooth clock has no relation to the
time of day; it may therefore be initialized to any value. The clock has a cycle of
about a day. If the clock is implemented with a counter, a 28-bit counter is
required that shall wrap around at 228-1. The least significant bit (LSB) shall
tick in units of 312.5 μs (i.e. half a time slot), giving a clock rate of 3.2 kHz.
The clock determines critical periods and triggers the events in the device.
Four periods are important in the Bluetooth system: 312.5 μs, 625 μs, 1.25 ms,
and 1.28 s; these periods correspond to the timer bits CLK0, CLK1, CLK2, and
CLK12, respectively, see Figure 1.4 on page 68.

 

Bluetooth Air에서 기본으로 사용하는 시간 단위는 625 μs.

 

 

2.2.5.1 Piconet physical channel timing
In the figures, only single-slot packets are shown as an example.
The master TX/RX timing is shown in Figure 2.3 on page 76. In Figure 2.3 and
Figure 2.4 the channel hopping frequencies are indicated by f(k) where k is the
time slot number. After transmission, a return packet is expected N × 625 μs
after the start of the TX packet where N is an odd, integer larger than 0. N
depends on the type of the transmitted packet.
To allow for some time slipping, an uncertainty window is defined around the
exact receive timing. During normal operation, the window length shall be 20
μs, which allows the RX packet to arrive up to 10 μs too early or 10 μs too late.

It is recommended that slaves implement variable sized windows or time
tracking to accommodate a master's absence of more than 250ms.
During the beginning of the RX cycle, the access correlator shall search for the
correct channel access code over the uncertainty window. If an event trigger
does not occur the receiver may go to sleep until the next RX event. If in the
course of the search, it becomes apparent that the correlation output will never
exceed the final threshold, the receiver may go to sleep earlier. If a trigger
event occurs, the receiver shall remain open to receive the rest of the packet
unless the packet is for another device, a non-recoverable header error is
detected, or a non-recoverable payload error is detected.

 

Bluetooth에서는 clock에 대한 시간 오차를 기준에서 앞/뒤 10μs 까지는 허용한다.

즉, 기준에서 10μs를 벗어나면 안 된다.

 

'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.09.08 15:08

 

 

Baseband에 ACK와 NACK로 SEQN(Sequence Number)이 결정됨.

기본적으로 SEQN은 data packet에 대해서만 0,1로 변경 된다.

이 때, 동일한 LT_ADDR에 대해서 SEQN을 확인 한다.

위의 이미지에서 LMP의 LT_ADDR이 3이므로 동일한 3에 대해서 check함.

 

Receiver는 data packet에 대해 정상 수신하면 ARQN에 1을 주고 잘못된 data를 받으면 0을 준다.

Receiver는 data packet 또는 NULL/POLL에 ARQN을 줄 수 있다.

 

Sender는 ARQN으로 1을 받으면 다음 data packet에 자신의 SEQN을 변경한다.

만약 Receiver가 응답이 없거나 ARQN으로 0을 보내면 retransmit packet을 보낸다.

'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Mesh - What's that noise about? (MAGAZINE)  (1) 2017.10.17
Bluetooth mesh networking From Wikipedia  (0) 2017.10.17
"블루투스의 혁신" 블루투스 메시 네트워크 표준 발표로 IoT 확산  (0) 2017.10.16
Mesh Profile  (0) 2017.10.16
Air packet에서 Bluetooth clock 확인  (0) 2017.09.08
baseband ack nack concept  (0) 2017.09.08
bluetooth timeout spec  (1) 2016.01.28
RFComm  (0) 2016.01.07
GPP(Generic PIM Profile)  (0) 2015.12.15
Paging and Inquiry  (0) 2015.11.26
AVDTP signaling/Media  (0) 2014.10.23
posted by bluelimn 2017.06.12 17:14

Original link : https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_MRG/1.2/html/Realtime_Reference_Guide/sect-Realtime_Reference_Guide-Using_library_calls_to_set_priority-sched_get_priority_min_and_sched_get_priority_max.html


#include <stdio.h>
#include <unistd.h>
#include <sched.h>

main()
{


  printf("Valid priority range for SCHED_OTHER: %d - %d\n",
  sched_get_priority_min(SCHED_OTHER),
  sched_get_priority_max(SCHED_OTHER));

  printf("Valid priority range for SCHED_FIFO: %d - %d\n",
  sched_get_priority_min(SCHED_FIFO),
  sched_get_priority_max(SCHED_FIFO));

  printf("Valid priority range for SCHED_RR: %d - %d\n",
  sched_get_priority_min(SCHED_RR),
  sched_get_priority_max(SCHED_RR));
}


Output

Valid priority range for SCHED_OTHER: 0 - 0

Valid priority range for SCHED_FIFO: 1 - 99

Valid priority range for SCHED_RR: 1 - 99



'Programming > linux왕초보' 카테고리의 다른 글

ssh사용 시 diffie-hellman-group1-sha1 관련  (0) 2018.01.30
pthread min, max priority on linux  (0) 2017.06.12
use vim like as source insight  (0) 2016.04.06
[ubuntu] change default shell  (0) 2016.03.22
GDB를 사용한 CORE 파일의 분석  (0) 2016.02.05
kernel make menuconfig error  (0) 2016.01.21
Caching your GitHub password in Git  (0) 2016.01.08
Serial ports usage on Linux  (0) 2016.01.08
process 종료  (0) 2015.05.28
fork  (0) 2015.05.26
Linux SSD 최적화  (0) 2015.04.17
posted by bluelimn 2017.05.29 15:55

original link : http://techqa.info/programming/question/28285850/Opensuse-13-1-build-envsetup-sh--syntax-error-near-unexpected-token------r--



Error:

bash: build/envsetup.sh: line 1: syntax error near unexpected token $'{\r'' 'ash: build/envsetup.sh: line 1:function hmm() {


Solve:

The problem comes from Windows end-of-lines (EOL) so you'll have to convert all scripts to unix-style EOL through dos2unix (run apt-get install dos2unix on Ubuntu) and then convert your scripts:

dos2unix build/envsetup.sh sdk/bash_completion/adb.bash

Then all vendorsetup.sh (that will prevent the "command not found" error you get):

find device/ -name vendorsetup.sh -exec dos2unix {} \;

And one last to run the choosecombo script:

dos2unix build/core/find-jdk-tools-jar.sh

EDIT: In order to finish the overall compilation, the exhaustive conversion:

find . -name '*.sh' -exec dos2unix {} \;
find . -name '*.py' -exec dos2unix {} \;
find . -name '*.c' -exec dos2unix {} \;
find . -name '*.h' -exec dos2unix {} \;
find . -name '*.cpp' -exec dos2unix {} \;
find . -name '*.hpp' -exec dos2unix {} \;
find . -name '*.txt' -exec dos2unix {} \;
find . -name 'Config.in' -exec dos2unix {} \;
find . -name 'Config.src' -exec dos2unix {} \;
find . -name 'Makefile' -exec dos2unix {} \;
find . -name 'mkmakefile' -exec dos2unix {} \;
find . -name 'Kconfig*' -exec dos2unix {} \;
find . -name rmtypedefs -exec dos2unix {} \;
find . -name apicheck -exec dos2unix {} \;
find . -name seapp_contexts -exec dos2unix {} \;
dos2unix external/busybox/scripts/* external/busybox/applets/* kernel/scripts/* dalvik/dx/etc/* prebuilts/sdk/tools/*

The *.sh for all shell scripts, and *.py for all python scripts (used during make compilation), as well as .c and .cpp file (obviously) and other files used by makefiles.

Of course you could go the over-overkill find . -type f -exec dos2unix -s -k -o {} \; and let dos2unix decide which files are text and which are binary.

There might be other. I'll edit this answer as I find new ones...

posted by bluelimn 2017.05.24 12:18

Error:


Checking API: checkapi-last

out/target/common/obj/PACKAGING/public_api.txt:23556: error 12: Class android.telephony.gsm.SmsMessage changed static qualifier

prebuilts/sdk/api/19.txt:23513: error 9: Removed public constructor SmsMessage()

prebuilts/sdk/api/19.txt:23514: error 9: Removed public method android.telephony.gsm.SmsMessage.calculateLength

prebuilts/sdk/api/19.txt:23515: error 9: Removed public method android.telephony.gsm.SmsMessage.calculateLength

prebuilts/sdk/api/19.txt:23516: error 9: Removed public method android.telephony.gsm.SmsMessage.createFromPdu

prebuilts/sdk/api/19.txt:23517: error 9: Removed public method android.telephony.gsm.SmsMessage.getDisplayMessageBody

prebuilts/sdk/api/19.txt:23518: error 9: Removed public method android.telephony.gsm.SmsMessage.getDisplayOriginatingAddress

prebuilts/sdk/api/19.txt:23519: error 9: Removed public method android.telephony.gsm.SmsMessage.getEmailBody

prebuilts/sdk/api/19.txt:23520: error 9: Removed public method android.telephony.gsm.SmsMessage.getEmailFrom

prebuilts/sdk/api/19.txt:23521: error 9: Removed public method android.telephony.gsm.SmsMessage.getIndexOnSim

prebuilts/sdk/api/19.txt:23522: error 9: Removed public method android.telephony.gsm.SmsMessage.getMessageBody

prebuilts/sdk/api/19.txt:23523: error 9: Removed public method android.telephony.gsm.SmsMessage.getMessageClass

prebuilts/sdk/api/19.txt:23524: error 9: Removed public method android.telephony.gsm.SmsMessage.getOriginatingAddress

prebuilts/sdk/api/19.txt:23525: error 9: Removed public method android.telephony.gsm.SmsMessage.getPdu

prebuilts/sdk/api/19.txt:23526: error 9: Removed public method android.telephony.gsm.SmsMessage.getProtocolIdentifier

prebuilts/sdk/api/19.txt:23527: error 9: Removed public method android.telephony.gsm.SmsMessage.getPseudoSubject

prebuilts/sdk/api/19.txt:23528: error 9: Removed public method android.telephony.gsm.SmsMessage.getServiceCenterAddress

prebuilts/sdk/api/19.txt:23529: error 9: Removed public method android.telephony.gsm.SmsMessage.getStatus

prebuilts/sdk/api/19.txt:23530: error 9: Removed public method android.telephony.gsm.SmsMessage.getStatusOnSim

prebuilts/sdk/api/19.txt:23531: error 9: Removed public method android.telephony.gsm.SmsMessage.getSubmitPdu

prebuilts/sdk/api/19.txt:23532: error 9: Removed public method android.telephony.gsm.SmsMessage.getSubmitPdu

prebuilts/sdk/api/19.txt:23533: error 9: Removed public method android.telephony.gsm.SmsMessage.getTPLayerLengthForPDU

prebuilts/sdk/api/19.txt:23534: error 9: Removed public method android.telephony.gsm.SmsMessage.getTimestampMillis

prebuilts/sdk/api/19.txt:23535: error 9: Removed public method android.telephony.gsm.SmsMessage.getUserData

prebuilts/sdk/api/19.txt:23536: error 9: Removed public method android.telephony.gsm.SmsMessage.isCphsMwiMessage

prebuilts/sdk/api/19.txt:23537: error 9: Removed public method android.telephony.gsm.SmsMessage.isEmail

prebuilts/sdk/api/19.txt:23538: error 9: Removed public method android.telephony.gsm.SmsMessage.isMWIClearMessage

prebuilts/sdk/api/19.txt:23539: error 9: Removed public method android.telephony.gsm.SmsMessage.isMWISetMessage

prebuilts/sdk/api/19.txt:23540: error 9: Removed public method android.telephony.gsm.SmsMessage.isMwiDontStore

prebuilts/sdk/api/19.txt:23541: error 9: Removed public method android.telephony.gsm.SmsMessage.isReplace

prebuilts/sdk/api/19.txt:23542: error 9: Removed public method android.telephony.gsm.SmsMessage.isReplyPathPresent

prebuilts/sdk/api/19.txt:23543: error 9: Removed public method android.telephony.gsm.SmsMessage.isStatusReportMessage

prebuilts/sdk/api/19.txt:23544: error 10: Removed field android.telephony.gsm.SmsMessage.ENCODING_16BIT

prebuilts/sdk/api/19.txt:23545: error 10: Removed field android.telephony.gsm.SmsMessage.ENCODING_7BIT

prebuilts/sdk/api/19.txt:23546: error 10: Removed field android.telephony.gsm.SmsMessage.ENCODING_8BIT

prebuilts/sdk/api/19.txt:23547: error 10: Removed field android.telephony.gsm.SmsMessage.ENCODING_UNKNOWN

prebuilts/sdk/api/19.txt:23548: error 10: Removed field android.telephony.gsm.SmsMessage.MAX_USER_DATA_BYTES

prebuilts/sdk/api/19.txt:23549: error 10: Removed field android.telephony.gsm.SmsMessage.MAX_USER_DATA_SEPTETS

prebuilts/sdk/api/19.txt:23550: error 10: Removed field android.telephony.gsm.SmsMessage.MAX_USER_DATA_SEPTETS_WITH_HEADER


******************************

You have tried to change the API from what has been previously released in

an SDK.  Please fix the errors listed above.

******************************


Solution:


1. change javadoc

$sudo update-alternatives --install "/usr/bin/javadoc" "javadoc" "/usr/local/jdk1.6.0_45/bin/javadoc" 1;


$sudo update-alternatives --config javadoc


2. update API

$make update-api



posted by bluelimn 2017.04.10 11:01

Renesas R-Car New Software for Connected Cars, Safety, Security and Linux/Android

Posted on April 9, 2017 by Gilbert Shar


link : http://www.autoconnectedcar.com/2017/04/renesas-r-car-new-software-for-connected-cars-safety-security-and-linuxandroid/


Renesas announced its new software packages for the R-Car automotive


computing platform to improve security and safety capabilities for next-generation connected cars. The software packages implement embedded optimized virtualization technology that enables embedded systems to have—in a single system—security features that protect the car from external threats, and functional safety features that assure continued safe operation even in the event of failures.


Safety is a primary concern for the automotive industry. Automotive systems including cloud-connected systems, instrument cluster, and driver monitoring are expanding in number and scale year by year. In addition, the demand for new user experience, such as information sharing and control linked with other systems over multi displays, is increasing. These trends have led to increasing expectations for the integration of automotive systems. For instrument cluster and driver monitoring, support for functional safety is particularly required to safely handle the car even in the event of failures.


 

Security is another key concern. For example, automotive cyber security becomes mission critical as modern cars are advancing towards connected cars that allow applications to be downloaded from the open cloud to update and upgrade the software in the car. Increased security functions are required to protect the car from malicious attacks over the network and to secure personal information handled in the cloud. Applications for cloud services need to be separated from instrument cluster to avoid idddmportant information from being lost or destroyed.


At the same time, the car cockpit environment is poised to evolve to an automotive computing system that integrates multiple systems to provide a more consistent and more advanced user experience. This creates new integration challenges for OEMs and Tier 1s to achieve, in a single system, both the security and the functional safety features that were previously implemented individually in multiple systems.


To resolve these issues, Renesas offers several new software packages that enable the integration of multiple automotive systems, including systems that require security and functional safety features, in a single R-Car platform:


Virtualization Package that allows multiple operating systems (OS) to be integrated simultaneously and for multiple different applications to operate on a single R-Car system for enhanced system integration.

Security Package that allows the implementation of secure booting and secure updates among other functions to meet changing security requirements.

Functional Safety Package that enables control of the safety mechanisms (hardware IPs) included in the R-Car system-on-chip (SoC).

Renesas, along with its partner companies, is making these software packages available to system manufacturers now, and plans to expand them in the future.


Key features of the new software packages:



 

(1) Embedded virtualization technology that enables integration of multiple systems while achieving both functional safety and security features


As its first release of embedded hypervisor for virtualization, Renesas adopted the INTEGRITY® MultivisorTM from Green Hills Software. With this hypervisor, a suitable OS for the application software, such as Real Time OS (RTOS), Linux, or AndroidTM, can be installed. The required level of security and functional safety can be assured by dividing the system into independent and robust partitions. Diverse applications can be run on a single R-Car platform. For example, Linux and/or Android OS can also be installed to run applications that require cloud connectivity or navigation, and the Green Hills Software INTEGRITY or other real-time OS can be installed on the same platform for applications that require functional safety support, such as instrument cluster and warning sound generator. The low performance degradation compared to running these applications on individual hardware such as system-on-chips (SoC) or microcontrollers (MCUs), enables integration in a single system on the R-Car platform. Support for other hypervisors will be rolled out sequentially.


(2) Security software that realizes a secure environment to safely run programs


Security functions are becoming crucial to prevent hacking and other attacks over the network. Renesas provides a variety of software for implementing strong security functions, such as: secure boot functions that prevent modifications to programs; security level management functions that correspond to the product lifetime; and trusted execution environments. In addition, the new software also enables OTA updating, which allows application and OS upgrades without the driver having to return to the car dealer. Renesas plans to sequentially roll out a variety of security software packages to respond to system structures and needs, and to support the hypervisor.


(3) Functional safety software that supports system development for functional safety


To implement functional safety, the Renesas R-Car H3 and R-Car M3 SoCs feature multiple hardware IPs to support their safety concept. This includes the runtime self-test system that Renesas announced at the ISSCC 2016 conference. This technology achieves the required diagnostic coverage of functional safety and reduces interruptions to programs running during the tests while taking advantage of multi-core CPUs to perform self-tests to detect faults. Renesas supports system development that supports functional safety by providing software that controls this safety mechanism. Renesas intends sequentially to roll out a variety of functional safety software packages.


”Today’s automotive OEMs and Tier 1s require a proven run-time software foundation to build production-grade automotive electronics,” said Tim Reed, Vice President of Advanced Products, Green Hills Software. “The INTEGRITY real-time operating system with Multivisor secure virtualization is an ASIL-certified and secure microkernel architecture, a flexible platform for system designers to mix guest OS systems with safety and security-critical functions across multiple cores, while leveraging the R-Car’s high-performance features. As the first company to deploy virtualization into the automobile we are happy to continue to work with Renesas as the first virtualization platform on Renesas’ high-performance R-Car devices.”


As a solution provider, Renesas is committed to providing solutions that support the early development of automotive computing systems and advanced driving assistance systems by collaborating with partners and contribute a safe and secure automotive future.

posted by bluelimn 2017.03.09 16:21

어저께 대감 마님네 잔치가 있었자네

가마 쪼깨 들어주고 녹을 받아 돌씨하고 춘샘이 하고 잔을 걸치고 들어간께

아 여편네가 울고 있는거여


잔치서 홀킨 귀한 송이를 아 하나 서방 하나 줄라고 기댕키는디

아는 먹도 안하고 투정질이고 서방은 술먹니라 들오도 않고 하다하다 나랏님꺼정 속을 썩이니

할 줄 아는 게 없어 마냥 운다고 카데


아니 나랏님은 받들어야제 어찌 그 분이 당신 기분을 맞춘단가? 했더니

글쎄 나랏님이 도적패랑 모의를 해서 백성들을 잡아간다는 거여 저그 방도 다 붙었는디 보도 못했냐길래

나랏님이 뭐가 아수워서 도적패랑 붙는당가? 방이 붙어도 거짓 방이 붙었고만! 하고는 소리를 냅다 지르고 나왔제


근디 아무래도 내용이 너무 자세허단 말시

어서 본 것 같기도 하고

영 신통치가 않은 거여


근디 나가 여편네한티 져서 되갔는가

다시 집에가서는 나랏님은 다 생각이 있어 그런 것이요 설사 사실이라 해도 잔치 집서 땅바닥에 떨어진 송이 홀킨 것보다 작은 흠인께 다시 한번 나랏님을 욕보이만 몽디로 죽사발을 낸다 혔제


나가 이로코롬 나라를 생각허고 나랏님을 위하는디 설마 도적패가 우리집은 건덜도 않겄제?

'bluelimn's > 우울한망상' 카테고리의 다른 글

어디서 거짓 방을 붙였고만?  (0) 2017.03.09
꿈을 품고 사는가?  (0) 2015.09.15
만약 신이 있다면  (0) 2015.09.12
즐겁지 않은 이유  (1) 2011.11.10
언론  (0) 2011.01.06
도대체 사람들은  (0) 2010.01.30
어그녀?  (0) 2009.11.28
꿈이란 뭘까?  (0) 2009.08.13
세가지 질문  (0) 2009.06.17
좋은일 가득  (0) 2009.06.03
감정 없는 기억  (0) 2009.03.03
posted by bluelimn 2016.04.06 18:06

vim에서 backspace 되지 않을

~/.bashrc 또는 ~/.bash_profile 추가

stty erase '^?'

 

vim에서 .vimrc 가져오지 못을

~/.bashrc 또는 ~/.bash_profile 추가

alias vim="vim -S ~/.vimrc"

 

 

vim source insight처럼 사용하기(taglist, SrcExpl, nerdTree)

* SrcExpl: http://www.vim.org/scripts/script.php?script_id=2179
* taglist: http://www.vim.org/scripts/script.php?script_id=273
*nerdTree: http://www.vim.org/scripts/script.php?script_id=1658

~/.vim/ 하위에 설치


~/.vimrc 수정

set tabstop=2

set shiftwidth=2

set softtabstop=2

set cindent

set autoindent

set smartindent

set incsearch

syntax on

filetype on

set background=dark

colorscheme evening

set backspace=eol,start,indent

set history=1000

set hlsearch

set showmatch

set nu

"============= Like a Source Insight =============”

"=== Taglist ===

" // The switch of the Taglist

nmap <F7> :TlistToggle<CR>

let Tlist_Ctags_Cmnd = "/usr/bin/ctags"

let Tlist_Inc_Winwidth = 0

let Tlist_Exit_OnlyWindow = 0

let Tlist_Auto_Open = 0

let Tlist_Use_Left_Window = 1

"=== NERDTree ===

" // The switch of the NERDTree

nmap <F9> :NERDTreeToggle<CR>

let NERDTreeWinPos = "right"

"=== Source explorer ===

" // The switch of the Source Explorer

nmap <F8> :SrcExplToggle<CR>

"// Map the keys below to jump from one window to another:

nmap <C-H> <C-W>h

nmap <C-J> <C-W>j

nmap <C-K> <C-W>k

nmap <C-L> <C-W>l

let g:SrcExpl_winHeight = 8

let g:SrcExpl_refreshTime = 100

let g:SrcExpl_isUpdateTags = 0

" // Set “Enter” key to jump into the exact definition context

let g:SrcExpl_jumpKey = "<ENTER>"

" // Set “Space” key for back from the definition context

let g:SrcExpl_gobackKey = "<SPACE>"

map <F3> :tnext^M

map <F2> :tprevious^M

 

경우 F7, F8, F9 이용하여 켜고 있음.


Tag 생성

mktrace.sh

#!/bin/sh

rm -rf cscope.files cscope.files

rm -rf tags


find . \( -name  *.c  -o -name  *.cpp  -o -name  *.cc  -o -name  *.h  -o -name  *.s  -o -name  *.S  -o -name  *.asm  \) -print > cscope.files

ctags -R


cscope -i cscope.files 


'Programming > linux왕초보' 카테고리의 다른 글

ssh사용 시 diffie-hellman-group1-sha1 관련  (0) 2018.01.30
pthread min, max priority on linux  (0) 2017.06.12
use vim like as source insight  (0) 2016.04.06
[ubuntu] change default shell  (0) 2016.03.22
GDB를 사용한 CORE 파일의 분석  (0) 2016.02.05
kernel make menuconfig error  (0) 2016.01.21
Caching your GitHub password in Git  (0) 2016.01.08
Serial ports usage on Linux  (0) 2016.01.08
process 종료  (0) 2015.05.28
fork  (0) 2015.05.26
Linux SSD 최적화  (0) 2015.04.17
posted by bluelimn 2016.03.22 15:36

bash를 주로 사용하는데 sh로 초기 shell이 적용되어 color가 맞지 않는다거나 하는 경우


# echo $SHELL

output : 

/bin/sh


chsh -s {shell-name} {user-name}

#sudo chsh -s /bin/bash john



'Programming > linux왕초보' 카테고리의 다른 글

ssh사용 시 diffie-hellman-group1-sha1 관련  (0) 2018.01.30
pthread min, max priority on linux  (0) 2017.06.12
use vim like as source insight  (0) 2016.04.06
[ubuntu] change default shell  (0) 2016.03.22
GDB를 사용한 CORE 파일의 분석  (0) 2016.02.05
kernel make menuconfig error  (0) 2016.01.21
Caching your GitHub password in Git  (0) 2016.01.08
Serial ports usage on Linux  (0) 2016.01.08
process 종료  (0) 2015.05.28
fork  (0) 2015.05.26
Linux SSD 최적화  (0) 2015.04.17
posted by bluelimn 2016.03.08 14:20

분서갱유

焚書坑儒 ,焚书坑儒


출처 : http://100.daum.net/encyclopedia/view/26XXXXX00599



서적을 불사르고 유생을 구덩이에 묻다. 상황을 고려하지 않고 무조건 발본색원을 하거나 폭정을 저지르는 것을 비유하는 말이다.



출전


진시황제(秦始皇帝)는 천하를 통일한 뒤 자손만대에 물려줄 수 있는 강력한 대제국을 만들기 위하여 군현제(郡縣制)를 실시했다. 군현제란 전국을 군과 현으로 나누고 관리를 파견하여 황제가 직접 다스리는 중앙집권 방식이다. 그런데 군현제에 반대 의견을 표하고, 봉건제로의 회귀를 주장하는 사람들이 상당수 있었다. 그 대표적인 사람이 바로 박사 순우월(淳于越)이었다. 순우월의 주장은 다음과 같다.


「진시황이 문무백관을 한자리에 불러 함양궁(咸陽宮)에서 잔치를 베푸는데 순우월이 황제 앞에 나와 말했다. “은나라와 주나라가 과거 천 년이나 왕위를 전할 수 있었던 것은 공신이나 친인척을 제후로 봉하여 이들이 병풍처럼 둘러서 왕실을 보호했기 때문입니다. 그런데 지금 왕께서는 지역을 분할해서 군현제를 채택하고 있기 때문에 설혹 왕족이라고 해도 일개 백성에 지나지 않습니다. 이제 만약 황실을 둘러엎으려는 불충한 자가 나올 경우 황실을 지켜 주는 세력이 없다면 어떻게 황실을 보전할 수 있겠습니까? 지나간 역사를 거울삼지 않고 장구한 안전을 얻었던 예는 없었습니다.”」


시황 34년(BC213) 이사(李斯)가 상서를 올렸다.


「예전에는 제후가 다투어 유세하는 학자를 후하게 초대하였으나, 이제 천하가 이미 평정되어 법령이 한곳에서 나오니 백성은 집에서 농업과 공업에 힘쓰며, 선비는 법령을 배워 익혀야 하거늘, 지금 여러 유생들은 지금을 스승 삼지 아니하고 옛것을 배워 현재를 비방하여 백성들을 미혹시키고, 서로 더불어 법이 아닌 것으로 사람들을 가르치고, 법령을 들으면 각자 자기의 학문으로 그것을 따지며, 조정에 들어가서는 마음속으로 비난하고, 밖으로 나와서는 논쟁하며, 왕에게 자만한 것을 명예롭게 생각하고, 뜻을 달리하는 것을 높다고 여겨 아랫사람들을 이끌고 다니면서 비방하니, 이 같은 것을 금하지 아니하면 왕의 권세는 위에서 내려가고 당파는 아래에서 이루어지게 되므로 이를 금해야 합니다. 사관은 진나라의 기록이 아니면 모두 불사르고, 박사관의 직책이 아니면 천하에 시서(詩書)와 백가(百家)의 서적을 소장한 자는 관리에 넘겨 모두 태우게 하고, 짝을 지어 시서를 논하는 자가 있으면 기시(棄市)하고, 옛것을 가지고 지금을 비방하는 자는 멸족하십시오. 의약, 복서(卜筮), 종수(種樹)의 책은 남겨두되, 만약 법령을 배우고자 하면 관리를 스승으로 삼게 하십시오.(臣請史官, 非秦記皆燒之. 非博士官所職, 天下有藏詩書百家語者, 皆詣守尉, 雜燒之. 有偶語詩書者棄市, 以古非今者族. 所不去者, 醫藥卜筮種樹之書. 若欲有學法令, 以吏爲師.)」


춘추전국시대에 전국이 전화에 휩싸인 근본적인 이유가 봉건제였으며, 전쟁을 부추긴 사람들이 바로 자신의 입신을 위해 각국의 왕들에게 유세를 하고 다녔던 학자였다고 분석했던 진시황은 군현제의 입안자이자 개혁론자인 재상 이사의 진언을 받아들여 군현제 실시에 장애물이 되는 것을 제거하는 조치를 내린다. 바로 의약과 복술, 농경에 관한 책과 진나라의 기록을 제외한, 민간에 퍼져 있던 시서(《시경》과 《서경》)와 제자백가의 책을 수거하여 태우고, 이를 위반하는 사람들이나 시서를 논하는 사람들과, 옛날과 비교하면서 정부의 정책을 비판하고 진시황을 비난하는 사람들을 모두 처형하는 것이었다. 이것이 바로 분서 사건이다. 그러나 이때 모든 기록을 다 불태운 것은 아니고, 박사관이 소장하고 있던 것은 그대로 보존되었다. 박사관이 소장하고 있던 나머지 기록마저도 다 불에 타 없어지고 만 것은 후에 항우(項羽)가 함양에 입성하여 진나라의 궁실을 불지른 때였다.(당시의 책은 모두 대나무 조각을 엮어서 만든 죽간(竹簡)이거나 비단 두루마리인 백서(帛書)였으므로 대부분 한번 잃으면 복원하기가 어려웠다.)


일반적으로 ‘분서갱유’라고 하며 분서와 갱유를 병칭하고 있지만, 사실은 갱유는 분서와는 별개의 사건으로, 도가의 방사들이 일으킨 화로 인해 그 불똥이 유생들에게 튄 사건이었다. 진시황은 말년에 미신에 빠져 불로장생의 선약을 구해 주겠다는 도가의 방사들에게 사기를 많이 당했다. 한중(韓衆)이나 서복(徐福)과 같은 방사들은 진시황의 돈만 사취하고 도망을 했고, 노생(盧生)과 후생(侯生)과 같은 방사들은 돈을 사취한 데 그치지 않고 오히려 진시황의 부덕함을 비난하고 도망해 버렸다. 이에 화가 난 진시황은 분서 다음 해인 BC212년, 자신의 실정을 비난하고 다니던 함양(咸陽)의 서생 460여 명을 체포하여 산 채로 구덩이에 매장해 버렸는데, 이것을 일러 갱유라고 한다.


「이에 어사를 시켜 서생들을 심문하게 하자 서생들이 서로 고발하였다. 진시황은 손수 금기를 범한 자들의 이름을 하나씩 지워 가며 460여 명을 모두 함양에서 산 채로 땅에 묻어 버려 천하가 알게 함으로써 후세에 경계를 삼도록 했다. 그리고 많은 사람을 적발하여 유배 보내 변방을 지키게 하였다. 그러자 큰아들 부소가 간했다. “천하가 막 평정되어 멀리 있는 백성들이 아직 돌아오지 못했고, 서생들은 시서를 외우며 공자를 배우고 있는데, 지금 폐하께서 무거운 법으로 다스리면 천하가 불안해할까 두렵습니다. 폐하께서 살피시기 바랍니다.” 진시황은 대로하여 부소를 북방의 상군으로 보내 몽염 장군을 감독하도록 했다.(於是使御史悉案問諸生, 諸生傳相告引, 乃自除犯禁者四百六十餘人, 皆阬之咸陽, 使天下知之, 以懲後. 益發謫徙邊. 始皇長子扶蘇諫曰, 天下初定, 遠方黔首未集, 諸生皆誦法孔子, 今上皆重法繩之, 臣恐天下不安. 唯上察之. 始皇怒, 使扶蘇北監蒙恬於上郡.)」


분서와 갱유에 관한 이야기들은 《사기(史記) 〈진시황본기(秦始皇本紀)〉》에 나오는데, 여기에는 진시황이 갱살한 것이 학자들인지, 아니면 방사들인지에 대한 구체적인 기록은 없다.


그러나 사마천은 다음에서 당시 진시황이 갱살한 것이 술사들이었다고 기록하고 있다.


「진나라 말년에 시서를 불태우고 술사들을 산 채로 묻어 죽였다.(及至秦之季世, 焚詩書, 坑術士.)」(《사기(史記) 〈유림열전(儒林列傳)〉》)


그런데 후세의 사람들이 진시황이 시서를 불태우고 서생들을 갱살한 사건을 ‘분서갱유’라고 칭하며 당시에 진시황이 유학자들을 묻어 죽였다고 이야기하는 것은, ‘분서갱유’란 말이 처음으로 쓰인 공안국(孔安國)의 《상서(尙書) 〈서(序)〉》에 기인한다.


「진시황이 선대의 전적을 없애고, 서적을 불사르고 유학자들을 산 채로 묻어 버리자 천하의 학사들이 모두 난을 피해 흩어져 버렸다.(及秦始皇滅先代典籍, 焚書坑儒, 天下學士逃難解散.)」



용례


과거 대부분의 독재 정권들은 언론을 장악하고 언론인들을 통제하기 위해 보도 지침을 만들어 현대판 ‘분서갱유’를 기도했다.


posted by 솔브0502 2016.02.25 15:08

◈.2016년도 기준중위소득 고시


⊙ 2016. 1. 1.부로 개인회생 생게비 내용이 변경되었습니다. 

 국민기초생보장법상 '최저생계비'라는 용어가 없어지고, 

  대신 '기준중위소득'이라는 용어가 생겼습니다.





⊙ 개인회생절차에서 적용되는 생계비는 "최저생계비의 150%"에서

  "기준중위소득의 60%"로 변경되었습니다. 

  (재판예규 제1556호, 개인회생사건처리지침)